From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
Date: Wed, 24 May 2017 09:50:22 +0100 [thread overview]
Message-ID: <CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com> (raw)
In-Reply-To: <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin@gmail•com> wrote:
>
> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
> probably the most human-readable description.
>
I guess I was looking for the detail you get in the code, but without
having to read the code.
My quick reading gives that the sidechain codes (critical hashes) are added
when a coinbase is processed.
Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
a potential critical hash.
When the block is processed, the key value pair (hash, block_height) is
added to a hash map.
The OP_BRIBE opcode checks that the given hash is in the hash map and
replaces the top element on the stack with the pass/fail result.
It doesn't even check that the height matches the current block, though
there is a comment that that is a TODO.
I agree with ZmnSCPxj, when updating a nop, you can't change the stack. It
has to fail the script or do nothing.
OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
coinbase, or cause a script failure otherwise.
Another concern is that you could have multiple bribes for the same chain
in a single coinbase. That isn't fair and arguably what the sidechain
miner is paying for is to get his hash exclusively into the block.
I would suggest that the output is
OP_RETURN <sidechain_id> <critical hash>
Then add the rule that only the first hash with a particular sidechain id
actually counts.
This forces the miner to only accept the bribe from 1 miner for each
sidechain for each block. If he tries to accept 2, then only the first one
counts.
OP_BRIBE_VERIFY could then operate as follows
<block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
This causes the script to fail if
<block height> does not match the block height, or
<critical hash> is not the hash for the sidechain with <sidechain_id>, or
there is no hash for that sidechain in the block's coinbase
If you want reduce the number of drops, you could serialize the info into a
single push.
This has the advantage that a sidechain miner only has to pay if his block
is accepted in the next bitcoin block. Since he is the only miner for that
sidechain that gets into the main bitcoin block, he is pretty much
guaranteed to form the longest chain.
Without that rule, sidechain miners could end up having to pay even though
it doesn't make their chain the longest.
How are these transactions propagated over the network? For relaying, you
could have the rule that the opcode passes as long as <block height> is
near the current block height. Maybe require that they are in the future.
They should be removed from the memory pool once the block height has
arrived, so losing miners can re-spend those outputs.
This opcode can be validated without needing to look at other blocks, which
is good for validating historical blocks.
I am still looking at the deposit/withdrawal code.
[-- Attachment #2: Type: text/html, Size: 4543 bytes --]
next prev parent reply other threads:[~2017-05-24 8:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:17 Paul Sztorc
2017-05-22 13:33 ` Peter Todd
2017-05-22 15:30 ` Paul Sztorc
2017-05-28 21:07 ` Peter Todd
[not found] ` <CAJowKgJjNaoWVc=QXfOqH3OdBPoKm3qkfUNpKV6oKLSRx_fD0g@mail.gmail.com>
[not found] ` <CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
2017-05-29 5:54 ` Erik Aronesty
2017-05-30 5:11 ` Paul Sztorc
2017-06-09 21:54 ` Sergio Demian Lerner
2017-06-10 16:28 ` Paul Sztorc
2017-05-22 14:39 ` ZmnSCPxj
2017-05-22 16:19 ` Paul Sztorc
2017-05-22 19:12 ` Tier Nolan
2017-05-22 20:00 ` Paul Sztorc
2017-05-23 9:51 ` Tier Nolan
2017-05-23 14:22 ` Paul Sztorc
2017-05-24 8:50 ` Tier Nolan [this message]
2017-05-24 10:05 ` Tier Nolan
2017-05-24 17:32 ` CryptAxe
2017-05-25 22:08 ` Tier Nolan
2017-06-18 14:36 ` Chris Stewart
2017-06-18 21:27 ` CryptAxe
[not found] ` <CAGL6+mGZZ=wG8P_DNj3PXVf==mLjJwA_bESh0_UdH2iVBY7GQA@mail.gmail.com>
2017-06-19 15:41 ` Chris Stewart
2017-05-23 0:13 ` ZmnSCPxj
2017-05-23 14:12 ` Paul Sztorc
2017-05-23 23:26 ` ZmnSCPxj
2017-06-10 17:04 ` [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc
2017-06-18 21:30 ` Tao Effect
2017-06-19 16:04 ` Paul Sztorc
[not found] ` <CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
2017-06-20 11:54 ` Paul Sztorc
2017-06-20 13:38 ` Erik Aronesty
2017-06-22 13:27 ` Paul Sztorc
2017-06-22 13:45 ` Erik Aronesty
2017-06-22 20:30 ` Paul Sztorc
2017-06-23 14:19 ` Erik Aronesty
2017-06-23 14:51 ` Moral Agent
2017-06-23 18:11 ` Paul Sztorc
2017-07-12 22:43 ` Tao Effect
2017-07-13 0:26 ` Paul Sztorc
2017-07-13 1:15 ` Tao Effect
2017-07-13 2:58 ` Paul Sztorc
2017-07-13 3:24 ` Tao Effect
2017-07-13 15:39 ` Paul Sztorc
2017-07-13 13:17 ` Hampus Sjöberg
2017-07-13 17:04 ` Paul Sztorc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox