Hi Russell,
>I haven't really been following the drivechain discussion; I have found
the documentation about how drivechains are supposed to work scattered and
difficult to follow. So, without advocating for or against this proposal,
I'd also suggest that adding an opcode is not the best way to im
HI Chris,
My proposal isn't intended to assume that the bitcoin miner is also
following the sidechain. In line with my understanding of your proposal,
I'm only proposing to bribe miners to put particular data into the coinbase
output regardless of any semantics that doing so may entail. By my pro
I haven't really been following the drivechain discussion; I have found the
documentation about how drivechains are supposed to work scattered and
difficult to follow. So, without advocating for or against this proposal,
I'd also suggest that adding an opcode is not the best way to implement
this b
Hi ZmnSCPxj,
It seems that, in your version, the "bribers" would react to the scheme
in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
fee per Kb) is low.
In short, there would be many bribe-attempts (each of which would take
up space in mainchain blocks), almost all of which
Hi Luke,
On 6/28/2017 1:20 AM, Luke Dashjr via bitcoin-dev wrote:
> On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
>> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
>> critical hash is included at the given vout index in the coinbase
>> tra
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,
Good morning.
I still do not see what this does that cannot be done by:
OP_RETURN
A transaction with such an output would allow sidechain-miners to bribe
mainchain-miners by paying a transaction fee if the transaction containing this
OP_RETURN is included in a block and committed to by a mainch
Hi,
I thought of a possibly interesting way to prevent transaction replay in
the event of a chain split, that seems better to the other approaches
I've seen. Basically, update OP_CHECKSIG (and MULTISIG and the VERIFY
variants, presumably via segwit versioning or using a NOP opcode) so that
signatu
