Matt Bell [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-19 📝 Original message:Hi ZmnSCPxj, Just to ...
📅 Original date posted:2019-01-19
📝 Original message: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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190118/de50b59d/attachment.html>;
📝 Original message: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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190118/de50b59d/attachment.html>;