[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS

I forget to send to bitcoin-dev. > A related problem is that if this transaction is reorged out during an innocent reorg, one that doesn't involve a double spend, the transaction may never get back in unless it occurs at exactly the same height, which is not guaranteed. > > This affects

Re: [bitcoin-dev] About ASICBoost

On Sun, Oct 2, 2016 at 10:51 PM, Matt Corallo via bitcoin-dev wrote: > If you had acted in a way which indicated even the slightest regard for > centralization pressure and the harm it can do to Bitcoin in the > long-term, then I dont think many would be

[bitcoin-dev] The use OP_COUNT_ACKS for paying for a common good for miners

One side benefit of OP_COUNT_ACKS is that it enables a completely different use case: It allow users to pay for any service miners can provide as group for the common good (e.g. fee payment smoothing over many blocks). For instance, users could pay miners to jointly buy better Internet service to

Re: [bitcoin-dev] About ASICBoost

> When you proposed the extra nonce space BIP [1], you had already > applied for your ASICBOOST patent [2] without disclosure in the BIP > [1] nor in your Bitcoin Core pull request #5102 [2]. There may be quite a few things to clarify here, and a possible misunderstanding: The BIP proposal [1]

Re: [bitcoin-dev] About ASICBoost

Replies to comments inline. Matt On 10/02/16 17:13, Sergio Demian Lerner via bitcoin-dev wrote: > Please Peter Todd explain here all what you want to say about a patent > of a hardware design for an ASIC. > > Remember that ASICBoost is not the only patent out there, there are at > least three

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > But I would argue that in this scenario, the only way it >> would become invalid is the equivalent of a double-spend... and therefore >> it >> may be acceptable in relation to this

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

> I don't know if it's possible to implement decentralised sidechains without > "breaking" this rule. > I haven't really been following the sidechain developements, but my understanding was that redemption from a side chain would be two phase. The person unpegging the funds provides a proof that

Re: [bitcoin-dev] About ASICBoost

It's good you bring that point, and it's very interesting to analyze what happened then. We shared our findings with some core developers much earlier than the BIP proposal. Wether they kept it secret or they shared it with some ASIC manufacturers is something I don't know. I even mentioned my

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote: > Is this particular proposal encumbered by a licensing type, patent, or > pending patent which would preclude it from being used in the bitcoin > project? If not, you're wildly off topic. I think that's the concern: we

Re: [bitcoin-dev] About ASICBoost

Sergio, It is critically important to the future of Bitcoin that consensus code avoid any unnecessary entanglements with patents because "the free market" allows you and anyone else to make consensus change proposals that rely on (unknown) patents - but this is something we should all be working

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

If I understand this BIP correctly, the values pushed onto the stack by the OP_COUNT_ACKS operation depends on the ack and nack counts relative to the block that this happens to be included in. This isn't going to be acceptable. The validity of a transaction should always be monotone in the

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL endorse DPL or will make the required actions to make sure the things developed by RSK remain free and open. This was not a priority until now, but coding was. For me, coding always is the priority. I will discuss

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sun, Oct 02, 2016 at 12:18:08PM -0500, Andrew Johnson wrote: > The purpose of this list is highly technical discussion, not political > disagreements. > > Is this particular proposal encumbered by a licensing type, patent, or > pending patent which would preclude it from being used in the

[bitcoin-dev] About ASICBoost

Please Peter Todd explain here all what you want to say about a patent of a hardware design for an ASIC. Remember that ASICBoost is not the only patent out there, there are at least three similar patents, filed by major Bitcoin ASIC manufacturers in three different countries, on similar

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote: > Peter, are you really going to try to down vote a decent free and > open-source proposal that benefits all the Bitcoin community including > you and your future children because a personal attack to me without any > logic or

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

Peter, are you really going to try to down vote a decent free and open-source proposal that benefits all the Bitcoin community including you and your future children because a personal attack to me without any logic or basis? Is that the way you collaborate to improving Bitcoin? I just can't

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via bitcoin-dev wrote: I think your history of patenting(1) Bitcoin consensus relevant technology is sufficient by itself to be extremely dubious of any proposals coming from you or your colleagues; patents on Bitcoin consensus

[bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

Since ScalingBitcoin is close, I think this is a good moment to publish our proposal on drivechains. This BIP proposed the drivechain we'd like to use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitcoin. Until that happens, we're using a federated approach. I'm