Ken Friece [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-06 to 2015-08-19
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:37:11

- reply

📅 Original date posted:2015-08-19
📝 Original message:1.) Most people are running XT as a vote for bigger blocks and not because
they specifically support BIP101. If Core supported bigger blocks, most XT
users would switch back to Core and XT would die.
2.) In this high stakes game of poker, XT just went all in, but Core still
has the far better hand. There are many, many scaling solutions Core could
adopt that would appease XT users enough to kill XT. Don't let perfect be
the enemy of good. The real question is whether or not anyone can provide
enough Core leadership to reach "consensus". The longer it takes for Core
to reach "consensus", the stronger XT gets.
3.) Bitcoin market price has a far greater mining centralizing effect than
larger blocks ever will. Right now, miners with reasonably efficient
hardware and energy costs (.5W/GH mining hardware, 10 cents per kilowatt
hour power, $250 BTC price) spend about half of their mining income on
electricity. If the total Bitcoin market cap is under ~5 billion at the
next halving in July 2016, it's game over for all but the most efficient
(large) miners. The mining centralization that may occur with 8MB blocks in
2016 is nothing compared to the centralization that will occur if the total
Bitcoin market cap does not grow substantially between now and the next
halving.
4.) Investors hate uncertainty, and the blocksize issue is adding a lot of
uncertainty right now, which makes the mining nightmare scenario outlined
above more likely. The entire ecosystem needs time to adjust and grow once
a Core scaling solution is adopted. Hopefully this issue will be revolved
well before the next halving in July 2016 so the market has time to adjust
and grow again.
5.) Not-BitcoinXT is a really terrible idea. Mike has proven time and time
again that he will not blink or back down. The chances of Not-BitcoinXT
gaining 25% of the hashrate are pretty much nil, so in effect, all
Not-BitcoinXT will do is help XT reach the 75% threshold sooner and end up
putting more people on the losing side of the fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/a69e5e4c/attachment.html>

2023-06-07 17:35:22

- reply

📅 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>

2023-06-07 17:35:18

- reply

📅 Original date posted:2015-08-15
📝 Original message: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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/9c7504be/attachment.html>

2023-06-07 17:35:17

- reply

📅 Original date posted:2015-08-15
📝 Original message: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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/9d78087a/attachment.html>

2023-06-07 17:35:14

- reply

📅 Original date posted:2015-08-15
📝 Original message: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'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.
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.
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...
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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/43e010e3/attachment-0001.html>

2023-06-07 17:35:14

- reply

2023-06-07 17:33:28

- reply

📅 Original date posted:2015-08-06
📝 Original message:I am a long time Bitcoin user, miner, investor, full node operator, and
distributed real-time system software engineer.
Out of the all currently proposed blocksize increase solutions, I support
BIP101 (or something like it) and find the current blocksize debate very
frustrating, so I will try to systematically debunk some common arguments
against BIP101 below.
1.
We should not increase the blocksize because we'll just end up hitting
the limit again at a future time.
-
If a reasonable blocksize increase like BIP101 that scales with
technology is implemented, it's not a given that we will hit the
blocksize
limit (consistently full blocks over an extended period of time) again in
the future. Stating that we will definitely hit the blocksize limit again
in the future is pure speculation about future bitcoin transaction volume
that can't possibly be known at this time, and is nothing but conjecture.
If technology increases faster than bitcoin transaction volume, simply
scaling the Bitcoin blocksize could keep up with future demand.
If Bitcoin
is successful beyond our wildest dreams and future transaction volume
outstrips future blockchain space, alternative solutions like
sidechains or
the lightning network will have more time to be implemented.
1.
The full node count will go down if we increase the blocksize because it
will be more costly to run a full node.
-
I'm not sure this is true. I currently run a full node on a higher
end consumer PC with a higher end home network connection, but if the
blocksize limit is not raised and transaction fees increase such
that it is
no longer economical for me to access the bitcoin blockchain directly, I
will no longer run a full node to support the network. Bitcoin
is no longer
interesting to me if it gets to the point where the average user
is priced
off the blockchain. Users that have direct access to the blockchain are
more likely to run full nodes. If Bitcoin ever becomes purely a limited,
small settlement network, I will no longer support it and move onto
something else.
1.
The blocksize can only be increased if there is developer “consensus”
and the change is not “controversial”.
-
Any blocksize increase will the deemed “controversial” and lack
“consensus”, but doing nothing in the face of consistently full
blocks and
rising transaction fees is also “controversial” and will lack
“consensus”.
Inaction, maintaining the status quo, and blocking a blocksize
increase in
the face of consistently full blocks and rising transaction fees
is just as
controversial as increasing the blocksize.
1.
Don't increase the blocksize now with all the promising work going on
with sidechains and the lightning network.
-
KISS (keep it simple, stupid). When dealing with a highly complex,
mission critical system, there needs to be a very compelling reason to
choose a much more complex solution over a simple solution like BIP101.
Sidechains and the lightning network are much more complex than
BIP101 and
introduce new points of failure. It's hard enough to get folks
to trust the
Bitcoin network after 7 years, so it will likely take years until
sidechains and the lightning network are proven enough to be trusted by
users.
1.
Some miners will be at a disadvantage with larger blocks.
-
As folks have pointed out multiple times, network speed is just one
of many variables that impact mining profitability. I don't believe for a
second that every miner in China (57% of the network) would be negatively
impacted by larger blocks because some of them either have decent network
connections or connect to mining pools with decent network connections.
Miners will be given ample notice of a blocksize increase before
it occurs,
so they will have time to make plans to deal with larger blocks. More
transactions per block should also increase miner profitability because
more transactions equals more users equals more transaction fees!
In conclusion, I think the next year is a make or break year for Bitcoin
and hope the developers do everything they can to come up with a reasonable
long term growth plan to put Bitcoin in the best possible position to be
successful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/3c575c43/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply