{"type":"rich","version":"1.0","author_name":"npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","author_url":"https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}