Re: [bitcoin-dev] Drivechain -- Request for Discussion

> > Since the sidechain has the sidechain BMM headers that they want the LD > (bribe) data for, I think that they could specifically request LD data > relevant only to that sidechain by providing a list of hashes to the > mainchain, and the mainchain can return a list of boolean values telling > th

Re: [bitcoin-dev] Drivechain -- Request for Discussion

> >OP_RETURN > > I think it is redundant here to have the , we can > implicitly assume what the sidechain_id is since we have a fixed set > of drivechains. I.e. mining reward is index 0, mimblewimble sidechain > is index 1, etc. CryptAxe has specific indexes defined already in his > implementatio

Re: [bitcoin-dev] Drivechain -- Request for Discussion

>OP_RETURN I think it is redundant here to have the , we can implicitly assume what the sidechain_id is since we have a fixed set of drivechains. I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc. CryptAxe has specific indexes defined already in his implementation: https://gi

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Hi Sergio / everyone, As some of you may know, Sergio and I each did an implementation of drivechain. I started working on mine, and he started working on his, and then I didn't hear from him for awhile about what he was doing. Anyways, with two versions, we each have an opportunity to double-che

Re: [bitcoin-dev] Drivechain -- Request for Discussion

I'm a bit late to this party. I just want to add that there exists an hybrid model where both a federation and the miners provide acknowledges (sometimes known as "votes" in drivechain terms and "multi-signatures" in a federation) of the sidechain state. My Drivechain proposal (Feb 2016) was tailo

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Hi Peter, Responses below. On 5/28/2017 5:07 PM, Peter Todd wrote: > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote: >> Surprisingly, this requirement (or, more precisely, this incentive) does >> not effect miners relative to each other. The incentive to upgrade is only >> for the pu

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Seems to me an obvious use case for drive chains are to have high speed small transactions on a side chain, eventually cleared to the main chain. Not sure why miners would want this to fail any more than any other side chain, like Liquid or lightning. On May 28, 2017 5:23 PM, "Peter Todd via bi

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote: > Surprisingly, this requirement (or, more precisely, this incentive) does > not effect miners relative to each other. The incentive to upgrade is only > for the purpose of preventing a "theft" -- defined as: an improper > withdrawal from

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Also the block number can only change by +1 or -1, so when a new h* is > added to the > queue it must be compared to the most recent h* in the queue. > std::abs(queue.back().nHeight - ToAdd.

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Your assumptions of the bribe process are indeed correct you seem to have a pretty good handle on all of that. Hopefully I can clear up a few things. BMM among other things is still a work in progress so you'll have to wait a bit longer before any reorg code is on github. The "ratchet" system on g

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Wed, May 24, 2017 at 9:50 AM, Tier Nolan wrote: > OP_BRIBE_VERIFY could then operate as follows > >OP_BRIBE_VERIFY > > This causes the script to fail if >does not match the block height, or >is not the hash for the sidechain with , or > there is no hash for that sidechain in the

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc 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 give

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning, >> (What happens if the h* to be put in the coinbase, by chance - even very >> unlikely chance - is 0? Then OP_NOP4 is not the same as >> OP_BRIBE scripts in result - the former will be rejected by old nodes, >> the latter will be accepted by new nodes) > >That would indeed be a bu

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote: > On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc > wrote: > > I would replace "Bitcoins you manage to steal" with "Bitcoins you > manage to double-spend". Then, it still seems the same to me. > > > With

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On 5/22/2017 8:13 PM, ZmnSCPxj wrote: > Good morning, > > > >>What you read is only an introduction of BMM. You may also consult the > notes (at the bottom of the BMM post) or the code, although this is time > consuming of course. > > Looking over the code, I have a question: Is OP_BRIBE supp

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc wrote: > I would replace "Bitcoins you manage to steal" with "Bitcoins you manage > to double-spend". Then, it still seems the same to me. > > With double spending, you can only get ownership of coins that you owned at some point in the past. Coins th

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning, >What you read is only an introduction of BMM. You may also consult the notes >(at the bottom of the BMM post) or the code, although this is time consuming >of course. Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked in, or hardforked? From my under

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" wrote: On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think t

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think they are the same. With Bitcoin, you only get to reverse recent

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On May 22, 2017 10:39 AM, "ZmnSCPxj" wrote: Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ >From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transacti

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation? OP_is_

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Charlie, I'll be mostly in the tech track, of course. And I've already planned to meet RSK guys after their event tomorrow. Ryan, the more review the better. We aren't in any direct rush, other than the natural desire to have cool things as early as possible. Peter, responses below: On May 22, 2

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote: > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual > sid