Matt Bell [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-27 to 2019-01-24
💬 Posted a total of 5 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:16:00

- reply

📅 Original date posted:2019-01-24
📝 Original message: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 at 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 at 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 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/20190124/edf6f67a/attachment.html>

2023-06-07 18:15:59

- reply

📅 Original date posted:2019-01-21
📝 Original message: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 at 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 at 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 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/20190121/d7bc33e3/attachment-0001.html>

2023-06-07 18:15:58

- reply

📅 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>

2023-06-07 18:15:58

- reply

📅 Original date posted:2019-01-18
📝 Original message: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/f588117a/attachment.html>

2023-06-07 18:00:36

- reply

📅 Original date posted:2017-04-27
📝 Original message:Hello everyone,
I've been thinking of an alternative to possibly get Segwit activated
sooner: bribing the miners. This proposal may not be necessary if everyone
is already set on doing a UASF, but miners seem to optimize for short-term
profits and this may make it easier for BitMain to accept its fate in
losing the ASICBoost advantage.
Here is a possible trustless contract protocol where contributors could
pledge to a Segwit bounty which would be paid out to miners iff Segwit is
activated, else the funds are returned to the contributor:
# Setup
- The contributor picks a possible future height where Segwit may be
activated and when the funds should be released, H.
- The contributor chooses a bounty contribution amount X.
- The contributor generates 3 private keys (k1, k2, and k3) and
corresponding pubkeys (K1, K2, and K3).
- The contributor creates and broadcasts the Funding Transaction, which has
2 outputs:
* Output 0, X BTC, P2SH redeem script:
<H> CHECKLOCKTIMEVERIFY DROP
<K1> CHECKSIGVERIFY
* Output 1, 0.00001 BTC, P2SH redeem script:
<H> CHECKLOCKTIMEVERIFY DROP
<K2> CHECKSIGVERIFY
- The contributor builds the Segwit Assertion Transaction:
* nTimeLock set to H
* Input 0, spends from Funding Transaction output 1, signed with k2,
SIGHASH_ALL
* Output 0, 0.00001 BTC, P2WPKH using K3
- The contributor builds the Bounty Payout Transaction:
* nTimeLock set to H
* Input 0, spends from Funding Transaction output 0, signed with k1,
SIGHASH_ALL
* Input 1, spends from Segwit Assertion Transaction output 0, signed with
k3, SIGHASH_ALL
* No outputs, all funds are paid to the miner
- The contributor publishes the Segwit Assertion Transaction and Bounty
Payout Transaction (with signatures) somewhere where miners can find them
# Process
1. After the setup, miners can find Funding Transactions confirmed on the
chain, and verify the other 2 transactions are correct and have valid
signatures. They can sum all the valid bounty contracts they find to factor
into their expected mining profit.
2A. Once the chain reaches height H-1, if Segwit has activated, miners can
claim the bounty payout by including the Segwit Assertion and Bounty Payout
transactions in their block H. Since Segwit has activated, the output from
the Segwit Assertion tx can be spent by the Bounty Payout, so both
transactions are valid and the miner receives the funds.
2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout
is not valid since it spends a P2WPKH output, preventing the miner from
including the Bounty Payout transaction in the block. (However, the output
of the Segwit Assertion tx can be claimed since it is treated as
anyone-can-spend, although this is not an issue since it is a very small
amount). The contributor can reclaim the funds from Output 0 of the Funding
tx by creating a new transaction, signed with k1.
# Notes
- This is likely a win-win scenario for the contributors, since Segwit
activating will likely increase the price of Bitcoin, which gives a
positive return if the price increases enough. If it does not activate, the
funds will be returned so nothing is at risk.
- Contributors could choose H heights on or slightly after an upcoming
possible activation height. If contributors pay out to many heights, then
the bounty can be split among many miners, it doesn't have to be
winner-take-all.
- If Segwit does not activate at H, the contributor has until the next
possible activation height to claim their refund without risking it being
taken by another miner. This could be outsourced by signing a refund
transaction which pays a fee to some third-party who will be online at H
and can broadcast the transaction. If the contributor wants to pay a bounty
for a later height, they should create a new contract otherwise a miner
could invalidate the payout by spending the output of the Segwit Assertion.
Thanks, I'd like to hear everyone's thoughts. Let me know if you find any
glaring flaws or have any other comments.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170427/a76ab38d/attachment.html>