[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Jared Lee Richardson jaredr26 at gmail.com
Tue Oct 10 02:36:22 UTC 2017


> We can scale highly if we used a central mint to solve double spend.

The implication of this is fundamentally not true.  Bitcoin can scale
hundreds of times past where we are today without any major risks or
impacts whatsoever.

> Somewhere between 2 nodes and billions of nodes lies a sweet spot that offers the utility of trade, in combination with the defense of corruptibility.

The number of fullnodes goes up as transaction volume goes up:
http://snap.stanford.edu/class/cs224w-2014/projects2014/cs224w-27-final.pdf

> Somewhere between 2 nodes and billions of nodes lies a sweet spot that offers the utility of trade, in combination with the defense of corruptibility.

Do you know what it is you are arguing in favor of?  Running a
fullnode can be done for less than $4.17 a month:
https://www.reddit.com/r/Bitcoin/comments/6yopwt/run_a_bitcoin_full_node_for_50_a_year/

It actually can be done for even less than THAT.

You're literally arguing the difference between $4.17 a month and $8 a
month.  Meanwhile, the average transaction fee paid 2 days ago was
$2.15, PER TRANSACTION.  If someone sends literally 2 transactions a
month, they are now paying more just to use Bitcoin than it costs to
run a fullnode.

That's pointless.  Fullnode costs actually scale remarkably well.  We
would have to scale hundreds of times above where we are today before
we begin to have problems regarding fullnodes -and probably not even
then due to the expanded ecosystem and adoption.

> Why dont we just agree the expert consensus is to increase capacity, but that the timeline for that is not yet agreed.

These "experts" have not provided any math to back up their claims,
and refuse to debate the issue when challenged.  Why does it matter if
5% of the fullnodes we have in operation shut down because of rising
costs?  How many fullnodes do we need?  How do we know when we have
too few nodes and the network is in danger?

These are the questions that should be asked and answered to justify
blocking the growth of the entire system.  Instead of answering, we
get down to fearmongering.  "If you don't run a fullnode, the
government can control Bitcoin!" and "If you run a fullnode in a
datacenter, that's not using Bitcoin!"  That line of thinking is
ridiculous.  If we're going to hold back the entire crypto ecosystem,
there needs to be a really good reason for it, and it needs to be
discussed **thoroughly** with numbers and risk evaluations of the
different options.

Answer me this, or get the answer from your experts.  If we were
willing to have pruned fullnode costs be $50 per month, how far could
Bitcoin scale?

The answer is pretty amazing.

Jared


On Mon, Oct 9, 2017 at 6:52 PM, Melvin Carvalho via Bitcoin-segwit2x
<bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>
> On 9 October 2017 at 22:27, Mike Belshe via Bitcoin-segwit2x
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>> Thanks for the lengthy reply.  Your argument can go both ways; why not
>> support this 2mb block size increase?  The risk has already been mitigated -
>> miners will adopt it, businesses will support it, and its compatible with
>> 99.5% of existing wallets. Now, if the core team would start trying to help
>> it work, instead of fighting it for pride and emotional reasons, we'd even
>> have all the developer support behind it....   There are no technical
>> arguments remaining against it - just lengthy prose about misunderstandings
>> and what not.
>>
>> You imply that planning for growth/scalability has a correlated risk of
>> destabilization that accompanies it.  If we took that as our guiding
>> principle, we wouldn't implement segwit either.  Sure, segwit is opt-in at
>> the user level, but its not opt-in at the chain level - we all are dependent
>> on it working properly or the chain which we share breaks for all of us. The
>> 2x part of Segwit2x is, by any measure, a simpler technical change.   I
>> would never say that changes carry no risk, but as far as risk goes, this
>> one is really small.
>>
>> It's a good opportunity now to just move to 2mb blocks, and there are
>> literally no technical objections left.
>
>
> Thanks for the insight
>
> There are technical arguments surrounding the argument of increasing the
> block size from "1MB" to "2MB", as such.
>
> These, imho, were well articulated by adam back at in his talk this weekend
> at the hcpp hackers congress [1].  I did raise a question on this topic at
> th end,
>
> We can scale highly if we used a central mint to solve double spend.
>
> Somewhere between 2 nodes and billions of nodes lies a sweet spot that
> offers the utility of trade, in combination with the defense of
> corruptibility.
>
> I think the consensus in core is to increase block size in a practical way
> with storage (ie moore's law).
>
> This whole problem is a timing question (assuming we stick with proof of
> work) and it also involves social issues.
>
> Why dont we just agree the expert consensus is to increase capacity, but
> that the timeline for that is not yet agreed.
>
> Heavy handed techniques are likely to be counter productive, when
> essentially most parties are in agreement.
>
> [1] https://www.youtube.com/watch?v=mmSuxqaKR2U
>
>>
>>
>> Mike
>>
>>
>>
>>
>> On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x
>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>
>>> Hello Mike, I understand that you're meaning well and want, as we all do,
>>> bitcoin to succeed over long term, and by reading your messages on this
>>> thread I've once again noticed that the current rift within the Bitcoin
>>> community actually springs from a few disagreements that have more to do
>>> with culture and process rather than with long term goals. I'm going to talk
>>> about those disagreements and hopefully state the "pro decentralisation"
>>> position in a way that's conducive to intelligent debate and perhaps,
>>> ultimate agreement.
>>>
>>> We want to bring Bitcoin to more users because it has unique features and
>>> qualities (namely permissionless-ness, resistance to tx censorship,
>>> resistance to inflation, pseudonymity) that the existing financial system
>>> doesn't offer. The presence of these features is contrary to the interests
>>> of many powerful entities (the legacy banking system, governments and their
>>> surveillance agencies) and only survive thanks to Bitcoin's decentralisation
>>> and absence of centralised points of failure. Being willing to sacrifice or
>>> endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward
>>> thinking, and is completely self-defeating. What's the point of on-boarding
>>> an ever greater number of users if you run the risk of weakening those
>>> features and give those users the same experience than current centralised
>>> paiement systems offer, e.g. tx censorship, vulnerability to inflation, and
>>> government surveillance? This would be a nonsensical and unproductive thing
>>> to do.
>>>
>>> Doing this would be all the more absurd that we now know (as we have
>>> since 2015) that, before increasing base block size, we can greatly increase
>>> throughput through more efficient of block space (with Segwit and, in the
>>> near future, with MAST, Schnorr signatures and signatures aggregation) and
>>> more importantly, with second layer technologies such as the Lightning
>>> Network or sidechains. These technologies are under rapid development, and
>>> will soon alleviate scaling.
>>>
>>> Presenting the scaling debate as a dichotomy between "onboard users fast
>>> and break things" and "let's for ever stay a store of value for rich people"
>>> is a mistake, because we know we can already greatly improve scaling, within
>>> the next few months and years. Was scaling slower than anticipated, we
>>> should err on the side of caution, and not give our potential adversaries
>>> any lever that they might pull to weaken those features.
>>>
>>> And this is why this scheduled hard fork worries me. Regardless of the
>>> blockchain bloating issue, changing consensus rules without wide community
>>> consensus - and in particular without the consensus of the community members
>>> that value decentralisation and privacy the most - is precisely such a lever
>>> for governments or other antagonists to pull.
>>> It would set an extremely bad precedent. The particulars of this fork -
>>> the fact that it doesn't have replay protection, that it lays a claim on the
>>> Bitcoin brand, that it relies on the imperfect security models of SPV
>>> wallets to make them follow new consensus rules - make things worse.
>>>
>>> if this fork is successful and the entire community shifts to the S2X
>>> chain (which, barring a prolonged 51% attack on the original chain, seems
>>> extremely unlikely to me), this would signals to external actors that
>>> consensus rules can be changed by exercising the right pressure on the right
>>> companies - and we're literally talking of a dozen mining pools and a dozen
>>> major paiement processors and exchanges, spread in only a few jurisdictions.
>>> This would cast doubt on the entire ability of cryptocurrencies to remain
>>> decentralised and act as censorship-resistant medium of exchange and
>>> inflation-resistant store of value. Bitcoin's sole comparative advantage
>>> over centralised systems would vanish.
>>>
>>> Even if this fork wasn't a base block size doubling but a simple,
>>> symbolic increase of one byte to base block size, it would still be a bad
>>> thing, because it would show that consensus rules - and therefore the very
>>> nature of the currency people use - can be changed by external actors. To me
>>> and to many other people, this debate isn't about block size anymore: it's
>>> about the survivability of Bitcoin as a decentralised system. The Bitcoin
>>> community should be as amorphous and resistant to change as possible - even
>>> to more technically sound changes like Segwit, and even when these changes
>>> come from competent devs with a solid track record of defending
>>> decentralisation and privacy.
>>>
>>> Just because only a few thousands or dozens of thousands of early users
>>> and cypherpunks out of a dozen million of users disagree with this fork
>>> doesn't mean we can be ignored: Bitcoin rose to its current popularity (and
>>> value) because we invested our time, our hopes and our money in it, and
>>> millions of politically unresponsive BitPay or Coinbase customers will not
>>> make up for our absence on a centralised chain.
>>>
>>> Claiming that Segwit2X has consensus with the now standard line "those
>>> who oppose it are only a few thousands, while NYA signatories have millions
>>> of customers" is akin to the NSA claiming that a majority of citizens
>>> endorses surveillance, "because only a few thousands nerds care about it".
>>> Claiming the silence of a majority of stakeholders as a tacit endorsement of
>>> some policy is a dangerous (and I would add immoral) thing to do, and is
>>> what has led to the creation of the centralised institutions that Bitcoin
>>> aims at replacing.
>>>
>>> Bitcoin is a formidable opportunity to bring greater monetary, economic
>>> and political freedom to all humans, and the single best hope of
>>> freedom-loving persons in this otherwise authoritarian and freedom-hating
>>> century. Regardless of whatever understanding or sympathy we may have for
>>> you and other NYA signatories, we who care about those things can not accept
>>> cooptation by companies who effectively are centralised points of failure at
>>> the mercy of governments.
>>>
>>> If I could sum up my position (and the position of many users preoccupied
>>> with decentralisation), it would be: "let us scale wisely, without making
>>> short-term compromises that would weaken Bitcoin's unique features". Merely
>>> increasing base block size as soon as we lack space would be akin to kicking
>>> the can down the road to serfdom. And changing consensus rules at a whim -
>>> or worse, engaging in a 51% attack to coerce the community into following
>>> the new rules - would get us there in no time.
>>>
>>> And to respond to one of your points, Mike, wishing for both chains to
>>> survive is certainly not about "pride": it's about giving a durable,
>>> decentralised consensus system to the world, a system that can't be coopted,
>>> coerced or censored.
>>>
>>> Mike, if you have any question or wish to continue this chat privately
>>> feel free to respond directly to this email. I feel that the differences
>>> between our respective camps are born out of cultural differences and absurd
>>> misunderstandings, and magnified by our good ol' tribal instincts; there is
>>> no reason why we should go through a messy divorce when we all agree on
>>> making Bitcoin the world's sole currency, used for both small purchases and
>>> storing large amount of values. This is Bitcoin's destiny, and our squabbles
>>> are petty in comparison.
>>>
>>> Cheers.
>>> Hubert
>>>
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>
>>
>>
>>
>> --
>>
>> Mike Belshe
>> CEO, BitGo, Inc
>> 408-718-6885
>>
>>
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>


More information about the Bitcoin-segwit2x mailing list