📅 Original date posted:2017-06-28
📝 Original message:Chris/Greg,
For pending withdrawals (side-to-main transfers), all of the data is
stored in a teeny tiny extension block which contains all the drivechain
data (which we called "MinerDB"). And miners were supposed to commit to
this and put it in the coinbase in some locate-able place (for example,
index 1).
I had assumed that this would go the same for BMM, since it is all
drivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM
included), would claim one output index.
Moreover, while DC claims an output "slot", the claim doesn't need to be
permanent...if the BTC-value of the relevant output is not equal to
zero, the BMM code could just ignore it. The sidechains would each
assume that no sidechain block was merged-mined in this period. And DC
would assume that no forward progress was made on any side-to-main
transfers (ie, that everyone "abstained").
Perhaps that addresses Greg's third, first, and second concerns.
I am having some trouble understanding concern #4. I think you mean to
say that the output coins of a transaction which is encumbered by OP
BribeVerify are different from other coins. Indeed they are, and coins
locked by OP BribeVerify cannot be moved until their associated
sidechain header ("h*") is ~100 blocks deep in the sidechain (hence the
earlier conversation about the "ratchet", which attempts to measure this).
The timeline that CryptAxe and I discussed, as I last remember it, is that:
0. (setup) The sidechain node is run by a briber, and this briber
constructs a sidechain block paying himself all the fees. These fees
total q=4 BTC.
1. Negotiations happen out of bound, between Briber and all miners.
(still setting up) Each new transaction the Briber makes, he chooses a
completely new h* (which is trivial for him to do by incrementing a
nonce/anything), and he may as well also fund each of these txns with
the same unspent output (owned by him). This prevents a miner from
annoying the Briber by including many ultimately-invalid transactions.
2. Miner1 includes h* in the coinbase of today's block thus BMMing a
sidechain block today, he also includes the transaction he just
negotiated with the Briber (call it, "tx1"). This tx1 is one where
Briber pays z=(q-0.001) to an op_bribe script that will eventually pay z
BTC to Bitcoin address M owned by "miner1".
3. After ~123 blocks, the ratchet (on mainchain) indicates that the
sidechain headers have advanced sequentially by x=100 places. This
allows miner1 to spend from tx1 to address M.
3. OR, after ~250 blocks, the second timing threshold is reached*, and
the Briber can spend from his script back to an address he controls
(also predefined in steps 1 and 2).
*This is the dual-threshold time-locking technique that the LN uses to
prove a negative.
The second timelock setup is required because it is possible that miner
will earnestly BMM a sidechain block, but then reorg such that this
block is orphaned out of the longest (side)chain. In this case, the
Briber doesn't get paid his tx-fees, so he is entitled to a refund.
So, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm
glad Chris is taking the initiative and doing this work. And I'm sorry
if the documentation has shifted too much. At the bottom of the spec
blog post there are some notes, but they probably aren't very helpful.
On 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> A new block rule is added which requires that the miner's coinbase reward be
>> at index 0 in the coinbase transaction's output vector.
>
> This is an absurd restriction-- I hope it was not your intent to
> directly ban P2Pool and probably any other form of decentralized or
> less centralized mining pooling... but thats what doing that does.
>
>> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
>
> This removes important flexibility that was intentionally preserved.
> What happens when an additional commitment is needed for bitcoin?
> must some sidechain be irreparably destroyed? looks like it in your
> proposal.
>
>> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
>
> And what happens if index 1 isn't present? if index 35 is used must
> there be 34 dummy outputs?
>
>> This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
>
> This is not monotone/reorg safe. It means that the output coins (if
> any) are not equivalently fungible with other bitcoins (for, e.g. 100
> blocks) because if there is a reorg this transaction cannot be
> restored to the chain. It's also impure and not compatible with
> caching, which would be unfortunate and slow block propagation.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Paul Sztorc [ARCHIVE] /
npub10t…w9uu9
2023-06-07 18:03:40
in reply to nevent1q…xhry
Author Public Key
npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9Published at
2023-06-07 18:03:40Event JSON
{
"id": "d12ff8a60a5c63090146bcc528391407a7042431ebc5b9e41dced2e5ac70df0e",
"pubkey": "7ac0bd39b854f24cbf067103758f3a9d398c23832d6d75824d190ae35c6c23be",
"created_at": 1686161020,
"kind": 1,
"tags": [
[
"e",
"ceb90cc04617646a4ed9dd447660214398effadc094de82e24452613b40f4a5e",
"",
"root"
],
[
"e",
"d80860bb4f219c3ba01278571184a2cfbb210760a42d09a73066bc7782ced91b",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-06-28\n📝 Original message:Chris/Greg,\n\nFor pending withdrawals (side-to-main transfers), all of the data is\nstored in a teeny tiny extension block which contains all the drivechain\ndata (which we called \"MinerDB\"). And miners were supposed to commit to\nthis and put it in the coinbase in some locate-able place (for example,\nindex 1).\n\nI had assumed that this would go the same for BMM, since it is all\ndrivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM\nincluded), would claim one output index.\n\nMoreover, while DC claims an output \"slot\", the claim doesn't need to be\npermanent...if the BTC-value of the relevant output is not equal to\nzero, the BMM code could just ignore it. The sidechains would each\nassume that no sidechain block was merged-mined in this period. And DC\nwould assume that no forward progress was made on any side-to-main\ntransfers (ie, that everyone \"abstained\").\n\nPerhaps that addresses Greg's third, first, and second concerns.\n\nI am having some trouble understanding concern #4. I think you mean to\nsay that the output coins of a transaction which is encumbered by OP\nBribeVerify are different from other coins. Indeed they are, and coins\nlocked by OP BribeVerify cannot be moved until their associated\nsidechain header (\"h*\") is ~100 blocks deep in the sidechain (hence the\nearlier conversation about the \"ratchet\", which attempts to measure this).\n\nThe timeline that CryptAxe and I discussed, as I last remember it, is that:\n0. (setup) The sidechain node is run by a briber, and this briber\nconstructs a sidechain block paying himself all the fees. These fees\ntotal q=4 BTC.\n1. Negotiations happen out of bound, between Briber and all miners.\n(still setting up) Each new transaction the Briber makes, he chooses a\ncompletely new h* (which is trivial for him to do by incrementing a\nnonce/anything), and he may as well also fund each of these txns with\nthe same unspent output (owned by him). This prevents a miner from\nannoying the Briber by including many ultimately-invalid transactions.\n2. Miner1 includes h* in the coinbase of today's block thus BMMing a\nsidechain block today, he also includes the transaction he just\nnegotiated with the Briber (call it, \"tx1\"). This tx1 is one where\nBriber pays z=(q-0.001) to an op_bribe script that will eventually pay z\nBTC to Bitcoin address M owned by \"miner1\".\n3. After ~123 blocks, the ratchet (on mainchain) indicates that the\nsidechain headers have advanced sequentially by x=100 places. This\nallows miner1 to spend from tx1 to address M.\n3. OR, after ~250 blocks, the second timing threshold is reached*, and\nthe Briber can spend from his script back to an address he controls\n(also predefined in steps 1 and 2).\n\n\n*This is the dual-threshold time-locking technique that the LN uses to\nprove a negative.\n\nThe second timelock setup is required because it is possible that miner\nwill earnestly BMM a sidechain block, but then reorg such that this\nblock is orphaned out of the longest (side)chain. In this case, the\nBriber doesn't get paid his tx-fees, so he is entitled to a refund.\n\n\nSo, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm\nglad Chris is taking the initiative and doing this work. And I'm sorry\nif the documentation has shifted too much. At the bottom of the spec\nblog post there are some notes, but they probably aren't very helpful.\n\n\n\nOn 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:\n\u003e On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e A new block rule is added which requires that the miner's coinbase reward be\n\u003e\u003e at index 0 in the coinbase transaction's output vector.\n\u003e \n\u003e This is an absurd restriction-- I hope it was not your intent to\n\u003e directly ban P2Pool and probably any other form of decentralized or\n\u003e less centralized mining pooling... but thats what doing that does.\n\u003e \n\u003e\u003e It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.\n\u003e \n\u003e This removes important flexibility that was intentionally preserved.\n\u003e What happens when an additional commitment is needed for bitcoin?\n\u003e must some sidechain be irreparably destroyed? looks like it in your\n\u003e proposal.\n\u003e \n\u003e\u003e For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.\n\u003e \n\u003e And what happens if index 1 isn't present? if index 35 is used must\n\u003e there be 34 dummy outputs?\n\u003e \n\u003e\u003e This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra\n\u003e \n\u003e This is not monotone/reorg safe. It means that the output coins (if\n\u003e any) are not equivalently fungible with other bitcoins (for, e.g. 100\n\u003e blocks) because if there is a reorg this transaction cannot be\n\u003e restored to the chain. It's also impure and not compatible with\n\u003e caching, which would be unfortunate and slow block propagation.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "5f2759e0c7ea97f195723a8700761c73163cad4aa684fe8dafc0fd6e1ceef8a5acef97c956fa9957014186916c69d814b7c978c566679286545c2c2c78499684"
}