[bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Matt Bell]

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

I have been working on a design for Bitcoin sidechains using the Tendermint
BFT consensus protocol, which is commonly used to build proof-of-stake
networks (Cosmos is the notable one).

The design ends up being very similar to Blockstream's Liquid sidechain,
since Tendermint consensus is not far off from Liquid's "strong federation"
consensus.

Any feedback about improvements or critical flaws would be greatly
appreciated. The design document is here:
https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that repo
also contains a simplified implementation of this sidechain design).

Thanks for your feedback,
Matt Bell

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good morning Matt,

It seems to me much more interesting if the stakes used to weigh voting power are UTXOs on the Bitcoin blockchain.
This idea is what I call "mainstake"; rather than a blockchain having its own token that is self-attesting (which is insecure).
It seems to me, naively, that the same script you propose here can be used for mainstake.

For instance, the sidechain network might accept potential stakers on the mainchain, if the staker proves the existence of a mainchain transaction whose output is for example:

<sidechain identifier> OP_DROP
"1 year" OP_CHECKSEQUENCEVERIFY OP_DROP
<pubkey> OP_CHECKSIG

The sidechain network could accept this and use the value of the output as the weight of the vote of that stake.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, which is commonly used to build proof-of-stake networks (Cosmos is the notable one).
>
> The design ends up being very similar to Blockstream's Liquid sidechain, since Tendermint consensus is not far off from Liquid's "strong federation" consensus.
>
> Any feedback about improvements or critical flaws would be greatly appreciated. The design document is here: https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that repo also contains a simplified implementation of this sidechain design).
>
> Thanks for your feedback,
> Matt Bell

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Matt Bell]

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

Hi ZmnSCPxj,

Just to clarify, my design does not specify the source of voting power, so
it is agnostic to whatever system you want to derive stake or valdiator set
membership from.

Your idea of timelocking Bitcoin is interesting, I am eager to find a
solution where holding Bitcoin is enough to get voting power. It's possible
there may be an issue with the fact that the Bitcoin is not slashable
(although their voting power is), meaning a validator who double-signs
cannot have their Bitcoin removed from them. However their UTXO can be
blacklisted which does make their attack costly since they lose out on the
time-value of their stake.

Our current thinking for the source of stake is to pay out stake to Bitcoin
merged-miners although I'll definitely do some more thinking about
timelocked Bitcoin as stake.

On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com wrote:

> Good morning Matt,
>
> It seems to me much more interesting if the stakes used to weigh voting
> power are UTXOs on the Bitcoin blockchain.
> This idea is what I call "mainstake"; rather than a blockchain having its
> own token that is self-attesting (which is insecure).
> It seems to me, naively, that the same script you propose here can be used
> for mainstake.
>
> For instance, the sidechain network might accept potential stakers on the
> mainchain, if the staker proves the existence of a mainchain transaction
> whose output is for example:
>
> <sidechain identifier> OP_DROP
> "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP
> <pubkey> OP_CHECKSIG
>
> The sidechain network could accept this and use the value of the output as
> the weight of the vote of that stake.
>
> Regards,
> ZmnSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > I have been working on a design for Bitcoin sidechains using the
> Tendermint BFT consensus protocol, which is commonly used to build
> proof-of-stake networks (Cosmos is the notable one).
> >
> > The design ends up being very similar to Blockstream's Liquid sidechain,
> since Tendermint consensus is not far off from Liquid's "strong federation"
> consensus.
> >
> > Any feedback about improvements or critical flaws would be greatly
> appreciated. The design document is here:
> https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that
> repo also contains a simplified implementation of this sidechain design).
> >
> > Thanks for your feedback,
> > Matt Bell
>

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good Morning Matt,

It seems to me that double signing can be punished by requiring that R be a trivial function on the blockheight of the block being signed on the sidechain network. Then a validator who signs multiple versions of history at a particular blockheight reveals their privkey. Since the privkey also protects their Bitcoin stake UTXO, they risk loss of their Bitcoin stake. A similar idea is used by Discrete Log Contracts to ensure Oracles do not sign multiple values at a particular time.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, January 19, 2019 1:35 PM, Matt Bell <mappum@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> Just to clarify, my design does not specify the source of voting power, so it is agnostic to whatever system you want to derive stake or valdiator set membership from.
>
> Your idea of timelocking Bitcoin is interesting, I am eager to find a solution where holding Bitcoin is enough to get voting power. It's possible there may be an issue with the fact that the Bitcoin is not slashable (although their voting power is), meaning a validator who double-signs cannot have their Bitcoin removed from them. However their UTXO can be blacklisted which does make their attack costly since they lose out on the time-value of their stake.
>
> Our current thinking for the source of stake is to pay out stake to Bitcoin merged-miners although I'll definitely do some more thinking about timelocked Bitcoin as stake.
>
> On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com wrote:
>
> > Good morning Matt,
> >
> > It seems to me much more interesting if the stakes used to weigh voting power are UTXOs on the Bitcoin blockchain.
> > This idea is what I call "mainstake"; rather than a blockchain having its own token that is self-attesting (which is insecure).
> > It seems to me, naively, that the same script you propose here can be used for mainstake.
> >
> > For instance, the sidechain network might accept potential stakers on the mainchain, if the staker proves the existence of a mainchain transaction whose output is for example:
> >
> > <sidechain identifier> OP_DROP
> > "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP
> > <pubkey> OP_CHECKSIG
> >
> > The sidechain network could accept this and use the value of the output as the weight of the vote of that stake.
> >
> > Regards,
> > ZmnSCPxj
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > I have been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, which is commonly used to build proof-of-stake networks (Cosmos is the notable one).
> > >
> > > The design ends up being very similar to Blockstream's Liquid sidechain, since Tendermint consensus is not far off from Liquid's "strong federation" consensus.
> > >
> > > Any feedback about improvements or critical flaws would be greatly appreciated. The design document is here: https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that repo also contains a simplified implementation of this sidechain design).
> > >
> > > Thanks for your feedback,
> > > Matt Bell

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Matt Bell]

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

ZmnSCPxj,

I'm intrigued by this mechanism of using fixed R values to prevent multiple
signatures, but how do we derive the R values in a way where they are
unique for each blockheight but still can be used to create signatures or
verify?

Thanks,
Matt

On Sat, Jan 19, 2019 at 6:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good Morning Matt,
>
> It seems to me that double signing can be punished by requiring that R be
> a trivial function on the blockheight of the block being signed on the
> sidechain network. Then a validator who signs multiple versions of history
> at a particular blockheight reveals their privkey. Since the privkey also
> protects their Bitcoin stake UTXO, they risk loss of their Bitcoin stake. A
> similar idea is used by Discrete Log Contracts to ensure Oracles do not
> sign multiple values at a particular time.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, January 19, 2019 1:35 PM, Matt Bell <mappum@gmail.com> wrote:
>
> > Hi ZmnSCPxj,
> >
> > Just to clarify, my design does not specify the source of voting power,
> so it is agnostic to whatever system you want to derive stake or valdiator
> set membership from.
> >
> > Your idea of timelocking Bitcoin is interesting, I am eager to find a
> solution where holding Bitcoin is enough to get voting power. It's possible
> there may be an issue with the fact that the Bitcoin is not slashable
> (although their voting power is), meaning a validator who double-signs
> cannot have their Bitcoin removed from them. However their UTXO can be
> blacklisted which does make their attack costly since they lose out on the
> time-value of their stake.
> >
> > Our current thinking for the source of stake is to pay out stake to
> Bitcoin merged-miners although I'll definitely do some more thinking about
> timelocked Bitcoin as stake.
> >
> > On Fri, Jan 18, 2019, 5:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com wrote:
> >
> > > Good morning Matt,
> > >
> > > It seems to me much more interesting if the stakes used to weigh
> voting power are UTXOs on the Bitcoin blockchain.
> > > This idea is what I call "mainstake"; rather than a blockchain having
> its own token that is self-attesting (which is insecure).
> > > It seems to me, naively, that the same script you propose here can be
> used for mainstake.
> > >
> > > For instance, the sidechain network might accept potential stakers on
> the mainchain, if the staker proves the existence of a mainchain
> transaction whose output is for example:
> > >
> > > <sidechain identifier> OP_DROP
> > > "1 year" OP_CHECKSEQUENCEVERIFY OP_DROP
> > > <pubkey> OP_CHECKSIG
> > >
> > > The sidechain network could accept this and use the value of the
> output as the weight of the vote of that stake.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Saturday, January 19, 2019 6:59 AM, Matt Bell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > > I have been working on a design for Bitcoin sidechains using the
> Tendermint BFT consensus protocol, which is commonly used to build
> proof-of-stake networks (Cosmos is the notable one).
> > > >
> > > > The design ends up being very similar to Blockstream's Liquid
> sidechain, since Tendermint consensus is not far off from Liquid's "strong
> federation" consensus.
> > > >
> > > > Any feedback about improvements or critical flaws would be greatly
> appreciated. The design document is here:
> https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md (that
> repo also contains a simplified implementation of this sidechain design).
> > > >
> > > > Thanks for your feedback,
> > > > Matt Bell
>
>
>

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good Morning Matt,

> ### ZmnSCPxj,
>
> I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
unique for each blockheight but still can be used to create signatures or verify?

One possibility is to derive `R` using standard hierarchical derivation.
Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.



Regards,
ZmnSCPxj

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Satoshin]

This could could be a viable option. I think this is the right approach.

Any downside to this and how much does this add to the blockweight if anything at all.

Anonymouse

> On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Good Morning Matt,
> 
>> ### ZmnSCPxj,
>> 
>> I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
> unique for each blockheight but still can be used to create signatures or verify?
> 
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.
> 
> 
> 
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Dustin Dettmer]

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

How could you prove the private key is in the burning transaction?

On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This could could be a viable option. I think this is the right approach.
>
> Any downside to this and how much does this add to the blockweight if
> anything at all.
>
> Anonymouse
>
> > On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Good Morning Matt,
> >
> >> ### ZmnSCPxj,
> >>
> >> I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> > unique for each blockheight but still can be used to create signatures
> or verify?
> >
> > One possibility is to derive `R` using standard hierarchical derivation.
> > Then require that the staking pubkey be revealed to the sidechain
> network as actually being `staking_pubkey = P + hash(P || parent_R) * G`
> (possibly with some trivial protection against Taproot).
> > To sign for a blockheight `h`, you must use your public key `P` and the
> specific `R` we get from hierarchical derivation from `parent_R` and the
> blockheight as index.
> >
> >
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Dustin Dettmer]

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

Wouldn’t a revealed private key for time locked funds create a race to
spend? I imagine miners who are paying attention would have the advantage
but it would still just be a race.

Would be nice to have the funds destroyed or sent somewhere specific. Like
if somehow the revealed key was actually itself a presigned transaction. Or
perhaps a 32 byte piece of a tx needed to complete it.

On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good Morning Matt,
>
> > ### ZmnSCPxj,
> >
> > I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> unique for each blockheight but still can be used to create signatures or
> verify?
>
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network
> as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly
> with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the
> specific `R` we get from hierarchical derivation from `parent_R` and the
> blockheight as index.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good morning Dustin,

> Wouldn’t a revealed private key for time locked funds create a race to spend? I imagine miners who are paying attention would have the advantage but it would still just be a race.

