public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: S kang <skang404@gmail•com>
To: email@yancy•lol,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)
Date: Fri, 21 Oct 2022 06:17:07 -0700	[thread overview]
Message-ID: <E446975B-4F06-40E6-9C97-1B60DBEB92D9@gmail.com> (raw)
In-Reply-To: <1f575fa24af142126507eebdf0e6b2e8@yancy.lol>

[-- Attachment #1: Type: text/plain, Size: 6256 bytes --]

Hello respected parties of the bitcoin network,

The point, as put forward by Jeremy is, economic rationality sometimes leads to breaking the ’social contract’ set earlier in history.

Beyond its implications to RBF discussion, following economic rationality, rather than trying to uphold the social contract(honesty), may lead to hijacking of the network. Few examples: Development/Mining might follow the economic rational path of supporting whatever the blockchains winning in the market are doing (supporting smart contracts, or becoming a privacy chain, etc.) even at the price of giving up peer to peer payment system (the meme infinity/21m maybe the opposite of issuing multiple coins). A centralized third party may acquire the market sentiment to motivate this direction or influence miners/bitcoin dev to follow their roadmap, which seems beneficial to individuals until the extreme case where the core use-case is needed to secure themselves.

The main issue it seems is consensus(pow-based-vote or market sentiment driven improvements) cannot be vetoed by an individual(minority is not quite the right term, since it is opposite of majority, vs consensus). They can only exit at that point(, as the 'ship sails').

My point is ‘purity’ about Satoshi's vision(a cringe term at this point, but it means nothing more than the original ’social contract’ here) should be aspired to (while not considering Satoshi's word as given truth, as pointed out by the bugs) & all ‘improvements’ must NOT be entertained. On the other hand, as pointed out by Peter & Yancy, it may be practically impossible to do anything better than economic rationality. (A corollary, is that attacks described might have already happened and thus current audience might be ‘unable to grok’ as explained by Jeremy.)

Thanks for your time, mindshare & bearing my lack of academic quality.

- S Kang


> On Oct 21, 2022, at 1:47 AM, yancy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
>> ...and the easiest way to avoid Bitcoin being a system that doesn't arbitrarily
>> change rules, is to rely on economically rational rules that aren't likely to
>> change!
>  
> Yes, I think many people on this thread have been making the same point.  This is the basis of the Nash Equilibrium, from what I remember.
>  
>> This, Satoshi (who doesn't really matter anyways I guess?)
> 
>  
> It doesn't seem to me Satoshi was classically trained in CS else maybe he/she/they might have referenced the Nash Equilibrium.  Looking at some of the other references, including a statistics book titled "An Introduction to Probability Theory and its Applications" from 1957 makes me think this Satoshi person was closer in training and practice to a mathematician.
>  
> Cheers,
> -Yancy
>  
> On 2022-10-21 02:26, Peter Todd via bitcoin-dev wrote:
>> 
>> On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin wrote:
>>> 
>>> The difference between honest majority and longest chain is that the
>>> longest chain bug was something acknowledged by Satoshi & patched
>>> https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420 <https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420>
>>> .
>>> 
>>> 
>>> OTOH, we have more explicit references that the honest majority really
>>> should be thought of as good guys vs bad guys... e.g.
>> 
>> The point is Satoshi got a lot of very fundamental stuff wrong. Bringing up
>> what Satoshi wrote now, almost 14 years later, misleads less-technical readers
>> into thinking our understanding of Bitcoin is still based on that early,
>> incorrect, understanding.
>> 
>> Incidentally, you realize that it was _Satoshi_ who added RBF to Bitcoin with
>> nSequence replacements. My contribution was to fix that obviously broken design
>> with fee-based RBF (with nSequence a transaction could be replaced up to 4
>> billion times, using essentially unlimited P2P bandwidth; it was a terrible
>> idea).
>> 
>>> I do think the case can be fairly made for full RBF, but if you don't grok
>>> the above maybe you won't have as much empathy for people who built a
>>> business around particular aspects of the Bitcoin network that they feel
>>> are now being changed. They have every right to be mad about that and make
>>> disagreements known and argue for why we should preserve these properties.
>> 
>> Those people run mild sybil attacks on the network in their efforts to
>> "mitigate risk" by monitoring propagation; fundamentally doing so is
>> centralizing and unfair, as only a small number of companies can do that
>> without DoS attacking the P2P network. It's pretty obvious that reliance to
>> zeroconf is harmful to Bitcoin, and people trying to do that have repeatedly
>> taken big losses when their risk mitigations turned out to not work. Their only
>> right to be mad comes from the 1st Ammendment.
>> 
>>> As someone who wants for Bitcoin to be a system which doesn't arbitrarily
>>> change rules based on the whims of others, I think it important that we can
>>> steelman and provide strong cases for why our actions might be in the
>>> wrong, so that we make sure our justifications are not only well-justified,
>>> but that we can communicate them clearly to all participants in a global
>>> value network.
>> 
>> ...and the easiest way to avoid Bitcoin being a system that doesn't arbitrarily
>> change rules, is to rely on economically rational rules that aren't likely to
>> change!
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

[-- Attachment #2: Type: text/html, Size: 16601 bytes --]

      reply	other threads:[~2022-10-21 13:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-16 17:35 Jeremy Rubin
2022-10-16 19:03 ` email
2022-10-17 19:10   ` Jeremy Rubin
2022-10-17 22:31     ` email
2022-10-18  3:34       ` Jeremy Rubin
2022-10-18 14:30         ` Russell O'Connor
2022-10-18 16:27           ` Jeremy Rubin
2022-10-18 17:33             ` Erik Aronesty
2022-10-18 18:57               ` email
2022-10-20 19:21             ` email
2022-10-20 22:19           ` Peter Todd
2022-10-17 15:51 ` Russell O'Connor
2022-10-17 19:02   ` Jeremy Rubin
2022-10-20 22:28 ` Peter Todd
2022-10-20 23:54   ` Jeremy Rubin
2022-10-21  0:26     ` Peter Todd
2022-10-21  8:47       ` email
2022-10-21 13:17         ` S kang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E446975B-4F06-40E6-9C97-1B60DBEB92D9@gmail.com \
    --to=skang404@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=email@yancy$(echo .)lol \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox