Michael Naber [ARCHIVE]

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

Public Key

npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4

Profile Code

nprofile1qqsg3kg37eu3lt7dfsj0xrrxxc8x7s7ua2qehrefg2urhh9s4fa52nqyncgpu

Author Public Key

npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4

Show more details

Last Notes

2023-06-07 17:35:20

- reply

📅 Original date posted:2015-08-15
📝 Original message:Bitcoin has no elections; it has no courts. If not through attempting a
hard-fork, how should we properly resolve irreconcilable disagreements?
On Sat, Aug 15, 2015 at 6: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/67814377/attachment-0001.html>

2023-06-07 17:34:04

- reply

📅 Original date posted:2015-08-11
📝 Original message:All things considered, if people want to participate in a global consensus
network, and the technology exist to do it at a lower cost, then is it
sensible or even possible to somehow arbitrarily set the price of
participating in a global consensus network to be expensive? Can someone
please walk me through how that's expected to play out because I'm really
having a hard time understanding how it could work.
On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> More people using Bitcoin does not necessarily mean more transactions
> being processed by the block chain. Satoshi was forward-thinking enough to
> include a powerful script-signature system, something which has never
> really existed before. Though suffering from some limitations to be sure,
> this smart contract execution framework is expressive enough to enable a
> wide variety of new features without changing bitcoin itself.
>
> One of these invented features is micropayment channels -- the ability for
> two parties to rapidly exchange funds while only settling the final balance
> to the block chain, and to do so in an entirely trustless way. Right now
> people don't use scripts to do interesting things like this, but there is
> absolutely no reason why they can't. Lightning network is a vision of a
> future where everyone uses a higher-layer protocol for their transactions
> which only periodically settle on the block chain. It is entirely possible
> that you may be able to do all your day-to-day transactions in bitcoin yet
> only settle accounts every other week, totaling 13kB per year. A 1MB block
> could support that level of usage by 4 million people, which is many orders
> of magnitude more than the number of people presently using bitcoin on a
> day to day basis.
>
> And that, by the way, is without considering as-yet uninvented
> applications of existing or future script which will provide even further
> improvements to scale. This is very fertile ground being explored by very
> few people. One thing I hope to come out of this block size debate is a lot
> more people (like Joseph Poon) looking at how bitcoin script can be used to
> enable new and innovative resource-efficient and privacy-enhancing payment
> protocols.
>
> The network has room to grow. It just requires wallet developers and other
> infrastructure folk to step up to the plate and do their part in deploying
> this technology.
>
> On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon <gubatron at gmail.com> wrote:
>
>> - policy neutrality.
>> - It can't be censored.
>> - it can't be shut down
>> - and the rules cannot change from underneath you.
>>
>> except it can be shutdown the minute it actually gets used by its
>> inability to scale.
>>
>> what's the point of having all this if nobody can use it?
>> what's the point of going through all that energy and CO2 for a mere
>> 24,000 transactions an hour?
>>
>> It's clear that it's just a matter of time before it collapses.
>>
>> Here's a simple proposal (concept) that doesn't pretend to set a fixed
>> block size limit as you can't ever know the demands the future will bring
>> https://gist.github.com/gubatron/143e431ee01158f27db4
>>
>> We don't need to go as far as countries with hyper inflation trying to
>> use the technology to make it collapse, anybody here who has distributed
>> commercial/free end user software knows that any small company out there
>> installs more copies in a couple weeks than all the bitcoin users we have
>> at the moment, all we need is a single company/project with a decent amount
>> of users who are now enabled to transact directly on the blockchain to
>> screw it all up (perhaps OpenBazaar this winter could make this whole thing
>> come down, hopefully they'll take this debate and the current limitations
>> before their release, and boy are they coding nonstop on it now that they
>> got funded), the last of your fears should be a malicious government trying
>> to shut you down, for that to happen you must make an impact first, for now
>> this is a silly game in the grand scheme of things.
>>
>> And you did sound pretty bad, all of his points were very valid and they
>> share the concern of many people, many investors, entrepreneurs putting
>> shitload of money, time and their lives on a much larger vision than that
>> of a network that does a mere 3,500 tx/hour, but some people seem to be
>> able to live in impossible or useless ideals.
>>
>> It's simply irresponsible to not want to give the network a chance to
>> grow a bit more. Miners centralizing is inevitable given the POW based
>> consensus, hobbists-mining is only there for countries with very cheap
>> energy.
>>
>> If things remain this way, this whole thing will be a massive failure and
>> it will probably take another decade before we can open our mouths about
>> cryptocurrencies, decentralization and what not, and this stubornness will
>> be the one policy that censored everyone, that shutdown everyone, that made
>> the immutable rules not matter.
>>
>> Perhaps it will be Stellar what ends up delivering at this stubborn pace.
>>
>> http://twitter.com/gubatron
>>
>> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> >It follows then, that if we make a decision now which destroys that
>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>> pressure miners into changing rules contrary to user interests, then
>>> Bitcoin is no longer interesting.
>>>
>>> You asked to be convinced of the need for bigger blocks. I gave that.
>>> What makes you think bitcoin will break when more people use it?
>>>
>>> Sent on the go, excuse the brevity.
>>> *From: *Mark Friedenbach
>>> *Sent: *Tuesday, 11 August 2015 08:10
>>> *To: *Thomas Zander
>>> *Cc: *Bitcoin Dev
>>> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>>>
>>> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>>>> > This is where things diverge. It's fine to pick a new limit or growth
>>>> > trajectory. But defend it with data and reasoned analysis.
>>>>
>>>> We currently serve about 0,007% of the world population sending maybe
>>>> one
>>>> transaction a month.
>>>> This can only go up.
>>>>
>>>> There are about 20 currencies in the world that are unstable and
>>>> showing early
>>>> signs of hyperinflation. If even small percentage of these people
>>>> cash-out and
>>>> get Bitcoins for their savings you'd have the amount of people using
>>>> Bitcoin
>>>> as savings go from maybe half a million to 10 million in the space of a
>>>> couple
>>>> of months. Why so fast? Because all the world currencies are linked.
>>>> Practically all currencies follow the USD, and while that one may stay
>>>> robust
>>>> and standing, the linkage has been shown in the past to cause
>>>> chain-effects.
>>>>
>>>> It is impossible to predict how much uptake Bitcoin will take, but we
>>>> have
>>>> seen big rises in price as Cyprus had a bailin and then when Greece
>>>> first
>>>> showed bad signs again.
>>>> Lets do our due diligence and agree that in the current world economy
>>>> there
>>>> are sure signs that people are considering Bitcoin on a big scale.
>>>>
>>>> Bigger amount of people holding Bitcoin savings won't make the
>>>> transaction
>>>> rate go up very much, but if you have feet on the ground you already
>>>> see that
>>>> people go back to barter in countries like Poland, Ireland, Greece etc.
>>>> And Bitcoin will be an alternative to good to ignore. Then transaction
>>>> rates
>>>> will go up. Dramatically.
>>>>
>>>> If you are asking for numbers, that is a bit tricky. Again; we are at
>>>> 0,007%... Thats like a f-ing rounding error in the world economy. You
>>>> can't
>>>> reason from that. Its like using a float to do calculations that you
>>>> should
>>>> have done in a double and getting weird output.
>>>>
>>>> Bottom line is that a maximum size of 8Mb blocks is not that odd.
>>>> Because a 20
>>>> times increase is very common in a "company" that is about 6 years old.
>>>> For instance Android was about that age when it started to get shipped
>>>> by non-
>>>> Google companies. There the increase was substantially bigger and the
>>>> company
>>>> backing it was definitely able to change direction faster than the
>>>> Bitcoin
>>>> oiltanker can change direction.
>>>>
>>>> ...
>>>>
>>>> Another metric to remember; if you follow hackernews (well, the
>>>> incubator more
>>>> than the linked articles) you'd be exposed to the thinking of these
>>>> startups.
>>>> Their only criteria is growth. and this is rather substantial growth.
>>>> Like
>>>> 150% per month. Naturally, most of these build on top of html or other
>>>> existing technologies. But the point is that exponential growth is
>>>> expected
>>>> in any startup. They typically have a much much more agressive
>>>> timeline,
>>>> though. Every month instead of every year.
>>>> Having exponential growth in the blockchain is really not odd and even
>>>> if we
>>>> have LN or sidechains or the next changetip, this space will be used.
>>>> And we
>>>> will still have scarcity.
>>>
>>>
>>> I'm sorry, I really don't want to sound like a jerk, but not a single
>>> word of that mattered. Yes we all want Bitcoin to scale such that every
>>> person in the world can use it without difficulty. However if that were all
>>> that we cared about then I would be remiss if I did not point out that
>>> there are plenty of better, faster, and cheaper solutions to finding global
>>> consensus over a payment ledger than Bitcoin. Architectures which are
>>> algorithmically superior in their scaling properties. Indeed they are
>>> already implemented and you can use them today:
>>>
>>> https://www.stellar.org/
>>> http://opentransactions.org/
>>>
>>> So why do I work on Bitcoin, and why do I care about the outcome of this
>>> debate? Because Bitcoin offers one thing, and one thing only which
>>> alternative architectures fundamentally lack: policy neutrality. It can't
>>> be censored, it can't be shut down, and the rules cannot change from
>>> underneath you. *That* is what Bitcoin offers that can't be replicated at
>>> higher scale with a SQL database and an audit log.
>>>
>>> It follows then, that if we make a decision now which destroys that
>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>> pressure miners into changing rules contrary to user interests, then
>>> Bitcoin is no longer interesting. We might as well get rid of mining at
>>> that point and make Bitcoin look like Stellar or Open-Transactions because
>>> at least then we'd scale even better and not be pumping millions of tons of
>>> CO2 into the atmosphere from running all those ASICs.
>>>
>>> On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
>>>> problems.
>>>>
>>>
>>> Straw man, storage is not an issue.
>>>
>>>
>>>> You can buy broadband in every relevant country that easily supports the
>>>> bandwidth we need. (remember we won't jump to 8Mb in a day, it will
>>>> likely
>>>> take at least 6 months).
>>>>
>>>
>>> Neither one of those assertions is clear. Keep in mind the goal is to
>>> have Bitcoin survive active censorship. Presumably that means being able to
>>> run a node even in the face of a hostile ISP or government. Furthermore, it
>>> means being location independent and being able to move around. In many
>>> places the higher the bandwidth requirements the fewer the number of ISPs
>>> that are available to service you, and the more visible you are.
>>>
>>> It may also be necessary to be able to run over Tor. And not just
>>> today's Tor which is developed, serviced, and supported by the US
>>> government, but a Tor or I2P that future governments have turned hostile
>>> towards and actively censor or repress. Or existing authoritative
>>> governments, for that matter. How much bandwidth would be available through
>>> those connections?
>>>
>>> It may hopefully never be necessary to operate under such constraints,
>>> except by freedom seeking individuals within existing totalitarian regimes.
>>> However the credible threat of doing so may be what keeps Bitcoin from
>>> being repressed in the first place. Lose the capability to go underground,
>>> and it will be pressured into regulation, eventually.
>>>
>>> To the second point, it has been previously pointed out that large
>>> miners stand to gain from larger blocks, for the same basic underlying
>>> reasons as selfish mining. The incentive is to increase blocks, and miners
>>> are able to do so at will and without cost. I would not be so certain that
>>> we wouldn't see large blocks sooner than that.
>>>
>>>
>>>> We should get the inverted bloom filters stuff (or competing products)
>>>> working
>>>> at least on a one-to-one basis so we can solve the propagation time
>>>> problem.
>>>> There frankly is a huge amount of optimization that can be done in that
>>>> area,
>>>> we don't even use locality (pingtime) to optimize distribution.
>>>> From my experience you can expect a 2-magnitude speedup in that same 6
>>>> month
>>>> period by focusing some research there.
>>>>
>>>
>>> This is basically already deployed thanks to Matt's relay network.
>>> Further improvements are not going to have dramatic effects.
>>>
>>>
>>>> Remember 8Gb/block still doesn't support VISA/Mastercard.
>>>>
>>>
>>> No, it doesn't. And 8GB/block is ludicrously large -- it would
>>> absolutely, without any doubt destroy the very nature of Bitcoin, turning
>>> it into a fundamentally uninteresting reincarnation of the existing
>>> financial system. And still be unable to compete with VISA/Mastercard.
>>>
>>> So why then the pressure to go down a route that WILL lead to failure by
>>> your own metrics?
>>>
>>> I humbly suggest that maybe we should play the strengths of Bitcoin
>>> instead -- it's trustlessness via policy neutrality.
>>>
>>> Either that, or go work on Stellar. Because that's where it's headed
>>> otherwise.
>>>
>>>
>>> _______________________________________________
>>> 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/20150811/811682e2/attachment-0001.html>

