I've revived BIP 2 (from Deferred Status) and given it some updates. Most
notably, I have reworked it to be a *replacement* for BIP 1 rather than an
addendum.
https://github.com/luke-jr/bips/blob/bip0002_squash/bip-0002.mediawiki
Please review it. If things go well, hopefully we can get this do
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 thei
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 b
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 any worse than simply double-spending.
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 UT
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 specified
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 reorg in which no affected transactions are
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 reorg in which no affected transactions are being double
> spent, all affected transactions can always eventually get replayed, so l
On Fri, Sep 23, 2016 at 09:57:01AM +, 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.
>
> https://github
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.
>
> https://github.com/luke-jr/bip
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 operati
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 thin
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 nesting,
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 ta
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 h
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
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.
https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
Does this seem like a good idea/approa
Hello Murch,
> I've corrected the boundary in my simulation now and will update my
> simulation results before Scaling Bitcoin. Thank you very much for your
> correction.
Okay, if you already had included this logic I guess it wont change the
result that much if the cut off is 4440 or 5460sat.
B
18 matches
Mail list logo
