<unnamed>

Public Key

npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4

Profile Code

nprofile1qqsg3kg37eu3lt7dfsj0xrrxxc8x7s7ua2qehrefg2urhh9s4fa52nqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wsq32amnwvaz7tmjv4kxz7fwdehhxarj9ehx2aqzfelsf

Publishing to

Last Notes

2023-06-07 17:35:20 UTC

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

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

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

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

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

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

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

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

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

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

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

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

2023-06-07 15:47:09 UTC

- reply

2023-06-07 15:46:00 UTC

- reply

2023-06-07 15:45:56 UTC

- reply

2023-06-07 15:45:54 UTC

- reply

2023-06-07 15:45:52 UTC

- reply

2023-06-07 15:45:51 UTC

- reply

2023-06-07 15:45:51 UTC

- reply

2023-06-07 15:45:51 UTC

- reply

2023-06-07 15:45:50 UTC

- reply

2023-06-07 15:45:49 UTC

- reply

2023-06-07 15:45:32 UTC

- reply

2023-06-07 15:40:57 UTC

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

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

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

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

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