What if a transaction is tagged as eligible for replace by fee possibly
using the lock_time (0xFFFE) so the parties involved can decide
which approach works best for them. If the receiving side doesn't see
the type of transaction they want they consider it invalid. The payment
protocol ca
I've been wondering why a blockchain is necessary at all. Ripple doesn't
have one (I haven't looked closely at their implementation but it seems
reasonable to go without one).
When you do blockchain based transaction confirmations, you give full
authority to the miner that finds the transaction bl
On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote:
> One point that was only recently exposed to me is that replacement
> combined with child-pays-for-parent creates a new kind of double spend
> _defense_: If someone double spends a payment to an online key of
> yours, you can instant
On Tue, May 21, 2013 at 01:39:30PM +1000, Robert Backhaus wrote:
> 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
Not at all - ACK from me, fwiw. Any attempt at a double spend should be
shouted from the housetops.
What Miners should do with that is still up for debate, it seems. My
opinion is that they should hold on and attempt to confirm the first,
letting it go only if a conflicting transaction is mined el
On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen wrote:
> I'm very much in favor of double-spend propagation across the network.
Absolutely.
(to the list:) Is there anyone who is not? (assuming that it doesn't
allow arbitrary traffic multiplication, which is easily solved)
-
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.
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
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 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
14 matches
Mail list logo