If Bitcoin had implemented RBF "properly" (i.e. not have the silly "opt-out" rule) then such races are won by bidding up the fees.  A random person who is not the original staker would be willing to pay miners a fee up to the entire staked amount minus dustlimit satoshis; obviously a staker would be far less willing to pay up such a fee, so the random person slashing the funds would have a major advantage in that race.
Thus the race will be won by whoever mines the highest-fee transaction.
It still becomes very unlikely that the staker will win unless the staker already has a significant mining hashpower (and if the staker has significant hashpower, then the Bitoin layer itself is at peril anyway, never mind sidechains built on top of it).

Regards,
ZmnSCPxj

>
> On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Good Morning Matt,
> >
> > > ### ZmnSCPxj,
> > >
> > > I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
> > unique for each blockheight but still can be used to create signatures or verify?
> >
> > One possibility is to derive `R` using standard hierarchical derivation.
> > Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
> > To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Matt Bell]

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

It seems that miners would always claim the stake for themselves, why not
since the private key is public knowledge anyway? This is a nice security
property since it wouldn't make economical sense for a miner to take a
bribe from an attacker since it would have to be less than the stake amount.

It still becomes very unlikely that the staker will win unless the staker
> already has a significant mining hashpower (and if the staker has
> significant hashpower, then the Bitoin layer itself is at peril anyway,
> never mind sidechains built on top of it).


Since the likelihood of a successful attack is proportional to the
attacker's share of the Bitcoin hashrate, the sidechain's integrity
essentially has the same security level as the Bitcoin main chain.
Although, the Bitcoin which was moved to the sidechain is susceptible to
being stolen if 67% of the stakers collude, which does makes storing funds
on it weaker to some degree.

On Thu, Jan 24, 2019 at 2:03 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Dustin,
>
> > Wouldn’t a revealed private key for time locked funds create a race to
> spend? I imagine miners who are paying attention would have the advantage
> but it would still just be a race.
>
> If Bitcoin had implemented RBF "properly" (i.e. not have the silly
> "opt-out" rule) then such races are won by bidding up the fees.  A random
> person who is not the original staker would be willing to pay miners a fee
> up to the entire staked amount minus dustlimit satoshis; obviously a staker
> would be far less willing to pay up such a fee, so the random person
> slashing the funds would have a major advantage in that race.
> Thus the race will be won by whoever mines the highest-fee transaction.
> It still becomes very unlikely that the staker will win unless the staker
> already has a significant mining hashpower (and if the staker has
> significant hashpower, then the Bitoin layer itself is at peril anyway,
> never mind sidechains built on top of it).
>
> Regards,
> ZmnSCPxj
>
> >
> > On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > Good Morning Matt,
> > >
> > > > ### ZmnSCPxj,
> > > >
> > > > I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> > > unique for each blockheight but still can be used to create signatures
> or verify?
> > >
> > > One possibility is to derive `R` using standard hierarchical
> derivation.
> > > Then require that the staking pubkey be revealed to the sidechain
> network as actually being `staking_pubkey = P + hash(P || parent_R) * G`
> (possibly with some trivial protection against Taproot).
> > > To sign for a blockheight `h`, you must use your public key `P` and
> the specific `R` we get from hierarchical derivation from `parent_R` and
> the blockheight as index.
> > >
> > > Regards,
> > > ZmnSCPxj
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

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

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Peter Todd]

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



On January 24, 2019 10:03:25 AM UTC, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Good morning Dustin,
>
>> Wouldn’t a revealed private key for time locked funds create a race
>to spend? I imagine miners who are paying attention would have the
>advantage but it would still just be a race.
>
>If Bitcoin had implemented RBF "properly" (i.e. not have the silly
>"opt-out" rule) then such races are won by bidding up the fees.  A

Note that CSV using transactions are always RBF as CSV disables the opt-out.
-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 500 bytes --]

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good mornint Peter,

> > > Wouldn’t a revealed private key for time locked funds create a race
> > > to spend? I imagine miners who are paying attention would have the
> > > advantage but it would still just be a race.
> >
> > If Bitcoin had implemented RBF "properly" (i.e. not have the silly
> > "opt-out" rule) then such races are won by bidding up the fees. A
>
> Note that CSV using transactions are always RBF as CSV disables the opt-out.
>

