I'm very much in favor of double-spend propagation across the network.
Most of the arguments about replace-based-on-fee /
child-pays-burn-coins / etc are orthogonal.
Letting a merchant know ASAP that their customer is trying to cheat
them is, in my opinion, strictly better than what we have now.
This was meant to go to everyone:
On 5/20/13 7:45 PM, Jeff Garzik wrote:
> On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach wrote:
>> So as to remain reasonably compliant with RFC 4122, I recommend that we
>> use Version 4 (random) UUIDs, with the random bits extracted from the
>> double-SHA256
Bitcoin currently uses raw hashes extensively as UUIDs; whether the payment
protocol should be influence by that or not, I've not given thought to yet.
Some alt coins may share a blockchain, or even merely the genesis block (two
currently do; despite one of those being a scamcoin, I think the po
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille wrote:
> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus wrote:
>> So the decision has been made to make 0-conf double spends trivial, so no
>> one will ever trust 0-confs. If a later transaction appears with a larger
>> fee, it will be considered t
A part of my reason for sending this email was a quick discussion I had
with Gavin at the BitCoin conference. I was under the strong impression
that double spend notification was something he approved of and was
considering implementing himself.
In the case of a double spend, If the receiving
That's good - what I had taken away from the replace-by-fee discussions was
that it was finally decided.
My opinion is that we should be doing what we can to make 0-confs as
reliable as possible - which will always be 'not very', but a solid system
to notify on attempted double-spends is a good st
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, "Jeff Garzik" wrote:
> On Mon, May 20, 2013 at 7:59 PM,
Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
it will go anywhere. Certainly no decision was made. The arguments for it
are based on some quite faulty thinking about economics. Double spend
notifications have been proposed a long time ago, I believe Matt has
indicated
On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach wrote:
> So as to remain reasonably compliant with RFC 4122, I recommend that we
> use Version 4 (random) UUIDs, with the random bits extracted from the
> double-SHA256 hash of the genesis block of the chain. (For colored
> coins, the colored coin
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus wrote:
> So the decision has been made to make 0-conf double spends trivial, so no
> one will ever trust 0-confs. If a later transaction appears with a larger
> fee, it will be considered to be the valid one, and the first one dropped,
> as long as
Personally, I agree, but a different decision has been made by the main
devs.
The issue is this: consider two transactions in the unconfirmed pool. One
transaction has 2BTC input, 1.5BTC to one address (the payment), .4995 to
another address (change) and .0005 standard fee. Another transaction
app
The current BitCoin implementation is subject to relatively easy double
spend attack for 0 confirmation payments. Yet 0 confirmation payments
are needed for typical in person transactions like most purchases at a
local business.
Notably, it is easy to transmit two transactions from the same ou
At the developer round-table it was asked if the payment protocol would
alt-chains, and Gavin noted that it has a UTF-8 encoded string
identifying the network ("main" or "test"). As someone with two
proposals in the works which also require chain/coin identification (one
for merged mining, one
This sounds similar to the "bitcoin2" branch I created a while back -
basically a "next"-like branch, but for hardforking changes that refused to
run without the -testnet option. There's so much non-hardforking code that can
be written/tested, at this point, that I think it was and maybe is prem
14 matches
Mail list logo