2023-06-07 17:33:55

- reply

📅 Original date posted:2015-08-11
📝 Original message:I'm not sure whether removing the limit at the protocol-level would lead to
government by miners who might reject blocks which were too big, but I
probably wouldn't want to take that risk. I think we should probably keep a
block size limit in the protocol, but that we should increase it to be as
high as "technology can provide." Toward that: I don't necessarily think
that node-count in and of itself should be the metric for evaluating what
technology can provide, as much as the goal that the chain be inexpensive
to validate given the capabilities of present technology -- so if I can
lease a server in a datacenter which can validate the chain and my total
cost to do that is just a few dollars, then we're probably ok.
Of course there's also the issue that we maintain enough geographic /
political distribution to keep the network reliable, but I think we're far
from being in danger on the reliability front. So maybe my criteria that
the chain be validated at low cost is the wrong focus, but if it is than
what's the appropriate criteria for deciding whether it's safe by standards
of "today's technology" to raise the limit at the protocol level?
On Tue, Aug 11, 2015 at 2:53 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Aug 11, 2015 9:37 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
>
> > Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>
> You didn't answer the 2 questions...
> Anyway, if we don't care about centralization at all, we can just remove
> the limit: that's what "technology can provide".
> Maybe in that case it is developers who move to a decentralized
> competitor...
>
> > On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >>
> >> On Aug 11, 2015 8:46 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
> >> >
> >> > Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
> >>
> >> Even if you are right, first fees will raise and that will be what
> pushes people to other altcoins, no?
> >> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/c9fb0045/attachment.html>

2023-06-07 17:33:51

- reply

📅 Original date posted:2015-08-11
📝 Original message:Bitcoin would be better money than current money even if it were a bit more
expensive to transact, simply because of its other great characteristics
(trustlessness, limited supply, etc). However... it is not better than
something else sharing all those same characteristics but which is also
less expensive. The best money will win, and if Bitcoin doesn't increase
capacity then it won't remain the best.
On Tue, Aug 11, 2015 at 4:23 PM, Adam Back <adam at cypherspace.org> wrote:
> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin. I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
> Adam
>
>
> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The only reason why Bitcoin has grown the way it has, and in fact the
> only
> > reason why we're all even here on this mailing list talking about this,
> is
> > because Bitcoin is growing, since it's "better money than other money".
> One
> > of the key characteristics toward that is Bitcoin being inexpensive to
> > transact. If that characteristic is no longer true, then Bitcoin isn't
> going
> > to grow, and in fact Bitcoin itself will be replaced by better money
> that is
> > less expensive to transfer.
> >
> > So the importance of this issue cannot be overstated -- it's compete or
> die
> > for Bitcoin -- because people want to transact with global consensus at
> high
> > volume, and because technology exists to service that want, then it's
> going
> > to be met. This is basic rules of demand and supply. I don't necessarily
> > disagree with your position on only wanting to support uncontroversial
> > commits, but I think it's important to get consensus on the criticality
> of
> > the block size issue: do you agree, disagree, or not take a side, and
> why?
> >
> >
> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
> > wrote:
> >>
> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
> >>> question at hand is whether we should constrain that limit below what
> >>> technology is capable of delivering. I'm arguing that not only we
> should
> >>> not, but that we could not even if we wanted to, since competition will
> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> some
> >>> other product / fork.
> >>
> >>
> >> The question is not what the technology can deliver. The question is
> what
> >> price we're willing to pay for that. It is not a boolean "at this size,
> >> things break, and below it, they work". A small constant factor increase
> >> will unlikely break anything in the short term, but it will come with
> higher
> >> centralization pressure of various forms. There is discussion about
> whether
> >> these centralization pressures are significant, but citing that it's
> >> artificially constrained under the limit is IMHO a misrepresentation.
> It is
> >> constrained to aim for a certain balance between utility and risk, and
> >> neither extreme is interesting, while possibly still "working".
> >>
> >> Consensus rules are what keeps the system together. You can't simply
> >> switch to new rules on your own, because the rest of the system will
> end up
> >> ignoring you. These rules are there for a reason. You and I may agree
> about
> >> whether the 21M limit is necessary, and disagree about whether we need a
> >> block size limit, but we should be extremely careful with change. My
> >> position as Bitcoin Core developer is that we should merge consensus
> changes
> >> only when they are uncontroversial. Even when you believe a more
> invasive
> >> change is worth it, others may disagree, and the risk from disagreement
> is
> >> likely larger than the effect of a small block size increase by itself:
> the
> >> risk that suddenly every transaction can be spent twice (once on each
> side
> >> of the fork), the very thing that the block chain was designed to
> prevent.
> >>
> >> My personal opinion is that we should aim to do a block size increase
> for
> >> the right reasons. I don't think fear of rising fees or unreliability
> should
> >> be an issue: if fees are being paid, it means someone is willing to pay
> >> them. If people are doing transactions despite being unreliable, there
> must
> >> be a use for them. That may mean that some use cases don't fit anymore,
> but
> >> that is already the case.
> >>
> >> --
> >> Pieter
> >>
> >
> >
> > _______________________________________________
> > 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/20150811/50de7307/attachment.html>

2023-06-07 17:33:48

- reply

📅 Original date posted:2015-08-11
📝 Original message:Sure, most people probably would be happy with cheaper off-chain systems.
There already are and will probably continue to be more transactions
happening off-chain partly for this very reason. That's not the issue we're
trying to address though: The main chain is the lynch-pin to the whole
system. We've got to do a good job meeting demand that people have for
wanting to utilize the main-chain, or else we'll risk being replaced by
some other main-chain solution that does it better.
On Tue, Aug 11, 2015 at 4:34 PM, Adam Back <adam at cypherspace.org> wrote:
> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com> wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin. I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wuille at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >>>
> >> >>> Hitting the limit in and of itself is not necessarily a bad thing.
> The
> >> >>> question at hand is whether we should constrain that limit below
> what
> >> >>> technology is capable of delivering. I'm arguing that not only we
> >> >>> should
> >> >>> not, but that we could not even if we wanted to, since competition
> >> >>> will
> >> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> >> >>> some
> >> >>> other product / fork.
> >> >>
> >> >>
> >> >> The question is not what the technology can deliver. The question is
> >> >> what
> >> >> price we're willing to pay for that. It is not a boolean "at this
> size,
> >> >> things break, and below it, they work". A small constant factor
> >> >> increase
> >> >> will unlikely break anything in the short term, but it will come with
> >> >> higher
> >> >> centralization pressure of various forms. There is discussion about
> >> >> whether
> >> >> these centralization pressures are significant, but citing that it's
> >> >> artificially constrained under the limit is IMHO a misrepresentation.
> >> >> It is
> >> >> constrained to aim for a certain balance between utility and risk,
> and
> >> >> neither extreme is interesting, while possibly still "working".
> >> >>
> >> >> Consensus rules are what keeps the system together. You can't simply
> >> >> switch to new rules on your own, because the rest of the system will
> >> >> end up
> >> >> ignoring you. These rules are there for a reason. You and I may agree
> >> >> about
> >> >> whether the 21M limit is necessary, and disagree about whether we
> need
> >> >> a
> >> >> block size limit, but we should be extremely careful with change. My
> >> >> position as Bitcoin Core developer is that we should merge consensus
> >> >> changes
> >> >> only when they are uncontroversial. Even when you believe a more
> >> >> invasive
> >> >> change is worth it, others may disagree, and the risk from
> disagreement
> >> >> is
> >> >> likely larger than the effect of a small block size increase by
> itself:
> >> >> the
> >> >> risk that suddenly every transaction can be spent twice (once on each
> >> >> side
> >> >> of the fork), the very thing that the block chain was designed to
> >> >> prevent.
> >> >>
> >> >> My personal opinion is that we should aim to do a block size increase
> >> >> for
> >> >> the right reasons. I don't think fear of rising fees or unreliability
> >> >> should
> >> >> be an issue: if fees are being paid, it means someone is willing to
> pay
> >> >> them. If people are doing transactions despite being unreliable,
> there
> >> >> must
> >> >> be a use for them. That may mean that some use cases don't fit
> anymore,
> >> >> but
> >> >> that is already the case.
> >> >>
> >> >> --
> >> >> Pieter
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20150811/68f2cc6f/attachment-0001.html>

2023-06-07 17:33:46

- reply

📅 Original date posted:2015-08-11
📝 Original message:The only reason why Bitcoin has grown the way it has, and in fact the only
reason why we're all even here on this mailing list talking about this, is
because Bitcoin is growing, since it's "better money than other money". One
of the key characteristics toward that is Bitcoin being inexpensive to
transact. If that characteristic is no longer true, then Bitcoin isn't
going to grow, and in fact Bitcoin itself will be replaced by better money
that is less expensive to transfer.
So the importance of this issue cannot be overstated -- it's compete or die
for Bitcoin -- because people want to transact with global consensus at
high volume, and because technology exists to service that want, then it's
going to be met. This is basic rules of demand and supply. I don't
necessarily disagree with your position on only wanting to support
uncontroversial commits, but I think it's important to get consensus on the
criticality of the block size issue: do you agree, disagree, or not take a
side, and why?
On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> question at hand is whether we should constrain that limit below what
>> technology is capable of delivering. I'm arguing that not only we should
>> not, but that we could not even if we wanted to, since competition will
>> deliver capacity for global consensus whether it's in Bitcoin or in some
>> other product / fork.
>>
>
> The question is not what the technology can deliver. The question is what
> price we're willing to pay for that. It is not a boolean "at this size,
> things break, and below it, they work". A small constant factor increase
> will unlikely break anything in the short term, but it will come with
> higher centralization pressure of various forms. There is discussion about
> whether these centralization pressures are significant, but citing that
> it's artificially constrained under the limit is IMHO a misrepresentation.
> It is constrained to aim for a certain balance between utility and risk,
> and neither extreme is interesting, while possibly still "working".
>
> Consensus rules are what keeps the system together. You can't simply
> switch to new rules on your own, because the rest of the system will end up
> ignoring you. These rules are there for a reason. You and I may agree about
> whether the 21M limit is necessary, and disagree about whether we need a
> block size limit, but we should be extremely careful with change. My
> position as Bitcoin Core developer is that we should merge consensus
> changes only when they are uncontroversial. Even when you believe a more
> invasive change is worth it, others may disagree, and the risk from
> disagreement is likely larger than the effect of a small block size
> increase by itself: the risk that suddenly every transaction can be spent
> twice (once on each side of the fork), the very thing that the block chain
> was designed to prevent.
>
> My personal opinion is that we should aim to do a block size increase for
> the right reasons. I don't think fear of rising fees or unreliability
> should be an issue: if fees are being paid, it means someone is willing to
> pay them. If people are doing transactions despite being unreliable, there
> must be a use for them. That may mean that some use cases don't fit
> anymore, but that is already the case.
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/becc6fff/attachment.html>

