On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
>
> > - Otherwise of hash is compared to lower of blockhash.
>
> Lower in what endian? Why only that endian? Why only lower? I c
On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
> Prefer a three-arg version (gbits-to-compare, blocknum, hash):
> - If is 0 or > 256, invalid.
> - If the hash length is not ( + 7) / 8, invalid.
This means zero padding on-chain, which would be undesirable.
Rather "at most" and have
Luke Dashjr via bitcoin-dev writes:
> 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
Thank you Luke, this makes it clearer.
It doesn't change that this scenario is an attack that doesn't give the
attacker any benefit and the attacked doesn't loose anything either (as
Dave pointed out).
This is a completely academical problem that assumes so many stupid
mistakes from software a
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
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
14 matches
Mail list logo
