public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: email@yancy•lol
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
	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: Thu, 20 Oct 2022 21:21:58 +0200	[thread overview]
Message-ID: <723c5f33823db10def2a07316ea88456@yancy.lol> (raw)
In-Reply-To: <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@mail.gmail.com>

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


I had one other idea on the topic.  Namely, in the last section 
"calculation", Satoshi talks more about what he/she/they consider to be 
bad actors.  The idea that someone is not doing "tip mining" does not 
mean they are dishonest.

> We consider the scenario of an attacker trying to generate an alternate 
> chain faster than the honest
> chain. Even if this is accomplished, it does not throw the system open 
> to arbitrary changes, such
> as creating value out of thin air or taking money that never belonged 
> to the attacker. Nodes are
> not going to accept an invalid transaction as payment, and honest nodes 
> will never accept a block
> containing them. An attacker can only try to change one of his own 
> transactions to take back
> money he recently spent.

It seems to me that there's a distinction in the game theoretics between 
"not tip mining" and actively being a bad actor (changing a past 
transaction signed by yourself).

I rewrote the "AttackerSuccessProbability" C function in Rust for fun:
https://github.com/yancyribbens/attacker-success-probability-rust

Cheers,
-Yancy

On 2022-10-18 18:27, Jeremy Rubin via bitcoin-dev wrote:

> I think the issue with
> 
>> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive
>> compatible for the system to be functional.  The honest majority is
>> only considered an assumption because even if following the rules
>> were clearly the 100% dominant strategy, this doesn't prove that the
>> majority is honest, since mathematics cannot say what is happening
>> in the real world at any given time.  Still, we must have a reason
>> to think that the majority would be honest, and that reasoning
>> should come from an argument that the rule set is incentive
>> compatible.
> 
> epistemically is that even within the game that you prove the dominant
> strategy, you can't be certain that you've captured (except maybe
> through clever use of exogenous parameters, which reduces to the same
> thing as % honest) the actual incentives of all players. For example,
> you would need to capture the existence of large hegemonic governments
> defending their legacy currencies by attacking bitcoin.
> 
> I think we may be talking past each other if it is a concern /
> valuable exercise to decrease the assumptions that Bitcoin rests on to
> make it more secure than it is as defined in the whitepaper. That's an
> exercise of tremendous value. I think my point is that those things
> are aspirational (aspirations that perhaps we should absolutely
> achieve?) but to the extent that we need to fix things like the fee
> market, selfish mining, mind the gap, etc, those are modifying Bitcoin
> to be secure (or more fair is perhaps another way to look at it) in
> the presence of deviations from a hypothesized "incentive compatible
> Bitcoin", which is a different thing that "whitepaper bitcoin". I
> think that I largely fall in the camp -- as evidenced by some past
> conversations I won't rehash -- that all of Bitcoin should be
> incentive compatible and we should fix it if not. But from those
> conversations I also learned that there are large swaths of the
> community who don't share that value, or only share it up to a point,
> and do feel comfortable resting on honest majority assumptions at one
> layer of the stack or another. And I think that prior / axiom is a
> pretty central one to debug or comprehend when dealing with, as is
> happening now, a fight over something that seems obviously not
> incentive compatible.
> 
> --
> @JeremyRubin [1 [1]]
> 
> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
> <roconnor@blockstream•com> wrote:
> 
> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> However, what *is* important about what Satoshi wrote is that it
> is sort of the "social contract" of what Bitcoin is that we can
> all sort of minimally agree to. This makes it clear, when we try
> to describe Bitcoin with differing assumptions than in the
> whitepaper, what the changes are and why we think the system might
> support those claims. But if we can't prove the new description
> sound, such as showing tip mining to be rational in a fully
> adversarial model, it doesn't mean Bitcoin doesn't work as
> promised, since all that was promised originally is functioning
> under an honest majority. Caveat Emptor!
> I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry.  The rules need to be incentive
> compatible for the system to be functional.  The honest majority is
> only considered an assumption because even if following the rules
> were clearly the 100% dominant strategy, this doesn't prove that the
> majority is honest, since mathematics cannot say what is happening
> in the real world at any given time.  Still, we must have a reason
> to think that the majority would be honest, and that reasoning
> should come from an argument that the rule set is incentive
> compatible.
> 
> The stability of mining, i.e. the incentives to mine on the most
> work chain, is actually a huge concern, especially in a future low
> subsidy environment.  There is actually much fretting about this
> issue, and rightly so.  We don't actually know that Bitcoin can
> function in a low subsidy environment because we have never tested
> it.  Bitcoin could still end up a failure if that doesn't work out.
> My current understanding/guess is that with a "thick mempool" (that
> is lots of transactions without large gaps in fee rates between
> them) and/or miners rationally leaving behind transactions to
> encourage mining on their block (after all it is in a miner's own
> interest not to have their block orphaned), that mining will be
> stable.  But I don't know this for sure, and we cannot know with
> certainty that we are going to have a "thick mempool" when it is
> needed.
> 
> It is most certainly the case that one can construct situations
> where not mining on the tip is going to be the prefered strategy.
> But even if that happens on occasion, it's not like the protocol
> immediately collapses, because mining off the tip is
> indistinguishable from being a high latency miner who simply didn't
> receive the most work block in time.  So it is more of a question of
> how rare does it need to be, and what can we do to reduce the
> chances of such situations arising (e.g. updating our mining policy
> to leave some transactions out based on current (and anticipated)
> mempool conditions, or (for a sufficiently capitalized miner) leave
> an explicit, ANYONECANSPEND transaction output as a tip for the next
> miner to build upon mined blocks.)

Links:
------
[1] https://twitter.com/JeremyRubin
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] https://twitter.com/JeremyRubin

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

  parent reply	other threads:[~2022-10-20 19:25 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 [this message]
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

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=723c5f33823db10def2a07316ea88456@yancy.lol \
    --to=email@yancy$(echo .)lol \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jeremy.l.rubin@gmail$(echo .)com \
    /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