Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

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 implement
this bribe.

Despite the flaws in this draft BIP, the goal is to start consolidating
this information into a more compact format. This BIP is *only*
meant to address the Blind Merging Mining Process of drivechains. It does
*not* address the withdrawal process from drivechain -> bitcoin.

>The problem I see is that to send a bribe one must first post a
transaction to a script that uses the OP_BRIBE code that fixes the critical
hash (and the sidechain id), and then a second transaction is needed to pay
the bribe to the miner.

That is intentional, this allows for a competitive process (like bitcoin
mining) for a block to be 'found' on the sidechain. The OP_BV output that
rewards
the bitcoin miner the most amount of money should be the one that is
included in the bitcoin blockchain. If I understand your scheme correctly,
you are
assuming the the bitcoin miner is *also* following the sidechain --
Sztorc's scheme does not make this assumption. The *number one goal* of BMM
is to *minimize* the resource burden on bitcoin miners for mining on a
drivechain.

To gmaxwell/luke-jr,

I agree my commitment scheme is flawed. Thanks for pointing it out. Is
there any way we could manipulate a coinbase transaction
into spending these OP_BV outputs? According to instagibbs, and AFIACT he
is right, we cannot have coinbase transactions
spend any outputs in previous blocks without a hard fork. This is
unfortunate because it might make more sense for the coinbase transaction
to spend these OP_BV outputs. We could design the coinbase transaction's
scriptSig to push the critical hash onto the stack and
place an OP_EQUAL on the OP_BV output to verify they were equal.
If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
correctly, I *think*
this solution might fix that as well.

Another way we could fix this is by *fixing* the drivechain indices.
Therefore the mining rewards and witness commitments must
*not* occupy one of those indices -- but can occupy any other indice in the
coinbase output.
This would give us future flexibility for committing to new soft forks. For
instance, we would say
the mining reward must *not* be index 0 of the coinbase transaction, but
can occupy index 1 - 256. The same would apply for witness commitments.

-Chris

On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor 
wrote:

> 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 bribe.
>
> The problem I see is that to send a bribe one must first post a
> transaction to a script that uses the OP_BRIBE code that fixes the critical
> hash (and the sidechain id), and then a second transaction is needed to pay
> the bribe to the miner.
>
> I suggest instead to use a 0 output value with some currently non-standard
> OP_RETURN output script that specifies the critical hash (and the sidechain
> id), similar to ZmnSCPxj's idea.  The difference is that I we would
> soft-fork a rule that says that such an output is only legal when a miner
> places the same critical hash suitably in their coinbase output.
>
> OP_RETURN outputs are prunable from the UTXO set.  The special bribe
> output can be fixed to 0 value because the bribe will be paid using the
> transaction's fees.  To perform a bribe, a user creates and signs a
> transaction containing one (or more) of these special bribe outputs.  The
> fee of this transaction constitutes the bribe, and any change the user has
> can be sent back to themselves.  This way only a single transaction is
> required to make a bribe.  I didn't really understand the bribe refund
> mechanism, but I think the fact that the bribe can be done in a single
> transaction this way alleviates any need for bribe refunds.
>
> Hopefully I have understood the goal of this proposal.
>
>
> On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 would be unsuccessful.
>>
>> In turn, miners would likely react to this, and try to improve the state
>> of affairs by offering users the privilege of occupying transaction slot
>> #2 (ie, the one right after the coinbase). Users would need to 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Russell O'Connor via bitcoin-dev]

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 proposed
soft-fork rules, only one of these Bribe TXOs can be included per coinbase
slot (except unless there are identical Bribe TXOs), so there is a
competition of which one of a set of conflicting Bribe TXOs will be
included in the next block.  (That said, the losing set Bribe TXOs can be
included in the later blocks; I don't know what this means semantically for
sidechains; however, the same thing occurs with your proposal as well.)

On Wed, Jun 28, 2017 at 7:47 PM, Chris Stewart  wrote:

> 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 implement
> this bribe.
>
> Despite the flaws in this draft BIP, the goal is to start consolidating
> this information into a more compact format. This BIP is *only*
> meant to address the Blind Merging Mining Process of drivechains. It does
> *not* address the withdrawal process from drivechain -> bitcoin.
>
> >The problem I see is that to send a bribe one must first post a
> transaction to a script that uses the OP_BRIBE code that fixes the critical
> hash (and the sidechain id), and then a second transaction is needed to pay
> the bribe to the miner.
>
> That is intentional, this allows for a competitive process (like bitcoin
> mining) for a block to be 'found' on the sidechain. The OP_BV output that
> rewards
> the bitcoin miner the most amount of money should be the one that is
> included in the bitcoin blockchain. If I understand your scheme correctly,
> you are
> assuming the the bitcoin miner is *also* following the sidechain --
> Sztorc's scheme does not make this assumption. The *number one goal* of BMM
> is to *minimize* the resource burden on bitcoin miners for mining on a
> drivechain.
>
> To gmaxwell/luke-jr,
>
> I agree my commitment scheme is flawed. Thanks for pointing it out. Is
> there any way we could manipulate a coinbase transaction
> into spending these OP_BV outputs? According to instagibbs, and AFIACT he
> is right, we cannot have coinbase transactions
> spend any outputs in previous blocks without a hard fork. This is
> unfortunate because it might make more sense for the coinbase transaction
> to spend these OP_BV outputs. We could design the coinbase transaction's
> scriptSig to push the critical hash onto the stack and
> place an OP_EQUAL on the OP_BV output to verify they were equal.
> If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
> correctly, I *think*
> this solution might fix that as well.
>
> Another way we could fix this is by *fixing* the drivechain indices.
> Therefore the mining rewards and witness commitments must
> *not* occupy one of those indices -- but can occupy any other indice in
> the coinbase output.
> This would give us future flexibility for committing to new soft forks.
> For instance, we would say
> the mining reward must *not* be index 0 of the coinbase transaction, but
> can occupy index 1 - 256. The same would apply for witness commitments.
>
> -Chris
>
> On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor  > wrote:
>
>> 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 bribe.
>>
>> The problem I see is that to send a bribe one must first post a
>> transaction to a script that uses the OP_BRIBE code that fixes the critical
>> hash (and the sidechain id), and then a second transaction is needed to pay
>> the bribe to the miner.
>>
>> I suggest instead to use a 0 output value with some currently
>> non-standard OP_RETURN output script that specifies the critical hash (and
>> the sidechain id), similar to ZmnSCPxj's idea.  The difference is that I we
>> would soft-fork a rule that says that such an output is only legal when a
>> miner places the same critical hash suitably in their coinbase output.
>>
>> OP_RETURN outputs are prunable from the UTXO set.  The special bribe
>> output can be fixed to 0 value because the bribe will be paid using the
>> transaction's fees.  To perform a bribe, a user creates and signs a
>> transaction containing one (or more) of these special bribe outputs.  The
>> fee of this transaction constitutes the bribe, and any change the user has
>> can be sent back to themselves.  This way only a single transaction is
>> 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Russell O'Connor via bitcoin-dev]

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 bribe.

The problem I see is that to send a bribe one must first post a transaction
to a script that uses the OP_BRIBE code that fixes the critical hash (and
the sidechain id), and then a second transaction is needed to pay the bribe
to the miner.

I suggest instead to use a 0 output value with some currently non-standard
OP_RETURN output script that specifies the critical hash (and the sidechain
id), similar to ZmnSCPxj's idea.  The difference is that I we would
soft-fork a rule that says that such an output is only legal when a miner
places the same critical hash suitably in their coinbase output.

OP_RETURN outputs are prunable from the UTXO set.  The special bribe output
can be fixed to 0 value because the bribe will be paid using the
transaction's fees.  To perform a bribe, a user creates and signs a
transaction containing one (or more) of these special bribe outputs.  The
fee of this transaction constitutes the bribe, and any change the user has
can be sent back to themselves.  This way only a single transaction is
required to make a bribe.  I didn't really understand the bribe refund
mechanism, but I think the fact that the bribe can be done in a single
transaction this way alleviates any need for bribe refunds.

Hopefully I have understood the goal of this proposal.


On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 would be unsuccessful.
>
> In turn, miners would likely react to this, and try to improve the state
> of affairs by offering users the privilege of occupying transaction slot
> #2 (ie, the one right after the coinbase). Users would need to trust
> miners for this, which introduces a cost friction which is pure
> deadweight loss. And, it might be easier for larger/older miners to be
> trustworthy than smaller/newer ones.
>
> Your way is actually very similar to mine. Mine _forces_ the bribe to be
> in the earliest txn (the coinbase) and to only occur once. Yours doesn't
> do anything to refund the briber, if the sidechain (but not the
> mainchain) reorganizes (as it can easily do, if an older sidechain
> parent is extended while the mainchain proceeds normally). This creates
> additional risk.
>
> I think mine is also much more space-efficient. Even if ours each had
> exactly one h* per sidechain per block, it seems that I only require one
> hash to be communicated (plus an indicator byte, and a ~2 byte counter
> for the ratchet), whereas you require two. Since its overhead per
> sidechain per block, it actually might really add up.
>
> Thanks,
> Paul
>
>
>
> On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
> > 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
> > mainchain-miner in the Merkle tree root.
> >
> > It would not require a softfork.
> >
> > --
> >
> > I have an alternate proposal that sidechains and altcoins that want to
> > do "blinded" merge mining can use without a softfork:
> >
> > 1.  Encode a block header as a simple cons-pair, with the head as the
> > block and the tail as the parent cons-pair.
> > 1.1.  This can be encoded as a 32-byte hash of the block including its
> > header, and the 32-byte hash of the parent cons-pair.
> > 1.2.  This is now the actual "chain" in the sidecoin/altcoin blockchain.
> > 2.  When a sidechain-node wants to know the consensus, it downloads
> > mainchain-blocks and looks for OP_RETURN's.
> > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
> > list) as the current cons-pair, it scans each OP_RETURN transaction.
> > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal to
> > the current cons-pair, look for the side block indicated and confirm its
> > correctness.  If correct, update the current cons-pair for the hash of
> > the OP_RETURN data.
> > 2.2.  When reaching the latest mainchain block, the current cons-pair is
> > now the sidecoin/altcoin latest block.
> > 2.3.  Note that if multiple OP_RETURN in a block match the current
> > cons-pair, the first one is considered the correct chain.  This property
> > means that the sidechain/altchain can only have a 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Paul Sztorc via bitcoin-dev]

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 would be unsuccessful.

In turn, miners would likely react to this, and try to improve the state
of affairs by offering users the privilege of occupying transaction slot
#2 (ie, the one right after the coinbase). Users would need to trust
miners for this, which introduces a cost friction which is pure
deadweight loss. And, it might be easier for larger/older miners to be
trustworthy than smaller/newer ones.

Your way is actually very similar to mine. Mine _forces_ the bribe to be
in the earliest txn (the coinbase) and to only occur once. Yours doesn't
do anything to refund the briber, if the sidechain (but not the
mainchain) reorganizes (as it can easily do, if an older sidechain
parent is extended while the mainchain proceeds normally). This creates
additional risk.

I think mine is also much more space-efficient. Even if ours each had
exactly one h* per sidechain per block, it seems that I only require one
hash to be communicated (plus an indicator byte, and a ~2 byte counter
for the ratchet), whereas you require two. Since its overhead per
sidechain per block, it actually might really add up.

Thanks,
Paul



