š
Original date posted:2022-10-18
š Original message:not sure if this is helpful, but when i'm code reviewing a change to an
existing, functioning and very complex system, i rarely go back to "first
principles" to analyze that change independently, and instead try to decide
if it's better or worse than what we have now
you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on whether
its better to get it out now for the people that need it, or bikeshed ux
for another 2 releases
i'm often a fan of the former
if someone proposes a change to bitcoin, we should probably review it as
"better or worse than what we have", rather than "has perfectly aligned
incentives promoting honest behavior even among selfish actors"
we know bitcoin functions now with a complex series of incentives,
especially regarding node operators
in other words, does the change "improve what we have" is a better bar than
"stands on its own"
in that way the system can slowly improve over time, rather than be stuck
On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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 <https://twitter.com/JeremyRubin>;
>
>
> 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.)
>>
> _______________________________________________
> 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/20221018/8fbccf61/attachment.html>;
Erik Aronesty [ARCHIVE] /
npub1y2ā¦5taj0
2023-06-07 23:15:17
in reply to nevent1qā¦9h9x
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:15:17Event JSON
{
"id": "c5f2b02df6c058c18d7b20d3f65dd91451504603f3cbb395e5d33c6e4b431c9c",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179717,
"kind": 1,
"tags": [
[
"e",
"7b8d8d0e33810be4c68b760cab2c67443a455ddd1b9f82bf14d66f2f304be8cb",
"",
"root"
],
[
"e",
"0c84ecd7e5e499e8a597af25eb171bf630caa45ef755077dde869b68f6d9cf50",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "š
Original date posted:2022-10-18\nš Original message:not sure if this is helpful, but when i'm code reviewing a change to an\nexisting, functioning and very complex system, i rarely go back to \"first\nprinciples\" to analyze that change independently, and instead try to decide\nif it's better or worse than what we have now\n\nyou can introduce a new feature, for example, that has a bunch of\nnoncritical bugs, especially in ux, and then you can weigh in on whether\nits better to get it out now for the people that need it, or bikeshed ux\nfor another 2 releases\n\ni'm often a fan of the former\n\nif someone proposes a change to bitcoin, we should probably review it as\n\"better or worse than what we have\", rather than \"has perfectly aligned\nincentives promoting honest behavior even among selfish actors\"\n\nwe know bitcoin functions now with a complex series of incentives,\nespecially regarding node operators\n\nin other words, does the change \"improve what we have\" is a better bar than\n\"stands on its own\"\n\nin that way the system can slowly improve over time, rather than be stuck\n\n\nOn Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I think the issue with\n\u003e\n\u003e I still think it is misguided to think that the \"honest\" (i.e. rule\n\u003e\u003e following) majority is to just be accepted as an axiom and if it is\n\u003e\u003e violated, well, then sorry. The rules need to be incentive compatible for\n\u003e\u003e the system to be functional. The honest majority is only considered an\n\u003e\u003e assumption because even if following the rules were clearly the 100%\n\u003e\u003e dominant strategy, this doesn't prove that the majority is honest, since\n\u003e\u003e mathematics cannot say what is happening in the real world at any given\n\u003e\u003e time. Still, we must have a reason to think that the majority would be\n\u003e\u003e honest, and that reasoning should come from an argument that the rule set\n\u003e\u003e is incentive compatible.\n\u003e\n\u003e\n\u003e epistemically is that even within the game that you prove the dominant\n\u003e strategy, you can't be certain that you've captured (except maybe through\n\u003e clever use of exogenous parameters, which reduces to the same thing as %\n\u003e honest) the actual incentives of all players. For example, you would need\n\u003e to capture the existence of large hegemonic governments defending their\n\u003e legacy currencies by attacking bitcoin.\n\u003e\n\u003e\n\u003e I think we may be talking past each other if it is a concern / valuable\n\u003e exercise to decrease the assumptions that Bitcoin rests on to make it more\n\u003e secure than it is as defined in the whitepaper. That's an exercise of\n\u003e tremendous value. I think my point is that those things are aspirational\n\u003e (aspirations that perhaps we should absolutely achieve?) but to the extent\n\u003e that we need to fix things like the fee market, selfish mining, mind the\n\u003e gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps\n\u003e another way to look at it) in the presence of deviations from a\n\u003e hypothesized \"incentive compatible Bitcoin\", which is a different thing\n\u003e that \"whitepaper bitcoin\". I think that I largely fall in the camp -- as\n\u003e evidenced by some past conversations I won't rehash -- that all of Bitcoin\n\u003e should be incentive compatible and we should fix it if not. But from those\n\u003e conversations I also learned that there are large swaths of the community\n\u003e who don't share that value, or only share it up to a point, and do feel\n\u003e comfortable resting on honest majority assumptions at one layer of the\n\u003e stack or another. And I think that prior / axiom is a pretty central one to\n\u003e debug or comprehend when dealing with, as is happening now, a fight over\n\u003e something that seems obviously not incentive compatible.\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\n\u003e\n\u003e On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor \u003c\n\u003e roconnor at blockstream.com\u003e wrote:\n\u003e\n\u003e\u003e On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e However, what *is* important about what Satoshi wrote is that it is sort\n\u003e\u003e\u003e of the \"social contract\" of what Bitcoin is that we can all sort of\n\u003e\u003e\u003e minimally agree to. This makes it clear, when we try to describe Bitcoin\n\u003e\u003e\u003e with differing assumptions than in the whitepaper, what the changes are and\n\u003e\u003e\u003e why we think the system might support those claims. But if we can't prove\n\u003e\u003e\u003e the new description sound, such as showing tip mining to be rational in a\n\u003e\u003e\u003e fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,\n\u003e\u003e\u003e since all that was promised originally is functioning under an honest\n\u003e\u003e\u003e majority. Caveat Emptor!\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e I still think it is misguided to think that the \"honest\" (i.e. rule\n\u003e\u003e following) majority is to just be accepted as an axiom and if it is\n\u003e\u003e violated, well, then sorry. The rules need to be incentive compatible for\n\u003e\u003e the system to be functional. The honest majority is only considered an\n\u003e\u003e assumption because even if following the rules were clearly the 100%\n\u003e\u003e dominant strategy, this doesn't prove that the majority is honest, since\n\u003e\u003e mathematics cannot say what is happening in the real world at any given\n\u003e\u003e time. Still, we must have a reason to think that the majority would be\n\u003e\u003e honest, and that reasoning should come from an argument that the rule set\n\u003e\u003e is incentive compatible.\n\u003e\u003e\n\u003e\u003e The stability of mining, i.e. the incentives to mine on the most work\n\u003e\u003e chain, is actually a huge concern, especially in a future low subsidy\n\u003e\u003e environment. There is actually much fretting about this issue, and rightly\n\u003e\u003e so. We don't actually know that Bitcoin can function in a low subsidy\n\u003e\u003e environment because we have never tested it. Bitcoin could still end up a\n\u003e\u003e failure if that doesn't work out. My current understanding/guess is that\n\u003e\u003e with a \"thick mempool\" (that is lots of transactions without large gaps in\n\u003e\u003e fee rates between them) and/or miners rationally leaving behind\n\u003e\u003e transactions to encourage mining on their block (after all it is in a\n\u003e\u003e miner's own interest not to have their block orphaned), that mining will be\n\u003e\u003e stable. But I don't know this for sure, and we cannot know with certainty\n\u003e\u003e that we are going to have a \"thick mempool\" when it is needed.\n\u003e\u003e\n\u003e\u003e It is most certainly the case that one can construct situations where not\n\u003e\u003e mining on the tip is going to be the prefered strategy. But even if that\n\u003e\u003e happens on occasion, it's not like the protocol immediately collapses,\n\u003e\u003e because mining off the tip is indistinguishable from being a high latency\n\u003e\u003e miner who simply didn't receive the most work block in time. So it is more\n\u003e\u003e of a question of how rare does it need to be, and what can we do to reduce\n\u003e\u003e the chances of such situations arising (e.g. updating our mining policy to\n\u003e\u003e leave some transactions out based on current (and anticipated) mempool\n\u003e\u003e conditions, or (for a sufficiently capitalized miner) leave an explicit,\n\u003e\u003e ANYONECANSPEND transaction output as a tip for the next miner to build upon\n\u003e\u003e mined blocks.)\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/8fbccf61/attachment.html\u003e",
"sig": "4c0d7079a3aaac44de84a5e1a1b14135131c451547957d643cce2d8b30cb8fb9578b59b14e29f7d2c58e6ff133991687352830c1c6a66ee0c7276bbcaab6ad9e"
}