Re: [bitcoin-dev] Opinion on proof of stake in future

[Ruben Somsen via bitcoin-dev]

Hi all,

Thanks for the lively discussion. On behalf of the bitcoin-dev moderators
and with the readers of this mailing list in mind, we'd like to suggest
finishing up this discussion. Of course there should be some room for
exploring fringe ideas, but it should not dominate the mailing list either.
Fun as it may be, perhaps it's time to get back to focusing on the topics
that are more directly relevant to Bitcoin.

Cheers,
Ruben

On Fri, Jun 25, 2021 at 9:29 AM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> No, that's not how it works.
>
> PoS is constitutionally incapable of producing any further consensus
> from its starting point. If you start out by hardcoding the bitcoin
> ledger state at June 1, 2021, then your PoS system will be unable to
> reach a global consensus as to what the state was on June 2, 2021.
>
> To get global consensus in PoS, you have to know which block came first.
> To reach a consensus on which block was first, you need to solve the
> timestamp problem. And to solve the timestamp problem, you need a
> consensus system. You'll notice that at no point does PoS provide such a
> consensus system.
>
> Implementations of PoS sacrifice global consensus for 'weak
> subjectivity', meaning that each node has its own notion of when a
> certain block arrived. Astute observers will note that 'each node has
> its own notion of what happened' differs somewhat from 'all nodes agree
> on what happened', and that only one of these is a good description of
> what is commonly known as 'consensus'.
>
> Maybe a simpler way of looking at it is from the coder's perspective:
> how do you implement IBD? In PoW, the "longest chain" rule is used -
> "Nodes can leave and rejoin the network at will, accepting the
> proof-of-work chain as proof of what happened while they were gone.".
> Does PoS have this property?
>
> On 2021-06-24 21:50, Erik Aronesty wrote:
> >> PoS is not suitable for use as a consensus system, because
> > it is constitutionally incapable of producing a consensus.
> >
> > true - but only for a system that is starting from nothing.
> >
> > since bitcoin already exists, and we have a consensus, you can use
> > bitcoin's existing consensus to maintain that consensus using
> > references to prior state.  and yes, you simply have to limit reorgs
> > to not go back before PoW was abandoned in favor of PoS/PoB (assuming
> > all incentive problems are solved).
> >
> > ie: once you have uses PoW to bootstrap the system, you can "recycle"
> > that work.
> >
> > On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
> >  wrote:
> >>
> >> No, 51% of the *coin holders* can't do diddly squat. 51% of miners
> >> can,
> >> but in PoW, that's a different set to the coin holders.
> >>
> >> The basic problem with PoS, anyway, is that it's not actually a
> >> consensus system ("weak subjectivity"). Either you allow long reorgs,
> >> and then you open the door to long-range attacks, or you don't, and
> >> then
> >> you're not guaranteed that all nodes agree on the state of the chain,
> >> which was the purpose of the system to begin with.
> >>
> >> To put it more plainly: for PoS to work, you need a consensus on which
> >> block was seen first. But if you had that, you could presumably apply
> >> that method to determine which *transaction* was seen first, in which
> >> case you could do away with the blockchain entirely. (Real-world
> >> implementations of PoS, such that they are, do away with this
> >> requirement, scrapping the global consensus on ordering in favor of
> >> having each node decide for itself which block came first.)
> >>
> >> In other words, even if you solved all the incentive problems, the
> >> fact
> >> remains that PoS is not suitable for use as a consensus system,
> >> because
> >> it is constitutionally incapable of producing a consensus.
> >>
> >> On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
> >> >>  This is not true in a Proof of Work system and this difference
> >> > absolutely should not be trivialized.
> >> >
> >> > That is in fact true of Proof of Work as well. If a colluding
> >> > coalition of miners with more than 50% of the hashrate want to censor
> >> > transactions, they absolutely can do that by orphaning blocks that
> >> > contain transactions they want to censor. This is not different in
> >> > proof of stake.
> >> >
> >> > On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> >> >  wrote:
> >> >
> >> >>> Premise: There is a healthy exchange market for PoS Coin X with
> >> >> tens of thousands of participants bidding to buy and sell the coin
> >> >> for other currencies on the market.
> >> >>
> >> >> The difference here though is that Proof of Stake allows the quorum
> >> >> of coin holders to block the exchange of said coins if they are
> >> >> going to a particular destination. Nothing requires these staking
> >> >> nodes to include particular transactions into a block. With that in
> >> >> mind, it isn't just that you 

Re: [bitcoin-dev] Opinion on proof of stake in future

[yanmaani--- via bitcoin-dev]

No, that's not how it works.

PoS is constitutionally incapable of producing any further consensus 
from its starting point. If you start out by hardcoding the bitcoin 
ledger state at June 1, 2021, then your PoS system will be unable to 
reach a global consensus as to what the state was on June 2, 2021.


To get global consensus in PoS, you have to know which block came first. 
To reach a consensus on which block was first, you need to solve the 
timestamp problem. And to solve the timestamp problem, you need a 
consensus system. You'll notice that at no point does PoS provide such a 
consensus system.


Implementations of PoS sacrifice global consensus for 'weak 
subjectivity', meaning that each node has its own notion of when a 
certain block arrived. Astute observers will note that 'each node has 
its own notion of what happened' differs somewhat from 'all nodes agree 
on what happened', and that only one of these is a good description of 
what is commonly known as 'consensus'.


Maybe a simpler way of looking at it is from the coder's perspective: 
how do you implement IBD? In PoW, the "longest chain" rule is used - 
"Nodes can leave and rejoin the network at will, accepting the 
proof-of-work chain as proof of what happened while they were gone.". 
Does PoS have this property?


On 2021-06-24 21:50, Erik Aronesty wrote:

PoS is not suitable for use as a consensus system, because

it is constitutionally incapable of producing a consensus.

true - but only for a system that is starting from nothing.

since bitcoin already exists, and we have a consensus, you can use
bitcoin's existing consensus to maintain that consensus using
references to prior state.  and yes, you simply have to limit reorgs
to not go back before PoW was abandoned in favor of PoS/PoB (assuming
all incentive problems are solved).

ie: once you have uses PoW to bootstrap the system, you can "recycle" 
that work.


On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
 wrote:


No, 51% of the *coin holders* can't do diddly squat. 51% of miners 
can,

but in PoW, that's a different set to the coin holders.

The basic problem with PoS, anyway, is that it's not actually a
consensus system ("weak subjectivity"). Either you allow long reorgs,
and then you open the door to long-range attacks, or you don't, and 
then

you're not guaranteed that all nodes agree on the state of the chain,
which was the purpose of the system to begin with.

To put it more plainly: for PoS to work, you need a consensus on which
block was seen first. But if you had that, you could presumably apply
that method to determine which *transaction* was seen first, in which
case you could do away with the blockchain entirely. (Real-world
implementations of PoS, such that they are, do away with this
requirement, scrapping the global consensus on ordering in favor of
having each node decide for itself which block came first.)

In other words, even if you solved all the incentive problems, the 
fact
remains that PoS is not suitable for use as a consensus system, 
because

it is constitutionally incapable of producing a consensus.

On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
>>  This is not true in a Proof of Work system and this difference
> absolutely should not be trivialized.
>
> That is in fact true of Proof of Work as well. If a colluding
> coalition of miners with more than 50% of the hashrate want to censor
> transactions, they absolutely can do that by orphaning blocks that
> contain transactions they want to censor. This is not different in
> proof of stake.
>
> On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
>  wrote:
>
>>> Premise: There is a healthy exchange market for PoS Coin X with
>> tens of thousands of participants bidding to buy and sell the coin
>> for other currencies on the market.
>>
>> The difference here though is that Proof of Stake allows the quorum
>> of coin holders to block the exchange of said coins if they are
>> going to a particular destination. Nothing requires these staking
>> nodes to include particular transactions into a block. With that in
>> mind, it isn't just that you require the permission of the person
>> who sold you the coins, which I can agree is a less dangerous form
>> of permission, but you must also require the permission of at least
>> 51% of the coin holders to even receive those coins in the first
>> place. This is not true in a Proof of Work system and this
>> difference absolutely should not be trivialized.
>>
>> Keagan
>>
>> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
>>  wrote:
>>
>>> Barrier to entry in PoS is being given permission by the previous
>> owner of a token
>>
>> The idea that proof of stake is not permissionless is completely
>> invalid. It pains me to see such an argument here. Perhaps we can
>> come to an agreement by being more specific. I'd like to propose the
>> following:
>>
>> Premise: There is a healthy exchange market for PoS Coin X with tens
>> of 

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Antoine Riard via bitcoin-dev]

> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).

Well, we have zero-conf LN channels ? Actually, Lightning channel funding
transactions should be buried under a few blocks, though few services
providers are offering zero-conf channels, where you can start to spend
instantly [0]. I believe that's an interesting usage, though IMHO as
mentioned we can explore different security models to make 0-conf safe
(reputation/fidelity-bond).

> One question I have is: how does software generally inform the user about
0-conf payment detection?

Yes generally it's something like an "Unconfirmed" annotation on incoming
txn, though at least this is what Blockstream Green or Electrum are doing.

> But I
suppose it would depend on how often 0-conf is used in the bitcoin
ecosystem at this point, which I don't have any data on.

There are few Bitcoin services well-known to rely on 0-conf. Beyond how
much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot
of 0-confs service providers are going to be reluctant to share the
information, for a really good reason you will learn a subset of their
business volumes.

I'll see if I can come up with some Fermi estimation on this front.

[0] https://www.bitrefill.com/thor-turbo-channels/

Le mer. 16 juin 2021 à 20:58, Billy Tetrud  a
écrit :

> Russel O'Connor recently opined
> 
> that RBF should be standard treatment of all transactions, rather than as a
> transaction opt-in/out. I agree with that. Any configuration in a
> transaction that has not been committed into a block yet simply can't be
> relied upon. Miners also have a clear incentive to ignore RBF rules and
> mine anything that passes consensus. At best opting out of RBF is a weak
> defense, and at worst it's simply a false sense of security that is likely
> to actively lead to theft events.
>
> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).
>
> One question I have is: how does software generally inform the user about
> 0-conf payment detection? Does software generally tell the user something
> along the lines of "This payment has not been finalized yet. All recipients
> should wait until the transaction has at least 1 confirmation, and most
> recipients should wait for 6 confirmations" ? I think unless we pressure
> software to be very explicit about what counts as finality, users will
> simply continue to do what they've always done. Rolling out this policy
> change over the course of a year or two seems fine, no need to rush. But I
> suppose it would depend on how often 0-conf is used in the bitcoin
> ecosystem at this point, which I don't have any data on.
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment phase
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attacker
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild for
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those DoS
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party