2023-06-07 17:33:45

- reply

📅 Original date posted:2015-08-11
📝 Original message:Jorge, As long as Bitcoin remains the best global consensus network -- and
part of being best means being reasonably priced -- then no I don't think
people will be pushed into altcoins. Better money ultimately displaces
worse money, so I don't see a driving force for people to move to other
altcoins as long as Bitcoin remains competitive.
Hitting the limit in and of itself is not necessarily a bad thing. The
question at hand is whether we should constrain that limit below what
technology is capable of delivering. I'm arguing that not only we should
not, but that we could not even if we wanted to, since competition will
deliver capacity for global consensus whether it's in Bitcoin or in some
other product / fork.
On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Aug 11, 2015 8:46 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
> >
> > Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
>
> Even if you are right, first fees will raise and that will be what pushes
> people to other altcoins, no?
> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/c8097503/attachment.html>

2023-06-07 17:33:45

- reply

📅 Original date posted:2015-08-11
📝 Original message:Lightning *depends* on global consensus in order to function. You can't use
it without a global consensus network at all. So given that there is
absolutely a place for a global consensus network, we need to decide
whether the cost to participate in that global consensus will be limited
above or below the capability of technology. In a world where anybody can
step up and fork the code, it's going to be hard for anyone to artificially
set the price of participating in global consensus at a rate higher than
what technology can deliver...
On Tue, Aug 11, 2015 at 1:51 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Note that lightning / hub and spoke do not meet requirements for users
> > wishing to participate in global consensus, because they are not global
> > consensus networks, since all participating nodes are not aware of all
> > transactions.
>
> You don't need consensus on the lightning network because you are
> using bitcoin consensus anyway. Commitment transactions are deep
> enough in the blockchain history that removing that transaction from
> the history is impractical. The remaining guarantees are ensured by
> the properties of the scripts in the transaction. You don't need to
> see all the transactions, but you do need to look at the transactions
> you are given and draw conclusions based on the details to see whether
> their commitments are valid or the setup wasn't broken.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/461e58f0/attachment.html>

2023-06-07 17:33:44

- reply

📅 Original date posted:2015-08-11
📝 Original message:Re: "In my opinion the main source of disagreement is that one: how the
maximum block size limits centralization."
I generally agree with that, but I would add that centralization is only a
goal insofar as it serves things like reliability, transaction integrity,
capacity, and accessibility. More broadly: how do you think that moving the
block size from 1MB to 8MB would materially impact these things?
Re: "That's why I cannot understand the urgency to rise the maximum size."
This issue is urgent because the difference between bitcoin being a success
and it being forgotten hinges on it being "better money" than other money.
If people want a money that can process lots and lots of transactions at
low cost, they're going to get it so long as technology can give it to
them. While it's not critical we raise the block size this very moment
since we're not hitting the capacity wall right now, based on the way
growth spikes in Bitcoin have occurred in the past we, may hit that
capacity wall soon and suddenly. And the moment we do, then Bitcoin may no
longer be "better money" since there's a big opportunity for other money
with higher throughput and lower fees to take its place.
On Tue, Aug 11, 2015 at 2:45 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
> >
> > It generally doesn't matter that every node validate your coffee
> transaction, and those transactions can and will probably be moved onto
> offchain solutions in order to avoid paying the cost of achieving global
> consensus. But you still don't get to set the cost of global consensus
> artificially. Market forces will ensure that supply will meet demand there,
> so if there is demand for access to global consensus, and technology exists
> to meet that demand at a cost of one cent per transaction -- or whatever
> the technology-limited cost of global consensus happens to be -- then
> that's what the market will supply.
>
> Assuming we maintain any block size maximum consensus rule, the market
> will adapt to whatever maximum size is imposed by the consensus rules.
> For example, with the current demand and the current consensus block size
> maximum, the market has settled on a minimum fee of zero satoshis per
> transaction. That's why I cannot understand the urgency to rise the maximum
> size.
>
> In any case, yhe consensus maximum shouldn't be based on current or
> projected demand, only on centralization concerns, which is what the
> consensus rule serves for (to limit centralization).
> For example, Gavin advocates for 20 MB because he is not worried about how
> that could increase centralization because he believes it won't.
> I can't agree with that because I believe 20 MB could make mining
> centralization (and centralization in general) much worse.
>
> But if I have to chose between 2 "centralization safe" sizes, sure, the
> bigger the better, why not.
> In my opinion the main source of disagreement is that one: how the maximum
> block size limits centralization.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/214ee358/attachment.html>

2023-06-07 17:33:43

- reply

📅 Original date posted:2015-08-11
📝 Original message:It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.
It would be like if Amazon suddenly said that they were going to be
charging $5 / gb / month to store data in s3. Can't do it. Technology
exists to bring about cloud storage at $0.01 / GB / month, so they don't
just get to set the price different from the capabilities of technology or
they'll get replaced by a competitor. Same applies to Bitcoin.
On Tue, Aug 11, 2015 at 1:48 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Michael, why does it matter that every node in the world process and
> validate your morning coffee transaction? Why does it matter to anyone
> except you and the coffee vendor?
>
> On Tue, Aug 11, 2015 at 11:46 AM, Michael Naber via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Jorge: Many people would like to participate in a global consensus
>> network -- which is a network where all the participating nodes are aware
>> of and agree upon every transaction. Constraining Bitcoin capacity below
>> the limits of technology will only push users seeking to participate in a
>> global consensus network to other solutions which have adequate capacity,
>> such as BitcoinXT or others. Note that lightning / hub and spoke do not
>> meet requirements for users wishing to participate in global consensus,
>> because they are not global consensus networks, since all participating
>> nodes are not aware of all transactions.
>>
>>
>>
>>
>> On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
>>> > > Gavin, I interpret the absence of response to these questions as a
>>> > > sign that everybody agrees that there's no other reason to increase
>>> > > the consensus block size other than to avoid minimum market fees from
>>> > > rising (above zero).
>>> > > Feel free to correct that notion at any time by answering the
>>> > > questions yourself.
>>> > > In fact if any other "big block size advocate" thinks there's more
>>> > > reason I would like to hear their reasons too.
>>> >
>>> > See my various emails in the last hour.
>>>
>>> I've read them. I have read gavin's blog posts as well, several times.
>>> I still don't see what else can we fear from not increasing the size
>>> apart from fees maybe rising and making some problems that need to be
>>> solved rewardless of the size more visible (like a dumb unbounded mempool
>>> design).
>>>
>>> This discussion is frustrating for everyone. I could also say "This have
>>> been explained many times" and similar things, but that's not productive.
>>> I'm not trying to be obstinate, please, answer what else is to fear or
>>> admit that all your feas are just potential consequences of rising fees.
>>>
>>> With the risk of sounding condescending or aggressive...Really, is not
>>> that hard to answer questions directly and succinctly. We should all be
>>> friends with clarity. Only fear, uncertainty and doubt are enemies of
>>> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
>>> do you?
>>> Please, prove paranoid people like me wrong on this point, for the good
>>> of this discussion. I really don't know how else to ask this without
>>> getting a link to something I have already read as a response.
>>>
>>> _______________________________________________
>>> 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/20150811/4b7c55dd/attachment.html>

2023-06-07 17:33:42

- reply

