On 7/13/2017 4:22 PM, Chris Stewart wrote:
> In general though, I'm still unclear of what purpose the 'Ratchet'
> serves. Can you either link to documentation about it or write
> something up quick?
>
> -Chris
In Bitcoin, new coins are held for 100 blocks. One result of this is
that the coins can'
I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Pau
In case anyone wants to do this, I added the CSidechainAddress class to the
mainchainBMM branch of the Drivechain project a long time ago. The only
purpose it serves right now is to show that sidechain deposit addresses can
start with a '4'. We could simply add the sha256 hash described by Paul to
I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).
Assume there are N sidechains.
In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain h
On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
>
> >>In my scheme, if you read carefully through the pseudocode, a block
> list node is valid only if its block is valid.
> >
> >It seems this is a contradiction against the "blind" part of blind
> merge mining. How can a bitcoin blockchain node enforce this w
Hi Russell/ZmnSCPxj,
I think you guys are right. The only problem I can see with it is
replaceability of the bribe transaction. If the 'Bribe' is the fee on the
transaction it isn't clear to me what the best way to replace/remove it is.
If we have the amount in the output (instead of the fee) we
On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1. Remove the necessity of coinbase commitments. The miner commits to
> the sidechain_id and h* in the t
>>In my scheme, if you read carefully through the pseudocode, a block list node
>>is valid only if its block is valid.
>
>It seems this is a contradiction against the "blind" part of blind merge
>mining. How can a bitcoin blockchain node enforce this without tracking the
>sidechain?
From:
https
Hi ZmnSCPxj,
In my scheme, if you read carefully through the pseudocode, a block list
> node is valid only if its block is valid.
>
It seems this is a contradiction against the "blind" part of blind merge
mining. How can a bitcoin blockchain node enforce this without tracking the
sidechain?
Bas
Good morning Paul, Chris, and CryptAxe,
@Paul
>> >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
Hi,
Sorry for the delay, I overlooked this email until now. I see that Chris
and CryptAxe both answered but I will also answer, because the message
was addressed to me.
On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the ear
To ZmnSCPxj:
I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
But I suppose you are considering something like the
>I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
Maybe I am misunderstanding you, but isn't this a flaw not a featu
Good Morning Paul,
>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 a
ons-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
orrect, 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 multipl
dechain-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
>
rivate 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 Mine
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,
nchain-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
On 27 June 2017 at 22:20, 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
>> transacti
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.
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
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 includ
25 matches
Mail list logo
