{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-24\n📝 Original message:On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc \u003ctruthcoin at gmail.com\u003e wrote:\n\n\u003e\n\u003e If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is\n\u003e probably the most human-readable description.\n\u003e\n\nI guess I was looking for the detail you get in the code, but without\nhaving to read the code.\n\nMy quick reading gives that the sidechain codes (critical hashes) are added\nwhen a coinbase is processed.\n\nAny coinbase output that has the form \"OP_RETURN \u003c32 byte push\u003e\" counts as\na potential critical hash.\n\nWhen the block is processed, the key value pair (hash, block_height) is\nadded to a hash map.\n\nThe OP_BRIBE opcode checks that the given hash is in the hash map and\nreplaces the top element on the stack with the pass/fail result.\n\nIt doesn't even check that the height matches the current block, though\nthere is a comment that that is a TODO.\n\nI agree with ZmnSCPxj, when updating a nop, you can't change the stack.  It\nhas to fail the script or do nothing.\n\nOP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the\ncoinbase, or cause a script failure otherwise.\n\nAnother concern is that you could have multiple bribes for the same chain\nin a single coinbase.  That isn't fair and arguably what the sidechain\nminer is paying for is to get his hash exclusively into the block.\n\nI would suggest that the output is\n\nOP_RETURN \u003csidechain_id\u003e \u003ccritical hash\u003e\n\nThen add the rule that only the first hash with a particular sidechain id\nactually counts.\n\nThis forces the miner to only accept the bribe from 1 miner for each\nsidechain for each block.  If he tries to accept 2, then only the first one\ncounts.\n\nOP_BRIBE_VERIFY could then operate as follows\n\n\u003cblock height\u003e \u003csidechain_id\u003e \u003ccritical hash\u003e OP_BRIBE_VERIFY\n\nThis causes the script to fail if\n  \u003cblock height\u003e does not match the block height, or\n  \u003ccritical hash\u003e is not the hash for the sidechain with \u003csidechain_id\u003e, or\n  there is no hash for that sidechain in the block's coinbase\n\nIf you want reduce the number of drops, you could serialize the info into a\nsingle push.\n\nThis has the advantage that a sidechain miner only has to pay if his block\nis accepted in the next bitcoin block.  Since he is the only miner for that\nsidechain that gets into the main bitcoin block, he is pretty much\nguaranteed to form the longest chain.\n\nWithout that rule, sidechain miners could end up having to pay even though\nit doesn't make their chain the longest.\n\nHow are these transactions propagated over the network?  For relaying, you\ncould have the rule that the opcode passes as long as \u003cblock height\u003e is\nnear the current block height.  Maybe require that they are in the future.\nThey should be removed from the memory pool once the block height has\narrived, so losing miners can re-spend those outputs.\n\nThis opcode can be validated without needing to look at other blocks, which\nis good for validating historical blocks.\n\nI am still looking at the deposit/withdrawal code.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170524/ac8f7126/attachment.html\u003e"}