📅 Original date posted:2015-08-11
📝 Original message:Hi Jorge: Many people would like to participate in a global consensus
network -- which is a network where all the participating nodes are aware
of and agree upon every transaction. Constraining Bitcoin capacity below
the limits of technology will only push users seeking to participate in a
global consensus network to other solutions which have adequate capacity,
such as BitcoinXT or others. Note that lightning / hub and spoke do not
meet requirements for users wishing to participate in global consensus,
because they are not global consensus networks, since all participating
nodes are not aware of all transactions.
On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
> > > Gavin, I interpret the absence of response to these questions as a
> > > sign that everybody agrees that there's no other reason to increase
> > > the consensus block size other than to avoid minimum market fees from
> > > rising (above zero).
> > > Feel free to correct that notion at any time by answering the
> > > questions yourself.
> > > In fact if any other "big block size advocate" thinks there's more
> > > reason I would like to hear their reasons too.
> >
> > See my various emails in the last hour.
>
> I've read them. I have read gavin's blog posts as well, several times.
> I still don't see what else can we fear from not increasing the size apart
> from fees maybe rising and making some problems that need to be solved
> rewardless of the size more visible (like a dumb unbounded mempool design).
>
> This discussion is frustrating for everyone. I could also say "This have
> been explained many times" and similar things, but that's not productive.
> I'm not trying to be obstinate, please, answer what else is to fear or
> admit that all your feas are just potential consequences of rising fees.
>
> With the risk of sounding condescending or aggressive...Really, is not
> that hard to answer questions directly and succinctly. We should all be
> friends with clarity. Only fear, uncertainty and doubt are enemies of
> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
> do you?
> Please, prove paranoid people like me wrong on this point, for the good of
> this discussion. I really don't know how else to ask this without getting a
> link to something I have already read as a response.
>
> _______________________________________________
> 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/20150811/ec6892eb/attachment.html>

2023-06-07 17:33:23

- reply

