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
 
I agree that it's important to not be too dogmatic, which includes Satoshi and the white paper. It's fun to look back and read to try to find inspiration, although, it seems to me, a lot has been learned since then.  And a lot will be learned in the future.  I was thinking to myself, what if in the distant future, quantum entanglement could be used to update all nodes simultaneously across any distance in space? How cool would that be?  How might that change from the original vision?  Well, if we ever get that far, I'm sure Satoshi could not have planned for that, or maybe they could have.. :)
 
On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote:
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@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 [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.)
 _______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 

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