On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
> 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
> mainchain-miner in the Merkle tree root.
> 
> It would not require a softfork.
> 
> --
> 
> I have an alternate proposal that sidechains and altcoins that want to
> do "blinded" merge mining can use without a softfork:
> 
> 1.  Encode a block header as a simple cons-pair, with the head as the
> block and the tail as the parent cons-pair.
> 1.1.  This can be encoded as a 32-byte hash of the block including its
> header, and the 32-byte hash of the parent cons-pair.
> 1.2.  This is now the actual "chain" in the sidecoin/altcoin blockchain.
> 2.  When a sidechain-node wants to know the consensus, it downloads
> mainchain-blocks and looks for OP_RETURN's.
> 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
> list) as the current cons-pair, it scans each OP_RETURN transaction.
> 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal to
> the current cons-pair, look for the side block indicated and confirm its
> correctness.  If correct, update the current cons-pair for the hash of
> the OP_RETURN data.
> 2.2.  When reaching the latest mainchain block, the current cons-pair is
> now the sidecoin/altcoin latest block.
> 2.3.  Note that if multiple OP_RETURN in a block match the current
> cons-pair, the first one is considered the correct chain.  This property
> means that the sidechain/altchain can only have a chainsplit if the
> mainchain has a chainsplit.
> 3.  When a sidechain-miner wants to create a side-block, it generates a
> new cons-pair and creates an OP_RETURN transaction for it, paying a
> mainchain-miner to include it in the next mainchain-block.
> 3.1.  The sidechain-miner risks that its competitors will outbid it and
> get its OP_RETURN earlier in a mainchain-block (or earlier in the order
> of transactions).  It can mitigate this risk by updating itself to
> become a mainchain-miner, it can then keep its OP_RETURN transaction
> private and put it earlier in the block, ensuring it will "win" the
> sidechain-consensus if it wins the mainchain-consensus.
> 
> Regards,
> ZmnSCPxj
> 
>  Original Message 
> Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
> Merge Mined drivechains
> Local Time: June 28, 2017 8:37 AM
> UTC Time: June 28, 2017 12:37 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion 
> 
>  
>   BIP: 
>   Layer: Consensus (Soft fork)
>   Title: OP_BRIBEVERIFY
>   Author: Chris Stewart 
>   Status: Draft
>   Type: Standards Track
>   Created: 2017-06-27
> 
> 
> 
> ==Abstract==
> 
> This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
> scripting system that allows for a user to bribe a miner to include a hash
> in the coinbase transaction's output.
> 
> 
> ==Summary==
> 
> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
> critical hash is included at the given vout index in the coinbase
> transaction
> the script evaluates to true. Otherwise, the script will fail.
> 
> This allows sidechains to be merged mined against
> bitcoin without burdening bitcoin miners with extra resource requirements.
> 
> ==Motivation==
> 
> The 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Paul Sztorc via bitcoin-dev]

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
>> transaction
>> the script evaluates to true. Otherwise, the script will fail.
>>
>> This allows sidechains to be merged mined against
>> bitcoin without burdening bitcoin miners with extra resource requirements.
> 
> I don't see how. It seems like the logical outcome from this is "whoever pays 
> the most gets the next sidechain block"... That's not particularly useful for 
> merge mining.

This is one of the assumptions which BMM exploits, see #4 of:
http://www.truthcoin.info/blog/blind-merged-mining/#focus

The idea is that this is a safe assumption, because it is already the
case today. If we assume that miners revenue-maximize, and further that
the "bidder" frames his payments in tx-fees, then a willing buyer can
control the next block by simply filling it with high tx-fee spam.
Anyone who is willing to pay the most can already 'get' the next
mainchain block (only, indirectly).

> 
>> This enables sidechains in Bitcoin.
> 
> There are different kinds of sidechains...
> 
> Federated peg: this already works on Bitcoin.
> SPV/SNARK peg: this isn't enabled by your BIP.
> Drivechains: this isn't enabled by your BIP.
> 
> How do you say this enables any kind of sidechain?

Yes, it is unclear, but Chris' email is specific to blind merged mining
(BMM), which is kind of a "sidechains +". So this does not directly
enable any sidechains. Instead, it enables the "+" part.

--Paul
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Paul Sztorc via bitcoin-dev]

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,
index 1).

I had assumed that this would go the same for BMM, since it is all
drivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM
included), would claim one output index.

Moreover, while DC claims an output "slot", the claim doesn't need to be
permanent...if the BTC-value of the relevant output is not equal to
zero, the BMM code could just ignore it. The sidechains would each
assume that no sidechain block was merged-mined in this period. And DC
would assume that no forward progress was made on any side-to-main
transfers (ie, that everyone "abstained").

Perhaps that addresses Greg's third, first, and second concerns.

I am having some trouble understanding concern #4. I think you mean to
say that the output coins of a transaction which is encumbered by OP
BribeVerify are different from other coins. Indeed they are, and coins
locked by OP BribeVerify cannot be moved until their associated
sidechain header ("h*") is ~100 blocks deep in the sidechain (hence the
earlier conversation about the "ratchet", which attempts to measure this).

The timeline that CryptAxe and I discussed, as I last remember it, is that:
0. (setup) The sidechain node is run by a briber, and this briber
constructs a sidechain block paying himself all the fees. These fees
total q=4 BTC.
1. Negotiations happen out of bound, between Briber and all miners.
(still setting up) Each new transaction the Briber makes, he chooses a
completely new h* (which is trivial for him to do by incrementing a
nonce/anything), and he may as well also fund each of these txns with
the same unspent output (owned by him). This prevents a miner from
annoying the Briber by including many ultimately-invalid transactions.
2. Miner1 includes h* in the coinbase of today's block thus BMMing a
sidechain block today, he also includes the transaction he just
negotiated with the Briber (call it, "tx1"). This tx1 is one where
Briber pays z=(q-0.001) to an op_bribe script that will eventually pay z
BTC to Bitcoin address M owned by "miner1".
3. After ~123 blocks, the ratchet (on mainchain) indicates that the
sidechain headers have advanced sequentially by x=100 places. This
allows miner1 to spend from tx1 to address M.
3. OR, after ~250 blocks, the second timing threshold is reached*, and
the Briber can spend from his script back to an address he controls
(also predefined in steps 1 and 2).


*This is the dual-threshold time-locking technique that the LN uses to
prove a negative.

The second timelock setup is required because it is possible that miner
will earnestly BMM a sidechain block, but then reorg such that this
block is orphaned out of the longest (side)chain. In this case, the
Briber doesn't get paid his tx-fees, so he is entitled to a refund.


So, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm
glad Chris is taking the initiative and doing this work. And I'm sorry
if the documentation has shifted too much. At the bottom of the spec
blog post there are some notes, but they probably aren't very helpful.



On 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
>  wrote:
>> A new block rule is added which requires that the miner's coinbase reward be
>> at index 0 in the coinbase transaction's output vector.
> 
> This is an absurd restriction-- I hope it was not your intent to
> directly ban P2Pool and probably any other form of decentralized or
> less centralized mining pooling... but thats what doing that does.
> 
>> It also fixes the witness commitment output to be at index 1 of the coinbase 
>> transaction's output vector.
> 
> This removes important flexibility that was intentionally preserved.
> What happens when an additional commitment is needed for bitcoin?
> must some sidechain be irreparably destroyed? looks like it in  your
> proposal.
> 
>> For instance, the mimblewimble sidechain could correspond to index 2 of the 
>> vector outputs on the coinbase transaction.
> 
> And what happens if index 1 isn't present? if index 35 is used must
> there be 34 dummy outputs?
> 
>> 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
> 
> This is not monotone/reorg safe. It means that the output coins (if
> any) are not equivalently fungible with other bitcoins (for, e.g. 100
> blocks) because if there is a reorg this transaction cannot be
> restored to the chain.  It's also impure and not compatible with
> caching, which would be unfortunate and slow 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[ZmnSCPxj via bitcoin-dev]

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 mainchain-miner in the 
Merkle tree root.
It would not require a softfork.
--
I have an alternate proposal that sidechains and altcoins that want to do 
"blinded" merge mining can use without a softfork:
1. Encode a block header as a simple cons-pair, with the head as the block and 
the tail as the parent cons-pair.
1.1. This can be encoded as a 32-byte hash of the block including its header, 
and the 32-byte hash of the parent cons-pair.
1.2. This is now the actual "chain" in the sidecoin/altcoin blockchain.
2. When a sidechain-node wants to know the consensus, it downloads 
mainchain-blocks and looks for OP_RETURN's.
2.1. Starting with its genesis cons-pair hash (equivalent to the empty list) as 
the current cons-pair, it scans each OP_RETURN transaction.
2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to the 
current cons-pair, look for the side block indicated and confirm its 
correctness. If correct, update the current cons-pair for the hash of the 
OP_RETURN data.
2.2. When reaching the latest mainchain block, the current cons-pair is now the 
sidecoin/altcoin latest block.
2.3. Note that if multiple OP_RETURN in a block match the current cons-pair, 
the first one is considered the correct chain. This property means that the 
sidechain/altchain can only have a chainsplit if the mainchain has a chainsplit.
3. When a sidechain-miner wants to create a side-block, it generates a new 
cons-pair and creates an OP_RETURN transaction for it, paying a mainchain-miner 
to include it in the next mainchain-block.
3.1. The sidechain-miner risks that its competitors will outbid it and get its 
OP_RETURN earlier in a mainchain-block (or earlier in the order of 
transactions). It can mitigate this risk by updating itself to become a 
mainchain-miner, it can then keep its OP_RETURN transaction private and put it 
earlier in the block, ensuring it will "win" the sidechain-consensus if it wins 
the mainchain-consensus.
Regards,
ZmnSCPxj
 Original Message 
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge 
Mined drivechains
Local Time: June 28, 2017 8:37 AM
UTC Time: June 28, 2017 12:37 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Protocol Discussion 