📅 Original date posted:2015-08-06
📝 Original message:How many nodes are necessary to ensure sufficient network reliability? Ten,
a hundred, a thousand? At what point do we hit the point of diminishing
returns, where adding extra nodes starts to have negligible impact on the
overall reliability of the system?
On Thu, Aug 6, 2015 at 10:26 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille at gmail.com>
>> wrote:
>>
>>> So if we would have 8 MB blocks, and there is a sudden influx of users
>>> (or settlement systems, who serve much more users) who want to pay high
>>> fees (let's say 20 transactions per second) making the block chain
>>> inaccessible for low fee transactions, and unreliable for medium fee
>>> transactions (for any value of low, medium, and high), would you be ok with
>>> that?
>>
>>
>> Yes, that's fine. If the network cannot handle the transaction volume
>> that people want to pay for, then the marginal transactions are priced out.
>> That is true today (otherwise ChangeTip would be operating on-blockchain),
>> and will be true forever.
>>
>
> The network can "handle" any size. I believe that if a majority of miners
> forms SPV mining agreements, then they are no longer affected by the block
> size, and benefit from making their blocks slow to validate for others (as
> long as the fee is negligable compared to the subsidy). I'll try to find
> the time to implement that in my simulator. Some hardware for full nodes
> will always be able to validate and index the chain, so nobody needs to run
> a pesky full node anymore and they can just use a web API to validate
> payments.
>
> Being able the "handle" a particular rate is not a boolean question. It's
> a question of how much security, centralization, and risk for systemic
> error we're willing to tolerate. These are not things you can just observe,
> so let's keep talking about the risks, and find a solution that we agree on.
>
>
>>
>>> If so, why is 8 MB good but 1 MB not? To me, they're a small constant
>>> factor that does not fundamentally improve the scale of the system.
>>
>>
>> "better is better" -- I applaud efforts to fundamentally improve the
>> scalability of the system, but I am an old, cranky, pragmatic engineer who
>> has seen that successful companies tackle problems that arise and are
>> willing to deploy not-so-perfect solutions if they help whatever short-term
>> problem they're facing.
>>
>
> I don't believe there is a short-term problem. If there is one now, there
> will be one too at 8 MB blocks (or whatever actual size blocks are
> produced).
>
>
>>
>>
>>> I dislike the outlook of "being forever locked at the same scale" while
>>> technology evolves, so my proposal tries to address that part. It
>>> intentionally does not try to improve a small factor, because I don't think
>>> it is valuable.
>>
>>
>> I think consensus is against you on that point.
>>
>
> Maybe. But I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.
>
> --
> Pieter
>
>
> _______________________________________________
> 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/20150806/067e62ee/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-01
📝 Original message:This is great: Adam agrees that we should scale the block size limit
discretionarily upward within the limits of technology, and continually so
as hardware improves. Peter and others: What stands in the way of broader
consensus on this?
We also agree on a lot of other important things:
-- block size is not a free variable
-- there are trade-offs between node requirements and block size
-- those trade-offs have impacts on decentralization
-- it is important to keep decentralization strong
-- computing technology is currently not easily capable of running a global
transaction network where every transaction is broadcast to every node
-- we may need some solution (perhaps lightning / hub and spoke / other
things) that can help with this
We likely also agree that:
-- whatever that solution may be, we want bitcoin to be the "hub" / core of
it
-- this hub needs to exhibit the characteristic of globally aware global
consensus, where every node knows about (awareness) and agrees on
(consensus) every transaction
-- Critically, the Bitcoin Core Goal: the goal of Bitcoin core is to build
the "best" globally aware globally consensus network, recognizing there are
complex tradeoffs in doing this.
There are a few important things we still don't agree on though. Our
disagreement on these things is causing us to have trouble making progress
meeting the goal of Bitcoin Core. It is critical we address the following
points of disagreement. Please help get agreement on these issues below by
sharing your thoughts:
1) Some believe that fees and therefore hash-rate will be high by limiting
capacity, and that we need to limit capacity to have a "healthy fee market".
Think of the airplane analogy: If some day technology exists to ship a
hundred million people (transactions) on a plane (block) then do you really
want to fight to outlaw those planes? Airlines are regulated so they have
to pay to screen each passenger to a minimum standard, so even if the plane
has unlimited capacity, they still have to pay to meet minimum security for
each passenger.
Just like we can set the block limit, so can we "regulate the airline
security requirements" and set a minimum fee size for the sake of security.
If technology allows running 100,000 transactions per second in 25 years,
and we set the minimum fee size to one penny, then each block is worth a
minimum of $600,000. Miners should be ok with that and so should everyone
else.
2) Some believe that it is better for (a) network reliability and (b)
validation of transaction integrity, to have every user run a "full node"
in order to use Bitcoin Core.
I don't agree with this. I'll break this into two pieces of network
reliability and transaction integrity.
Network Reliability
Imagine you're setting up an email server for a big company. You decide to
set up a main server, and two fail-over servers. Somebody says that they're
really concerned about reliability and asks you to add another couple
fail-over servers. So you agree. But at some point there's limited benefit
to adding more servers: and there's real cost -- all those servers need to
keep in sync with one another, and they need to be maintained, etc. And
there's limited return: how likely is it really that all those servers are
going to go down?
Bitcoin is obviously different from corporate email servers. In one sense,
you've got miners and volunteer nodes rather than centrally managed ones,
so nodes are much more likely to go down. But at the end of the day, is our
up-time really going to be that much better when you have a million nodes
versus a few thousand?
Cloud storage copies your data a half dozen times to a few different data
centers. But they don't copy it a half a million times. At some point the
added redundancy doesn't matter for reliability. We just don't need
millions of nodes to participate in a broadcast network to ensure network
reliability.
Transaction Integrity
Think of open source software: you trust it because you know it can be
audited easily, but you probably don't take the time to audit yourself
every piece of open source software you use. And so it is with
Bitcoin: People need to be able to easily validate the blockchain, but they
don't need to be able to validate it every time they use it, and they
certainly don't need to validate it when using Bitcoin on their Apple
watches.
If I can lease a server in a data center for a few hours at fifty cents an
hour to validate the block chain, then the total cost for me to
independently validate the blockchain is just a couple dollars. Compare
that to my cost to independently validate other parts of the system -- like
the source code! Where's the real cost here?
If the goal of decentralization is to ensure transaction integrity and
network reliability, then we just don't need lots of nodes or every user
running a node to meet that goal. If the goal of decentralization is
something else: what is it?
3) Some believe that we should make Bitcoin Core to run as a high-memory
server-grade software rather than for people's desktops.
I think this is a great idea.
The meaningful impact to the goals of decentralization by limiting which
hardware nodes can run on will be minimal compared with the huge gains in
capacity. Why does increasing capacity of Bitcoin Core matter when we can
"increase capacity" by moving to hub and spoke / lightning? Maybe we should
ask why does growing more apples matter if we can grow more oranges instead?
Hub and spoke and lightning are useful means of making lower cost
transactions, but they're not the same as Bitcoin Core. Stick to the goal:
the goal of Bitcoin core is to build the "best" globally aware globally
consensus network, recognizing there are complex tradeoffs in doing this.
Hub and spoke and lightning could be great when you want lower-cost fees
and don't really care about global awareness. Poker chips are great when
you're in a casino. We don't talk about lightning networks to the guy who
designs poker chips, and we shouldn't be talking about them to the guy who
builds globally aware consensus networks either.
Do people even want increased capacity when they can use hub and spoke /
lightning? If you think they might be willing to pay $600,000 every ten
minutes for it (see above) then yes. Increase capacity, and let the market
decide if that capacity gets used.
On Tue, Jun 30, 2015 at 3:54 PM, Adam Back <adam at cypherspace.org> wrote:
> Not that I'm arguing against scaling within tech limits - I agree we
> can and should - but note block-size is not a free variable. The
> system is a balance of factors, interests and incentives.
>
> As Greg said here
>
> https://www.reddit.com/r/Bitcoin/comments/3b0593/to_fork_or_not_to_fork/cshphic?context=3
> there are multiple things we should usefully do with increased
> bandwidth:
>
> a) improve decentralisation and hence security/policy
> neutrality/fungibility (which is quite weak right now by a number of
> measures)
> b) improve privacy (privacy features tend to consume bandwidth, eg see
> the Confidential Transactions feature) or more incremental features.
> c) increase throughput
>
> I think some of the within tech limits bandwidth should be
> pre-allocated to decentralisation improvements given a) above.
>
> And I think that we should also see work to improve decentralisation
> with better pooling protocols that people are working on, to remove
> some of the artificial centralisation in the system.
>
> Secondly on the interests and incentives - miners also play an
> important part of the ecosystem and have gone through some lean times,
> they may not be overjoyed to hear a plan to just whack the block-size
> up to 8MB. While it's true (within some limits) that miners could
> collectively keep blocks smaller, there is the ongoing reality that
> someone else can take break ranks and take any fee however de minimis
> fee if there is a huge excess of space relative to current demand and
> drive fees to zero for a few years. A major thing even preserving
> fees is wallet defaults, which could be overridden(plus protocol
> velocity/fee limits).
>
> I think solutions that see growth scale more smoothly - like Jeff
> Garzik's and Greg Maxwell's and Gavin Andresen's (though Gavin's
> starts with a step) are far less likely to create perverse unforeseen
> side-effects. Well we can foresee this particular effect, but the
> market and game theory can surprise you so I think you generally want
> the game-theory & market effects to operate within some more smoothly
> changing caps, with some user or miner mutual control of the cap.
>
> So to be concrete here's some hypotheticals (unvalidated numbers):
>
> a) X MB cap with miner policy limits (simple, lasts a while)
> b) starting at 1MB and growing to 2*X MB cap with 10%/year growth
> limiter + policy limits
> c) starting at 1MB and growing to 3*X MB cap with 15%/year growth
> limiter + Jeff Garzik's miner vote.
> d) starting at 1MB and growing to 4*X MB cap with 20%/year growth
> limiter + Greg Maxwell's flexcap
>
> I think it would be good to see some tests of achievable network
> bandwidth on a range of networks, but as an illustration say X is 2MB.
>
> Rationale being the weaker the signalling mechanism between users and
> user demanded size (in most models communicated via miners), the more
> risk something will go in an unforeseen direction and hence the lower
> the cap and more conservative the growth curve.
>
> 15% growth limiter is not Nielsen's law by intent. Akamai have data
> on what they serve, and it's more like 15% per annum, but very
> variable by country
>
> http://www.akamai.com/stateoftheinternet/soti-visualizations.html#stoi-graph
> CISCO expect home DSL to double in 5 years
> (
> http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.html
> ), which is about the same number.
>
> (Thanks to Rusty for data sources for 15% number).
>
> This also supports the claim I have made a few times here, that it is
> not realistic to support massive growth without algorithmic
> improvement from Lightning like or extension-block like opt-in
> systems. People who are proposing that we ramp blocksizes to create
> big headroom are I think from what has been said over time, often
> without advertising it clearly, actually assuming and being ok with
> the idea that full nodes move into data-centers period and small
> business/power user validation becomes a thing of the distant past.
> Further the aggressive auto-growth risks seeing that trend continuing
> into higher tier data-centers with negative implications for
> decentralisation. The odd proponent seems OK with even that too.
>
> Decentralisation is key to Bitcoin's security model, and it's
> differentiating properties. I think those aggressive growth numbers
> stray into the zone of losing efficiency. By which I mean in
> scalability or privacy systems if you make a trade-off too far, it
> becomes time to re-asses what you're doing. For example at that level
> of centralisation, alternative designs are more network efficient,
> while achieving the same effective (weak) decentralisation. In
> Bitcoin I see this as a strong argument not to push things to that
> extreme, the core functionality must remain for Lightning and other
> scaling approaches to remain secure by using the Bitcoin as a secure
> anchor. If we heavily centralise and weaken the security of the main
> Bitcoin chain, there remains nothing secure to build on.
>
> Therefore I think it's more appropriate for high scale to rely on
> lightning, or a semi-centralised trade-offs being in the side-chain
> model or similar, where the higher risk of centralisation is opt-in
> and not exposed back (due to the security firewall) to the Bitcoin
> network itself.
>
> People who would like to try the higher tier data-center and
> throughput by high bandwidth use route should in my opinion run that
> experiment as a layer 2 side-chain or analogous. There are a few ways
> to do that. And it would be appropriate to my mind that we discuss
> them here also.
>
> An experiment like that could run in parallel with lightning, maybe it
> could be done faster, or offer different trade-offs, so could be an
> interesting and useful thing to see work on.
>
> > On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete at petertodd.org> wrote:
> >> Which of course raises another issue: if that was the plan, then all you
> >> can do is double capacity, with no clear way to scaling beyond that.
> >> Why bother?
>
> A secondary function can be a market signalling - market evidence
> throughput can increase, and there is a technical process that is
> effectively working on it. While people may not all understand the
> trade-offs and decentralisation work that should happen in parallel,
> nor the Lightning protocol's expected properties - they can appreciate
> perceived progress and an evidently functioning process. Kind of a
> weak rationale, from a purely technical perspective, but it may some
> value, and is certainly less risky than a unilateral fork.
>
> As I recall Gavin has said things about this area before also
> (demonstrate throughput progress to the market).
>
> Another factor that people have said, which I think I agree with
> fairly much is that if we can chose something conservative, that there
> is wide-spread support for, it can be safer to do it with moderate
> lead time. Then if there is an implied 3-6mo lead time we are maybe
> projecting ahead a bit further on block-size utilisation. Of course
> the risk is we overshoot demand but there probably should be some
> balance between that risk and the risk of doing a more rushed change
> that requires system wide upgrade of all non-SPV software, where
> stragglers risk losing money.
>
> As well as scaling block-size within tech limits, we should include a
> commitment to improve decentralisation, and I think any proposal
> should be reasonably well analysed in terms of bandwidth assumptions
> and game-theory. eg In IETF documents they have a security
> considerations section, and sometimes a privacy section. In BIPs
> maybe we need a security, privacy and decentralisation/fungibility
> section.
>
> Adam
>
> NB some new list participants may not be aware that miners are
> imposing local policy limits eg at 750kB and that a 250kB policy
> existed in the past and those limits saw utilisation and were
> unilaterally increased unevenly. I'm not sure if anyone has a clear
> picture of what limits are imposed by hash-rate even today. That's
> why Pieter posed the question - are we already at the policy limit -
> maybe the blocks we're seeing are closely tracking policy limits, if
> someone mapped that and asked miners by hash-rate etc.
>
> On 30 June 2015 at 18:35, Michael Naber <mickeybob at gmail.com> wrote:
> > Re: Why bother doubling capacity? So that we could have 2x more network
> > participants of course.
> >
> > Re: No clear way to scaling beyond that: Computers are getting more
> capable
> > aren't they? We'll increase capacity along with hardware.
> >
> > It's a good thing to scale the network if technology permits it. How can
> you
> > argue with that?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/6d43b13a/attachment-0001.html>