Thank you for this information.
I forgot that RBF opt-out was hacked on top of `nSequence`, and relative timelocks were also hacked on top of `nSequence`.
In particular coins locked on mainchain for the purpose of staking a sidechain (mainstake) have to be locked with an `OP_CSV`, which immediately enables this protection.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[Dr Adam Back]

Brands credentials use this single show, and multiple show
credentials. It's based on the representation problem which is the
generalisation to multiple bases where Schnorr is one base, Pedersen
Commitments are two bases, Representation problem is n>2 bases.

The method used would work for Schnorr or DSA and there was some 2013
era #bitcoin-wizards discussion on this topic, where if you spend
twice miners can take your money, as a strong way to "discourage"
address reuse.  One side effect though is you force ACID log oriented
storage on the wallet, and many wallets are low power devices or even
a few in VMs that could be snapshotted or rolled back. Similar risk
model to the lightning penalty for accidentally doing a hostile close
in the current model (where ELTOO has non-penalty based close).

You would have to be careful to not use related nonces (k=nonce
committed to by R=kG), as Schnorr and DSA are highly vulnerable to
that, like simultaneous equation two samples solvable.

What the Brands n-show credential looks like is a precommitment like
single show the address becomes A=H(R,Q) where Q is the public key,
and n-show becomes A=H(R1,...,Rn,Q).

Signing becomes providing i,Ri,Q in the Script to satisfy a
ScriptPubKey that includes the three. You would need to in practice
store the Ri values in a merkle tree probably so that you don't need
to provide n inputs, but log(n) or some other structuring.

Anyway main point being the fragility to related nonces, and cost of
ACID log structured storage levels of reliability in wallets.

Adam

On Tue, 22 Jan 2019 at 15:14, ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Good Morning Matt,
>
> > ### ZmnSCPxj,
> >
> > I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
> unique for each blockheight but still can be used to create signatures or verify?
>
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

[ZmnSCPxj]

Good morning Matt Bell,

Thinking of this further, I observe that there are limits on the number of operations in a SCRIPT (I believe 201 non-push operations, and maybe a smaller number of CHECKSIG operations?).
This implies that the number of signatories of the sidechain funds in the mainchain are limited.
This is an important care point.
I am uncertain what is the best way to solve this issue.


---

In any case, I now present a design for a proof-of-mainstake sidechain, now without any modifications to Bitcoin mainchain.

---

I observe that a blockchain is, stripped to its barest minimum, nothing more than a Merklized singly-linked list.
Each block header is a node in a singly-linked list.
It commits to the previous block header, and also commits to the block data (traditionally a Merkle binary tree).

Via such block headers, a chain of blocks --- a blockchain --- is formed.

---

I observe that a (non-coinbase) transaction in Bitcoin refers to at least one existing transaction output.
A representation of that transaction output must be committed to in the transaction.

If we create single-input single-output transactions, a chain of transactions is formed.

---

Thus the idea: the sidechain *is* the transaction chain.

I observe that the mainchain *must* contain some UTXO(s) that are purportedly controlled by the sidechain rules.

It is also possible that the sidechain funds be a single UTXO, with deposits and withdrawals requiring that the single UTXO be spent, in order to maintain the invariant that the sidechains funds are handled completely in a single UTXO.
In addition, it is possible for a transaction to commit to some data arbitrarily, either via `OP_RETURN`, or via some technique such as pay-to-contract (which reduces space utilization on the mainchain compared to `OP_RETURN`).

When we use the above technique (i.e. the sidechain only "owns" a single mainchain UTXO at each block of the mainchain):

1.  Each transaction commits to the previous transaction (via spending the output of the previous transaction).
2.  Each transaction may commit to some other data (via `OP_RETURN` or other technique).

I observe also that under a blockchain:

1.  Each block header commits to the previous block header.
2.  Each block header commits to the block data.

From this, the analogy is simple and obvious.
The sidechain "blockchain" *is* the transaction chain.

---

Under certain forms of proof-of-stake, the block must be signed by some set of signatories of the stakers.
Under transaction rules, the transaction must be signed according to the SCRIPT, and the SCRIPT may indicate that some set of signatories must sign.

Thus, it becomes possible to simply embed the sidechain block headers on the mainchain directly, by spending the previous transaction (== sidechain block header).
This spend requires that the transaction be signed in order to authorize the spend.
However, these same signatures are in fact also the signatures that, under proof-of-stake, prove that a sufficient signatory set of the stakers has authorized a particular block of the proof-of-stake blockchain.

The magic here is that, on the mainchain, a transaction may only be spent once.
Thus, nothing-at-stake and stake-grinding problems disappear.

---

Now let us introduce some details.

We have two mainchain-to-sidechain requests:

1.  An indication that a mainchain coin owner wants to stake coins to the sidechain.
2.  An indication that a mainchain coin owner wants to transfer coins to the sidechain.

From within the sidechain, sidechain-to-mainchain withdrawals must somehow be signalled, but that is up to the sidechain to define.
We shall ignore it here.

When a sidechain receives a request to add stake, then the current stakers create a mainchain transaction, spending the sidechain UTXO, plus the  staked coins, and outputting the next sidechain UTXO (with the signatory set modified appropriately), plus a stake UTXO that locks the coins.
When a sidechain receives a request to transfer coins from mainchain to sidechain, then the current stakers create a mainchain transaction, spending the sidechain UTXO, plus the transferred coins, and outputting the next sidechain UTXO (with the same signatory set).

Multiple such requests can be processed for each transaction (i.e. sidechain block).
This simply consumes the sidechain UTXO, any stake or transfer coins, and creates the next sidechain UTXO and any stake UTXOs.

Now, the indication to stake is a UTXO with a special script.
It has two branches:

1.  A signature from the current signatory set.
2.  Or, 2 OP_CSV and the staker signature.

The intent of the latter branch is to ensure that, if the current signatories ignore the incoming staker, the incoming staker can still recover its funds.

If the current set of stakers accepts the incoming staker (which requires both that they change the signatory set, and put the money being staked into a stake UTXO which is simply a long CSV and the staker signature), then the first branch is performed and the coin is an input of the sidechain block header (== sidechain managing transaction).

A similar technique is used for mainchain-to-sidechain transfers.
If the mainchain-to-sidechain transfer is ignored (either deliberately, or by an accident of disrupted communication from the mainchain trasnferrer to the sidechain network), the mainchain transferrer can recover its money and try again.

---

Ideally, every mainchain block would have a sidechain managing transaction (== sidechain block header).
Of course, we must consider fees.
Obviously the sidechain itself must charge fees within the sidechain.
Some fraction of those fees will be spent in order for the sidechain managing transaction to be confirmed on the mainchain.

Now it may happen that the sidechain managing transaction is not confirmed immediately on the mainchain.
The sidechain stakers (the signatory set) may elect to sacrifice even more of their fees to increase the fees of the sidechain managing transaction via RBF.

---

Now perhaps the sidechain may wish to have a faster (or more regular) block rate than the mainchain.
In such a case, it may maintain a "real" blockchain (i.e. headers that commit to a single previous header, and commits the block data).
Then each sidechain managing transaction would commit to the latest sidechain block header agreed upon by the stakers.

These sidechain blocks need not be signed; they only become "real" if they are committed to, directly or indirectly, in a sidechain managing transaction.

At each sidechain block, the signatory set (the stakers) create a sidechain managing transaction.
If it is immediately put into a mainchain block, then the next sidechain managing transaction spends it.
Otherwise, if it is not put into a mainchain block, then the stakers just recreate the sidechain managing transaction with RBF.

Regards,
ZmnSCPxj