[bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.

I've proposed a revision to BIP-1 that removes the option to license the work under the OPL: https://github.com/bitcoin/bips/pull/446 The OPL contains troublesome terms where the licensor can elect to prohibit print publication of the work as well as the creation of modified versions without

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

Joe sends Alice 5 BTC (UTXO 0). Fred sends Alice 4 BTC (UTXO 1). Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2). Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's transfer to Bob. Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so, it is possible that

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

In the innocent use case of this opcode, a double-spend has already occurred, and this should be a strict improvement. In the non-innocent abuse of this opcode, I don't see that it's any worse than simply double-spending. Would this proposal be better or otherwise more acceptable, if a

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev wrote: > In the innocent use case of this opcode, a double-spend has already occurred, > and this should be a strict improvement. In the non-innocent abuse of this > opcode, I don't see that it's

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob complains about getting paid faster, Alice can let him know that Fred essentially stole his coins and that when she is certain he (and she) can't get them

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote: > On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote: > > > > I think BIPs should be self-contained, or rely on previous BIPs, > > whenever possible. Referencing an external formatting document should > > be

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Friday, 23 September 2016 13:42:36 CEST Christian Decker via bitcoin-dev wrote: > > I have to disagree. That is not malleability. Creating a new document > > and re- signing it is not changing anything. Its re-creating. > > Something that the owner of the coin has every right to do. > Same

Re: [bitcoin-dev] On-going work: Coin Selection Simulation

Hi Daniel, Thank you for your mail. My simulation of the Mycelium coin selection does add small change outputs to the fee, but I did get your boundary wrong. Instead of the 5460, I dropped at the dust boundary which calculates to 4440 in my simulation. Therefore, I think that the results in the

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev wrote: > Not sure if the comparison to XML and HTML holds: the lack of closing > tags makes the meaning of individual tokens ambiguous, like I pointed > out before. The use of segments gives at most two levels of

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Thu, Sep 22, 2016 at 08:37:29PM +0200, Tom via bitcoin-dev wrote: > On Thursday, 22 September 2016 14:27:29 CEST Peter Todd wrote: > > CSV uses per-input sequence numbers; you only have a per-tx equivalent. > > I think you misunderstand tagged systems at a very basic level. You think > that

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote: > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin > scripting system to address reissuing bitcoin transactions when the coins > they spend have been conflicted/double-spent. > >

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

I believe Bitcoin currently enjoys the property that during an "innocent" re-org, i.e. a reorg in which no affected transactions are being double spent, all affected transactions can always eventually get replayed, so long as the re-org depth is less than 100. My concern with this proposed

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

On Fri, Sep 23, 2016 at 06:57:57PM +, Gregory Maxwell via bitcoin-dev wrote: > On Fri, Sep 23, 2016 at 1:43 PM, Russell O'Connor via bitcoin-dev > wrote: > > I believe Bitcoin currently enjoys the property that during an "innocent" > > re-org, i.e. a