What is Nostr?
Ken Friece [ARCHIVE] /
npub1rsl…xqf2
2023-06-07 17:35:22

Ken Friece [ARCHIVE] on Nostr: đź“… Original date posted:2015-08-15 đź“ť Original message:Let's start with the ...

đź“… Original date posted:2015-08-15
đź“ť Original message:Let's start with the definition of a conflict of interest before we go any
further:
A *conflict of interest* (COI) is a situation in which a person or
organization is involved in multiple interests (financial, emotional, or
otherwise), one of which could possibly corrupt the motivation of the
individual or organization.

Just because a conflict of interest exists does not necessarily mean the
individual with a conflict of interest has engaged in any wrongdoing. They
could be a saint. However, to not even be able to acknowledge that such a
conflict of interest exists when debating such a serious issue as the
bitcoin blocksize is incredibly naive.

On Sat, Aug 15, 2015 at 7:40 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:

> Baseless accusations also have no place on this mailing list. They are
> unprofessional, and poisonous to the consensus-building process we all seek
> to engage in.
>
> The Lightning Network effort at Blockstream is purposefully structured to
> avoid any conflict of interest. ALL code related to lightning is available
> on Github. There is absolutely nothing that we are holding back, and the
> protocol itself is entirely p2p. There is no privileged entity, Blockstream
> or otherwise.
>
> On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Please take the lightning 101 discussion to another thread.
>>
>> The main point I was trying to make was that Mike is clearly
>> misrepresenting the views of a great number of people who have deep,
>> intimate knowledge of how things work and are almost certainly not
>> primarily motivated by their own potential for profits.
>>
>> On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Being an early hub provider would be an obvious place to start
>> capitalizing on lightning. Early lightning adopters would be in the best
>> position to do this.
>>
>> Long term, Bitcoin needs to scale the blockchain in a reasonable manner
>> and implement things like lightning.
>>
>> Limiting the blocksize is a blatant conflict of interest because it
>> creates artificial demand for lightning that would not otherwise exist if
>> the blockchain scaled in a reasonable manner.
>>
>> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach <mark at friedenbach.org>
>> wrote:
>>
>>> I would like very much to know how it is that we're supposed to be
>>> making money off of lightning, and therefore how it represents a conflict
>>> of interest. Apparently there is tons of money to be made in releasing
>>> open-source protocols! I would hate to miss out on that.
>>>
>>> We are working on lightning because Mike of all people said,
>>> essentially, " if you're so fond of micro payment channels, why aren't you
>>> working on them?" And he was right! So we looked around and found the best
>>> proposal and funded it.
>>> On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I know full well who works for Blockstream and I know you're not one of
>>>> those folks. The Blockstream core devs are very vocal against a reasonable
>>>> blocksize increase (17% growth per year in Pieter's BIP is not what I
>>>> consider reasonable because it doesn't come close to keeping with
>>>> technological increases). I think we can both agree that more on-chain
>>>> space means less demand for lightning, and vice versa, which is a blatant
>>>> conflict of interest.
>>>>
>>>> I'm also trying to figure out how things like lightning are not
>>>> competing directly with miners for fees. More off-chain transactions means
>>>> less blockchain demand, which would lower on-chain fees. I'm not sure what
>>>> is controversial about that statement.
>>>>
>>>> The lightning network concept is actually a brilliant way to take fees
>>>> away from miners without having to make any investment at all in SSH-256
>>>> ASIC mining hardware.
>>>>
>>>> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> What are you so afraid of, Eric? If Mike's fork is successful,
>>>>> consensus is reached around larger blocks. If it is rejected, the status
>>>>> quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS,
>>>>> is the only thing that matters, and those that go against network consensus
>>>>> will be severely punished with complete loss of income.
>>>>>
>>>>>
>>>>> I fully agree that core developers are not the only people who should
>>>>> have a say in this. But again, we’re not talking about merely forking some
>>>>> open source project - we’re talking about forking a ledger representing
>>>>> real assets that real people are holding…and I think it’s fair to say that
>>>>> the risk of permanent ledger forks far outweighs whatever benefits any
>>>>> change in the protocol might bring. And this would be true even if there
>>>>> were unanimous agreement that the change is good (which there clearly IS
>>>>> NOT in this case) but the deployment mechanism could still break things.
>>>>>
>>>>> If anything we should attempt a hard fork with a less contentious
>>>>> change first, just to test deployability.
>>>>>
>>>>> I'm not sure who appointed the core devs some sort of Bitcoin Gods
>>>>> that can hold up any change that they happen to disagree with. It seems
>>>>> like the core devs are scared to death that the bitcoin network may change
>>>>> without their blessing, so they go on and on about how terrible hard forks
>>>>> are. Hard forks are the only way to keep core devs in check.
>>>>>
>>>>>
>>>>> Again, let’s figure out a hard fork mechanism and test it with a far
>>>>> less contentious change first
>>>>>
>>>>> Despite significant past technical bitcoin achievements, two of the
>>>>> most vocal opponents to a reasonable blocksize increase work for a company
>>>>> (Blockstream) that stands to profit directly from artificially limiting the
>>>>> blocksize. The whole situation reeks. Because of such a blatant conflict of
>>>>> interest, the ethical thing to do would be for them to either resign from
>>>>> Blockstream or immediately withdraw themselves from the blocksize debate.
>>>>> This is the type of stuff that I hoped would end with Bitcoin, but alas, I
>>>>> guess human nature never changes.
>>>>>
>>>>>
>>>>> For the record, I do not work for Blockstream. Neither do a bunch of
>>>>> other people who have published a number of concerns. Very few of the
>>>>> concerns I’ve seen from the technical community seem to be motivated
>>>>> primarily by profit motives.
>>>>>
>>>>> It should also be pointed out that *not* making drastic changes is the
>>>>> default consensus policy…and the burden of justifying a change falls on
>>>>> those who want to make the change. Again, the risk of permanent ledger
>>>>> forks far outweighs whatever benefits protocol changes might bring.
>>>>>
>>>>> Personally, I think miners should give Bitcoin XT a serious look.
>>>>> Miners need to realize that they are in direct competition with the
>>>>> lightning network and sidechains for fees. Miners, ask yourselves if you
>>>>> think you'll earn more fees with 1 MB blocks and more off-chain
>>>>> transactions or with 8 MB blocks and more on-chain transactions…
>>>>>
>>>>>
>>>>> Miners are NOT in direct competition with the lightning network and
>>>>> sidechains - these claims are patently false. I recommend you take a look
>>>>> at these ideas and understand them a little better before trying to make
>>>>> any such claims. Again, I do not work for Blockstream…and my agenda in this
>>>>> post is not to promote either of these ideas…but with all due respect, I do
>>>>> not think you properly understand them at all.
>>>>>
>>>>> The longer this debate drags on, the more I agree with BIP 100 and
>>>>> Jeff Garzik because the core devs are already being influenced by outside
>>>>> forces and should not have complete control of the blocksize. It's also
>>>>> interesting to note that most of the mining hashpower is already voting for
>>>>> 8MB blocks BIP100 style.
>>>>>
>>>>>
>>>>> I don’t think the concern here is so much that some people want to
>>>>> increase block size. It’s the *way* in which this change is being pushed
>>>>> that is deeply problematic.
>>>>>
>>>>> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <
>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> You deeply disappoint me, Mike.
>>>>>>
>>>>>> Not only do you misrepresent many cogent, well thought out positions
>>>>>> from a great number of people who have published and posted a number of
>>>>>> articles detailing an explaining in-depth technical concerns…you also seem
>>>>>> to fancy yourself more capable of reading into the intentions of someone
>>>>>> who disappeared from the scene years ago, before we even were fully aware
>>>>>> of many things we now know that bring the original “plan” into question.
>>>>>>
>>>>>> I ask of you, as a civilized human being, to stop doing this divisive
>>>>>> crap. Despite your protestations to the contrary, YOU are the one who is
>>>>>> proposing a radical departure from the direction of the project. Also, as
>>>>>> several of us have clearly stated before, equating the fork of an open
>>>>>> source project with a fork of a cryptoledger is completely bogus - there’s
>>>>>> a lot of other people’s money at stake. This isn’t a democracy - consensus
>>>>>> is all or nothing. The fact that a good number of the people most
>>>>>> intimately familiar with the inner workings of Satoshi’s invention do not
>>>>>> believe doing this is a good idea should give you pause.
>>>>>>
>>>>>> Please stop using Bitcoin as your own political football…for the sake
>>>>>> of Bitcoin…and for your own sake. Despite your obvious technical abilities
>>>>>> (and I sincerely do believe you have them) you are discrediting yourself
>>>>>> and hurting your own reputation.
>>>>>>
>>>>>>
>>>>>> - Eric
>>>>>>
>>>>>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
>>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> As promised, we have released Bitcoin XT 0.11A which includes the
>>>>>> bigger blocks patch set. You can get it from
>>>>>>
>>>>>> https://bitcoinxt.software/
>>>>>>
>>>>>> I feel sad that it's come to this, but there is no other way. The
>>>>>> Bitcoin Core project has drifted so far from the principles myself and many
>>>>>> others feel are important, that a fork is the only way to fix things.
>>>>>>
>>>>>> Forking is a natural thing in the open source community, Bitcoin is
>>>>>> not the first and won't be the last project to go through this. Often in
>>>>>> forks, people say there was insufficient communication. So to ensure
>>>>>> everything is crystal clear I've written a blog post and a kind of
>>>>>> "manifesto" to describe why this is happening and how XT plans to be
>>>>>> different from Core (assuming adoption, of course).
>>>>>>
>>>>>> The article is here:
>>>>>>
>>>>>>
>>>>>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>>>>>>
>>>>>> It makes no attempt to be neutral: this explains things from our
>>>>>> point of view.
>>>>>>
>>>>>> The manifesto is on the website.
>>>>>>
>>>>>> I say to all developers on this list: if you also feel that Core is
>>>>>> no longer serving the interests of Bitcoin users, come join us. We don't
>>>>>> bite.
>>>>>>
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/8ee0851d/attachment-0001.html>;
Author Public Key
npub1rslmeackq2vlwkzte3g5rc23960qkxnc3rfd7hvgne4plz5udfysayxqf2