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 11:05:38 +0100 [thread overview]
Message-ID: <CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> 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
>
>
I was thinking more on the process for these transactions.
I assume that the process is
- sidechain miner broadcasts transaction with OP_BRIBE output
- this transaction ends up in the memory pool of miners
- Miners add the transaction to their next block
- Miners add a transaction which spends the output to one of their own
addresses
I think you need an additional rule that OP_BRIBE checks fails unless the
output is locked 100 or more blocks.
The output script would end up something like
IF
<block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
<public key> OP_CHECKSIG
ENDIF
This output acts like "anyone can spend" for the one block height.
Otherwise, only the sidechain miner can spend the output.
This allows the sidechain miner to reclaim their coins if the transaction
ends up in a different block.
OP_BRIBE_VERIFY would have an additional rule
The script to fails if
one or more of the transaction outputs start with something other than
the template
<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
The template is
<100> OP_CHECKSEQUENCE_VERIFY
[-- Attachment #2: Type: text/html, Size: 3092 bytes --]
next prev parent reply other threads:[~2017-05-24 10:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:17 [bitcoin-dev] Drivechain -- Request for Discussion 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
2017-05-24 10:05 ` Tier Nolan [this message]
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-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com \
--to=tier.nolan@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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