BIP: 
Layer: Consensus (Soft fork)
Title: OP_BRIBEVERIFY
Author: Chris Stewart 
Status: Draft
Type: Standards Track
Created: 2017-06-27

==Abstract==
This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
scripting system that allows for a user to bribe a miner to include a hash
in the coinbase transaction's output.
==Summary==
BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
critical hash is included at the given vout index in the coinbase transaction
the script evaluates to true. Otherwise, the script will fail.
This allows sidechains to be merged mined against
bitcoin without burdening bitcoin miners with extra resource requirements.
==Motivation==
The current political climate of bitcoin is extremely contentious. Many 
community members
have different visions of what bitcoin is. This op code is meant to
enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge Mining].
This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners can
bribe bitcoin miners to to include their block hash in the bitcoin blockchain. 
If their block
is included in the coinbase transaction's vout, it is assumed that block is a 
mined block on the sidechain.
This will allow various factions of the community to realize their vision on 
their own separate
blockchain that is interoperable with the bitcoin blockchain. This allows those 
factions to use
bitcoin as a 'reserve currency' for their own network.
===Commitment Structure===
A new block rule is added which requires that the miner's coinbase reward be at 
index 0 in the coinbase transaction's output vector.
It also fixes the witness commitment output to be at index 1 of the coinbase 
transaction's output vector.
This is needed so we can reliably tell what vout corresponds to what 
drivechain. For instance, the mimblewimble sidechain
could correspond to index 2 of the vector outputs on the coinbase transaction.
The commitment is recorded in a scriptPubKey of the coinbase 
transaction. It must be at least 34 bytes in size
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 32 bytes (0x20)
32-byte - block hash
the 35th byte and onward have no consensus meaning.
===OP_BRIBEVERIFY op code===
This op code reads two arguments from the stack. The stack top is expected to 
be a sidechain id for which this user attempting to blind merge mine for.
The next 

[bitcoin-dev] Replay protection via CHECKSIG

[Anthony Towns via bitcoin-dev]

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
signatures can optionally specify an additional integer block-height. If
this is provided, the message hash is combined with the block hash at
the given height, before the signature is created/verified, and therefore
the signature becomes invalid if used on a chain that does not have that
particular block in its history [0].

It adds four bytes to a signature that uses the feature [1], along with
a block hash lookup, and some extra sha ops when verifying the signature,
but it otherwise seems pretty lightweight, and scales to an arbitrary
number of forks including a pretty fair range of hard forks, as far
as I can see, without requiring any coordination between any of the
chains. So I think it's superior to what Johnson Lau proposed in January
[2] or BIP 115 from last year [3].

Thoughts? Has this been proposed before and found wanting already?

Cheers,
aj

[0] For consistency, you could use the genesis block hash if the signature
doesn't specify a block height, which would lock a given signature to
"bitcoin" or "testnet" or "litecoin", which might be beneficial.

[1] Conceivably a little less if you allow "-5" to mean "5 blocks ago"
and miners replace a four byte absolute reference ("473000") with a
one or two byte relative reference ("-206") when grabbing transactions
from the mempool to put in the block template.

[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html

[3] https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev