email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-20 📝 Original message:I had one other idea on ...
📅 Original date posted:2022-10-20
📝 Original message: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 at blockstream.com> wrote:
>
> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
> <bitcoin-dev at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] https://twitter.com/JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/d96658cc/attachment-0001.html>;
📝 Original message: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 at blockstream.com> wrote:
>
> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
> <bitcoin-dev at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] https://twitter.com/JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/d96658cc/attachment-0001.html>;