2023-06-07 15:41:18

- reply

📅 Original date posted:2015-06-30
📝 Original message:Re: Why bother doubling capacity? So that we could have 2x more network
participants of course.
Re: No clear way to scaling beyond that: Computers are getting more capable
aren't they? We'll increase capacity along with hardware.
It's a good thing to scale the network if technology permits it. How can
you argue with that?
On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
> > > Do what's best for Bitcoin and define what needs to get done to
> > > agree to a simple block size increase to a static 8MB.
> >
> > And this then leads back to the core issue: if an 8MB blocksize
> > excludes many on this list from testnet, then the proposed 8MB blocks
> > will exclude a lot of mainnet participants (miners) and degrade the
> > quality of diversity and decentralization.
> >
> > How about testing at double the capacity: 2MB?
>
> Which of course raises another issue: if that was the plan, then all you
> can do is double capacity, with no clear way to scaling beyond that.
> Why bother?
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/f0f4be16/attachment.html>

2023-06-07 15:41:17

- reply

📅 Original date posted:2015-06-30
📝 Original message:As you know I'm trying to lobby for a block size increase to a static 8MB.
I'm happy to try to get the testing done that people want done for this,
but I think the real crux of this issue is that we need to get consensus
that we intend to continually push the block size upward as bounded only by
technology.
Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going to
build an airplane (block) that was going to move 8x as many people
(transactions) as today’s planes (blocks), all while costing about the same
amount to operate. Imagine he then went on to tell you that he expects to
double the plane’s (block's) capacity every two years!
Without full planes (blocks), will the airlines (miners) go out of
business, since planes (blocks) will never be full and the cost to add
people (transactions) to a plane (block) will approach zero? Probably not.
Airlines (miners) still have to pay for pilots, security screening staff,
fuel, etc (engineers, hash rate, electricity, etc) so even if their
airplanes (blocks) can hold limitless people (transactions), they would
still have to charge sufficient fees to stay in business.
What tests do you need done to move to 8MB? Pitch in and help get those
tests done; agree that we'll run more tests next year or the year after
when technology might allow for 16 MB blocks. Do you really want to be the
guy holding back bigger planes? Do you really want to artificially
constrain block size below what technology allows?
In the face of such strong market demand for increased capacity in globally
aware global consensus, do you really think you can prevent supply from
meeting demand when the technology exists to deliver it? Do you really want
to force a fork because you and others won't agree to a simple raise to a
static 8MB?
Do what's best for Bitcoin and define what needs to get done to agree to a
simple block size increase to a static 8MB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/aebb2579/attachment.html>

2023-06-07 15:41:16

- reply

📅 Original date posted:2015-06-29
📝 Original message:Bitcoin is globally aware global consensus.
It means every node both knows about and agrees on every transaction.
Do we need global awareness of every transaction to run a worldwide payment network? Of course not! In fact the limits of today's technology probably would not even allow it.
Global awareness is a finite resource. That's okay; hub and spoke, or other clever designs are going to ensure we can run worldwide transactions without requiring global awareness. That's great!
But even if we have hub and spoke, we still need a "hub" at the center. Bitcoin Core needs to focus on being that hub. It needs to be the best globally aware global consensus network that we can build. Let's put aside our differences and focus on this goal.
Part of building the best network means ensuring that network can operate at the highest capacity technology can allow.
If we run the test-net to show that hardware exists today to safely increase block size to a static 8 MB, then we will have broad developer support to make this happen.
Let's get that done. We can continue to adjust the block size upward in the future as technology permits.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/fbeea316/attachment.html>

2023-06-07 15:40:57

- reply

📅 Original date posted:2015-06-28
📝 Original message:Bitcoin Core exists to solve the global consensus problem. Global network
consensus means that there is global network recognition that a particular
transaction has occurred and is irreversible. Systems like hub-and-spoke,
payment channels, Lightning, etc. are useful, but they are not solutions to
the global consensus problem, because they do not meet this definition of
global consensus.
Let us focus our efforts on the goal of making Bitcoin Core the best
solution to the global consensus problem. Let us address Peter Todd’s
requirements to raise the block size limit to 8MB:
1) Run a successful test-net with 8MB blocks and show that the network
works and small miners are not unduly disadvantaged
2) Address Peter Todd's concern: “without scarcity of blockchain space
there is no reason to think that transaction fees won’t fall to the
marginal cost of including a transaction, which doesn’t leave anything to
pay for proof-of-work security”
Regarding 1: This is not done yet, though it seems reasonable enough to do.
Regarding 2: It is a fallacy to believe that artificially constraining
capacity of Bitcoin Core below the limits of technology will lead to
increased fees and therefore lead to sufficient security in the far-future.
Constraining capacity below the limits of technology will ultimately only
drive users seeking global consensus to solutions other than Bitcoin Core,
perhaps through a fork.
Demand for user access to high-capacity global consensus is real, and the
technology exists to deliver it; if we don't meet that demand in Bitcoin
Core, it's inevitably going to get met through some other product. Let's
not let that happen. Let's keep Bitcoin Core the best solution to the
global consensus problem.
Thoughts? Is there anything else not mentioned above which anyone would
like done in order to raise the block size to a static 8 MB?
On Sun, Jun 28, 2015 at 5:05 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>
>> This is probably going to sound impolite, but I think it's pertinent.
>>
>> Gavin, on dwelling on the the fact that you appear to not understand
>> the basics of the lightning network, I am a little alarmed about this
>
>
> If I don't see how switching from using the thousands of fully-validating
> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
> terms of decentralization (or security, in terms of Sybil/DoS attacks),
> then I doubt other people do, either. You need to do a better job of
> explaining it.
>
> But even if you could convince me that it WAS better from a
> security/decentralization point of view:
>
> a) Lightning Network is nothing but a whitepaper right now. We are a long
> way from a practical implementation supported by even one wallet.
>
> b) The Lightning Network paper itself says bigger blocks will be needed
> even if (especially if!) Lightning is wildly successful.
>
>
>
> _______________________________________________
> 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/20150628/1bff0d26/attachment.html>

2023-06-07 15:40:52

- reply

📅 Original date posted:2015-06-27
📝 Original message:Global network consensus means that there is global network recognition
that a particular transaction has occurred and is irreversible. The
off-chain solutions you describe, while probably useful for other purposes,
do not exhibit this characteristic and so they are not global network
consensus networks.
Bitcoin Core scales as O(N), where N is the number of transactions. Can we
do better than this while still achieving global consensus?
On Sat, Jun 27, 2015 at 12:37 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 12:09:16PM -0400, Michael Naber wrote:
> > The goal of Bitcoin Core is to meet the demand for global consensus as
> > effectively as possible. Please let's keep the conversation on how to
> best
> > meet that goal.
>
> Keep in mind that Andresen and Hearn both propose that the majority of
> Bitcoin users, even businesses, abandon the global consensus technology
> aspect of Bitcoin - running full nodes - and instead adopt trust
> technology instead - running SPV nodes.
>
> We're very much focused on meeting the demand for global consensus
> technology, but unfortunately global consensus is also has inherently
> O(n^2) scaling with current approaches available. Thus we have a fixed
> capacity system where access is mediated by supply and demand
> transaction fees.
>
> > The off-chain solutions you enumerate are are useful solutions in their
> > respective domains, but none of them solves the global consensus problem
> > with any greater efficiency than Bitcoin does.
>
> Solutions like (hub-and-spoke) payment channels, Lightning, etc. allow
> users of the global consensus technology in Bitcoin to use that
> technology in much more effcient ways, leveraging a relatively small
> amount of global consensus to do large numbers of transactions
> trustlessly.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/4fed3514/attachment.html>

2023-06-07 15:40:51

- reply

📅 Original date posted:2015-06-27
📝 Original message:The goal of Bitcoin Core is to meet the demand for global consensus as
effectively as possible. Please let's keep the conversation on how to best
meet that goal.
The off-chain solutions you enumerate are are useful solutions in their
respective domains, but none of them solves the global consensus problem
with any greater efficiency than Bitcoin does.
On Sat, Jun 27, 2015 at 11:33 AM, Adam Back <adam at cypherspace.org> wrote:
> Michael Naber wrote:
> > Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,
> distributed, fastest, overall best solution possible to the global
> consensus problem.
>
> Everyone here is excited about the potential of Bitcoin and would
> aspirationally like it to reach its full potential as fast as
> possible. But the block-size is not a free variable, half those
> parameters you listed are in conflict with each other. We're trying
> to improve both decentralisation and throughput short-term while
> people work on algorithmic improvements mid-term. If you are
> interested you can take a look through the proposals:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html
>
> Note that probably 99% of Bitcoin transactions already happen
> off-chain in exchanges, tipping services, hosted wallets etc. Maybe
> you're already using them, assuming you are a bitcoin user.
> They constitute an early stage layer 2, some of them even have on
> chain netting and scale faster than the block-chain.
>
> You can also read about layer 2, the lightning network paper and the
> duplex micropayment channel paper:
>
> http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
> and read the development list and look at the code:
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
> https://github.com/ElementsProject/lightning
>
> Adam
>
>
> On 27 June 2015 at 16:39, Michael Naber <mickeybob at gmail.com> wrote:
> > Demand to participate in a low-fee global consensus network will likely
> > continue to rise. Technology already exists to meet that rising demand
> using
> > a blockchain with sufficient block size. Whether that blockchain is
> Bitcoin
> > Core with an increased block size, or whether it is a fork, market forces
> > make it almost certain that demand will be met by a blockchain with
> adequate
> > capacity. These forces ensure that not only today’s block size will be
> > increased, but also that future increases will occur should the demand
> > arise.
> >
> > In order to survive, Bitcoin Core must remain the lowest-fee,
> > highest-capacity, most secure, distributed, fastest, overall best
> solution
> > possible to the global consensus problem. Attempting to artificially
> > constrain the block size below the limits of technology for any reason
> is a
> > conflict with this objective and a threat to the survival of Bitcoin
> Core.
> > At the same time, scheduling large future increases or permitting
> unlimited
> > dynamic scaling of the block size limit raises concerns over
> availability of
> > future computing resources. Instead, we should manually increase the
> block
> > size limit as demand occurs, except in the special case that increasing
> the
> > limit would cause an undue burden upon users wishing to validate the
> > integrity of the blockchain.
> >
> > Compromise: Can we agree that raising the block size to a static 8MB now
> > with a plan to increase it further should demand necessitate except in
> the
> > special case above is a reasonable path forward?
> >
> > _______________________________________________
> > 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/20150627/ec2e5cfc/attachment-0001.html>

2023-06-07 15:40:48

- reply

📅 Original date posted:2015-06-27
📝 Original message:That test seems like a reasonable suggestion; 840GB is not prohibitive
given today's computing costs. What other than the successful result of
that test would you want to see before agreeing to increase the block size
to 8MB?
On Sat, Jun 27, 2015 at 11:21 AM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 27 June 2015 10:39:51 GMT-04:00, Michael Naber <mickeybob at gmail.com>
> wrote:
> >Compromise: Can we agree that raising the block size to a static 8MB
> >now
> >with a plan to increase it further should demand necessitate except in
> >the
> >special case above is a reasonable path forward?
>
> It's not a reasonable path forward right now given the lack of testing
> done with 8MB+ blocks, among many other problems. A way to help make that
> appear more reasonable would be to setup a 8MB testnet as I suggested, with
> two years or so of 8MB blocks in history as well as a large UTXO set to
> test performance characteristics.
>
> Of course, that'll be a 840GB download - if that's unreasonable you might
> want to ask why 8MB blocks are reasonable...
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVjr9n
> AAoJEMCF8hzn9Lnc47AIAIIwu4maaJs4pAKpK00jQnhPNIQ8LPvijD/8vvyugA1z
> OLxlRrn8zs7JPFbxWOAzK2qzT1RksSd0gbXqWm/Saqk9CAG5LBp7Oq0HAVE23XYt
> 6BvyhjyhYaZjDrv+SZvlSjdl5xfpDNPMIXMi7XblKD9hm1GIUSVIYAOinOSVIy0B
> HlKyn/xc4MaO8DuzQcs0vsNMudVQFLMOLjMWz/7iv41NnB/Ujjzv/6845Z1g7Opf
> d5AfxhPHZixshqav/lF7ly7xQwSZZpoJCyFdtzCNG47EQmFYY9e22uy1KVzS7Zeo
> qYPi3KRx5+vFtHHJMDYG5EIMTwI4l/4+lY/Sd0CFWss=
> =0IOS
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/405bf6a8/attachment.html>

2023-06-07 15:40:47

- reply

📅 Original date posted:2015-06-27
📝 Original message:Demand to participate in a low-fee global consensus network will likely
continue to rise. Technology already exists to meet that rising demand
using a blockchain with sufficient block size. Whether that blockchain is
Bitcoin Core with an increased block size, or whether it is a fork, market
forces make it almost certain that demand will be met by a blockchain with
adequate capacity. These forces ensure that not only today’s block size
will be increased, but also that future increases will occur should the
demand arise.
In order to survive, Bitcoin Core must remain the lowest-fee,
highest-capacity, most secure, distributed, fastest, overall best solution
possible to the global consensus problem. Attempting to artificially
constrain the block size below the limits of technology for any reason is a
conflict with this objective and a threat to the survival of Bitcoin Core.
At the same time, scheduling large future increases or permitting unlimited
dynamic scaling of the block size limit raises concerns over availability
of future computing resources. Instead, we should manually increase the
block size limit as demand occurs, except in the special case that
increasing the limit would cause an undue burden upon users wishing to
validate the integrity of the blockchain.
Compromise: Can we agree that raising the block size to a static 8MB now
with a plan to increase it further should demand necessitate except in the
special case above is a reasonable path forward?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/5e051f1b/attachment.html>

2023-06-07 15:33:53

- reply

📅 Original date posted:2015-05-08
📝 Original message:Why can't we have dynamic block size limit that changes with difficulty, such as the block size cannot exceed 2x the mean size of the prior difficulty period?
I recently subscribed to this list so my apologies if this has been addressed already.