* [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
@ 2014-04-22 21:31 Peter Todd
2014-04-23 4:29 ` Jan Møller
2014-04-23 4:45 ` Tom Harding
0 siblings, 2 replies; 8+ messages in thread
From: Peter Todd @ 2014-04-22 21:31 UTC (permalink / raw)
To: bitcoin-development; +Cc: support
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
You may have seen my reddit post of the same title a few days ago:
http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/
I've done some more experiments since, with good results. For instance
here's a real-world double-spend of the gambling service Lucky Bit:
Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20
01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000
Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a
01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac00000000
The double-spend was mined by Eligius and made use of the fact that
Eligius blacklists transactions to a number of addresses considered to
be "spam" by the pool operators; affected transactions are not added to
the Eligus mempool at all. Lucky Bit has a real-time display of bets as
they are accepted; I simply watched that display to determine whether or
not I had lost. With Eligius at 8% and the house edge at 1.75% the
attack is profitable when automated. My replace-by-fee patch(1) was
used, although as there are only a handful of such nodes running - none
connected directly to Eligius from what I can determine - I submitted
the double-spend transactions to Eligius directly via their pushtxn
webform.(2)
Of course, this is an especially difficult case, as you must send the
double-spend after the original transaction - normally just sending a
non-standard tx to Eligius first would suffice. Note how this defeats
Andresen's double-spend-relay patch(3) as proposed since the
double-spend is a non-standard transaction.
In discussion with Lucky Bit they have added case-specific code to
reject transactions with known blacklisted outputs; the above
double-spend I preformed is no longer possible. Of course, if the
(reused) Lucky Bit addresses are added to that blacklist, that approach
isn't viable - I suggest they switch to a scheme where addresses are not
reused. (per-customer? rotated?) They also have added code to keep track
of double-spend occurances and trigger human intervention prior to
unacceptable losses. Longer term as with most services (e.g. Just-Dice)
they intend to move to off-chain transactions. They are also considering
implementing replace-by-fee scorched earth(4) - in their case a single
pool, such as Eligius, implementing it would be enough to make the
attack unprofitable. It may also be enough security to allow users to
use their deposits prior to the first confirmation in a Just-Dice style
off-chain implementation.
1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
2) http://eligius.st/~wizkid057/newstats/pushtxn.php
3) https://github.com/bitcoin/bitcoin/pull/3354 and
https://github.com/bitcoin/bitcoin/pull/3883
4) https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
--
'peter'[:-1]@petertodd.org
000000000000000024abc60eebba42333d74b30635ca5fb0b7c776a579c307a8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-23 4:45 ` Tom Harding
@ 2014-04-23 4:03 ` Matt Whitlock
2014-04-23 22:29 ` Tom Harding
2014-04-23 4:22 ` Jeff Garzik
1 sibling, 1 reply; 8+ messages in thread
From: Matt Whitlock @ 2014-04-23 4:03 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-development
On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
> A network where transaction submitters consider their (final)
> transactions to be unchangeable the moment they are transmitted, and
> where the network's goal is to confirm only transactions all of whose
> UTXO's have not yet been seen in a final transaction's input, has a
> chance to be such a network.
Respectfully, this is not the goal of miners. The goal of miners is to maximize profits. Always will be. If they can do that by enabling replace-by-fee (and they can), then they will. Altruism does not factor into business.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-23 4:45 ` Tom Harding
2014-04-23 4:03 ` Matt Whitlock
@ 2014-04-23 4:22 ` Jeff Garzik
1 sibling, 0 replies; 8+ messages in thread
From: Jeff Garzik @ 2014-04-23 4:22 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Dev
A lot of these "should the network..." questions depend on business
rules and business models.
Even if a 0-conf double spend is possible in a given business
situation, the incentives quite often are aligned to avoid
double-spend attempts in any case. Any physical good being shipped
can "accept" the transaction, and then wait for confirmations before
shipping. Digital goods might be accepted for 0-conf payment from
users who have a good history with the merchant. The 0-conf attacker
will tend to /not/ be a regular user, and also have many other typical
markers of a fraudster.
The subset of (a) double-spend attackers making a one-time or
short-term attack on (b) a naive merchant with mistuned business rules
will tend to be very small.
On Wed, Apr 23, 2014 at 12:45 AM, Tom Harding <tomh@thinlink•com> wrote:
>
> Since no complete solution to preventing 0-confirmation respends in the
> bitcoin network has been proposed, or is likely to exist, when
> evaluating partial solutions let's ask "what kind of network does this
> move toward?"
>
> Does the solution move toward a network with simple rules, where the
> certainty that decreases from the many-confirmations state, down to 1
> confirmation, does not immediately disappear just below the time of 1
> confirmation?
>
> A network where transaction submitters consider their (final)
> transactions to be unchangeable the moment they are transmitted, and
> where the network's goal is to confirm only transactions all of whose
> UTXO's have not yet been seen in a final transaction's input, has a
> chance to be such a network. If respend attempts are broadcast widely,
> then after a time on the order of transaction propagation time (<< 1
> minute) has passed, participants have a good chance to avoid relying on
> a transaction whose funds are spent to someone else. This is both
> because after this time the network is unlikely to split on the primacy
> of one spend, and because the recipient, able to see a respend attempt,
> can withhold delivery of the good or service until confirmation.
>
> Or, does the solution move toward a network that
> - Requires participants to have knowledge of the policies of multiple
> entities, like Eligius and whoever maintains the blacklist mentioned below?
> - Requires a transaction submitter to intently monitor transactions
> and try to climb over the top of attempted respends with
> "scorched-earth" triple spends, until a random moment some time between,
> let's say, 5 and 15 minutes in the future?
> - Punts the problem to off-network solutions?
>
>
> On 4/22/2014 1:31 PM, Peter Todd wrote:
>> You may have seen my reddit post of the same title a few days ago:
>>
>> http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/
>>
>> I've done some more experiments since, with good results. For instance
>> here's a real-world double-spend of the gambling service Lucky Bit:
>>
>> Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20
>>
>> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000
>>
>> Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a
>>
>> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac00000000
>>
>> The double-spend was mined by Eligius and made use of the fact that
>> Eligius blacklists transactions to a number of addresses considered to
>> be "spam" by the pool operators; affected transactions are not added to
>> the Eligus mempool at all. Lucky Bit has a real-time display of bets as
>> they are accepted; I simply watched that display to determine whether or
>> not I had lost. With Eligius at 8% and the house edge at 1.75% the
>> attack is profitable when automated. My replace-by-fee patch(1) was
>> used, although as there are only a handful of such nodes running - none
>> connected directly to Eligius from what I can determine - I submitted
>> the double-spend transactions to Eligius directly via their pushtxn
>> webform.(2)
>>
>> Of course, this is an especially difficult case, as you must send the
>> double-spend after the original transaction - normally just sending a
>> non-standard tx to Eligius first would suffice. Note how this defeats
>> Andresen's double-spend-relay patch(3) as proposed since the
>> double-spend is a non-standard transaction.
>>
>> In discussion with Lucky Bit they have added case-specific code to
>> reject transactions with known blacklisted outputs; the above
>> double-spend I preformed is no longer possible. Of course, if the
>> (reused) Lucky Bit addresses are added to that blacklist, that approach
>> isn't viable - I suggest they switch to a scheme where addresses are not
>> reused. (per-customer? rotated?) They also have added code to keep track
>> of double-spend occurances and trigger human intervention prior to
>> unacceptable losses. Longer term as with most services (e.g. Just-Dice)
>> they intend to move to off-chain transactions. They are also considering
>> implementing replace-by-fee scorched earth(4) - in their case a single
>> pool, such as Eligius, implementing it would be enough to make the
>> attack unprofitable. It may also be enough security to allow users to
>> use their deposits prior to the first confirmation in a Just-Dice style
>> off-chain implementation.
>>
>> 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
>>
>> 2) http://eligius.st/~wizkid057/newstats/pushtxn.php
>>
>> 3) https://github.com/bitcoin/bitcoin/pull/3354 and
>> https://github.com/bitcoin/bitcoin/pull/3883
>>
>> 4) https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-22 21:31 [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise Peter Todd
@ 2014-04-23 4:29 ` Jan Møller
2014-04-23 6:35 ` Mark Friedenbach
2014-04-23 4:45 ` Tom Harding
1 sibling, 1 reply; 8+ messages in thread
From: Jan Møller @ 2014-04-23 4:29 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
>Of course, this is an especially difficult case, as you must send the
>double-spend after the original transaction - normally just sending a
>non-standard tx to Eligius first would suffice. Note how this defeats
>Andresen's double-spend-relay patch(3) as proposed since the
>double-spend is a non-standard transaction.
Why can't you send a non-standard tx to Eligius first in this scenario?
Is it because LuckyBit is connected directly to Eligius, and does Eligius
relay (not only mine) non-standard transactions?
[-- Attachment #2: Type: text/html, Size: 1317 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-22 21:31 [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise Peter Todd
2014-04-23 4:29 ` Jan Møller
@ 2014-04-23 4:45 ` Tom Harding
2014-04-23 4:03 ` Matt Whitlock
2014-04-23 4:22 ` Jeff Garzik
1 sibling, 2 replies; 8+ messages in thread
From: Tom Harding @ 2014-04-23 4:45 UTC (permalink / raw)
To: bitcoin-development
Since no complete solution to preventing 0-confirmation respends in the
bitcoin network has been proposed, or is likely to exist, when
evaluating partial solutions let's ask "what kind of network does this
move toward?"
Does the solution move toward a network with simple rules, where the
certainty that decreases from the many-confirmations state, down to 1
confirmation, does not immediately disappear just below the time of 1
confirmation?
A network where transaction submitters consider their (final)
transactions to be unchangeable the moment they are transmitted, and
where the network's goal is to confirm only transactions all of whose
UTXO's have not yet been seen in a final transaction's input, has a
chance to be such a network. If respend attempts are broadcast widely,
then after a time on the order of transaction propagation time (<< 1
minute) has passed, participants have a good chance to avoid relying on
a transaction whose funds are spent to someone else. This is both
because after this time the network is unlikely to split on the primacy
of one spend, and because the recipient, able to see a respend attempt,
can withhold delivery of the good or service until confirmation.
Or, does the solution move toward a network that
- Requires participants to have knowledge of the policies of multiple
entities, like Eligius and whoever maintains the blacklist mentioned below?
- Requires a transaction submitter to intently monitor transactions
and try to climb over the top of attempted respends with
"scorched-earth" triple spends, until a random moment some time between,
let's say, 5 and 15 minutes in the future?
- Punts the problem to off-network solutions?
On 4/22/2014 1:31 PM, Peter Todd wrote:
> You may have seen my reddit post of the same title a few days ago:
>
> http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/
>
> I've done some more experiments since, with good results. For instance
> here's a real-world double-spend of the gambling service Lucky Bit:
>
> Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20
>
> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000
>
> Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a
>
> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac00000000
>
> The double-spend was mined by Eligius and made use of the fact that
> Eligius blacklists transactions to a number of addresses considered to
> be "spam" by the pool operators; affected transactions are not added to
> the Eligus mempool at all. Lucky Bit has a real-time display of bets as
> they are accepted; I simply watched that display to determine whether or
> not I had lost. With Eligius at 8% and the house edge at 1.75% the
> attack is profitable when automated. My replace-by-fee patch(1) was
> used, although as there are only a handful of such nodes running - none
> connected directly to Eligius from what I can determine - I submitted
> the double-spend transactions to Eligius directly via their pushtxn
> webform.(2)
>
> Of course, this is an especially difficult case, as you must send the
> double-spend after the original transaction - normally just sending a
> non-standard tx to Eligius first would suffice. Note how this defeats
> Andresen's double-spend-relay patch(3) as proposed since the
> double-spend is a non-standard transaction.
>
> In discussion with Lucky Bit they have added case-specific code to
> reject transactions with known blacklisted outputs; the above
> double-spend I preformed is no longer possible. Of course, if the
> (reused) Lucky Bit addresses are added to that blacklist, that approach
> isn't viable - I suggest they switch to a scheme where addresses are not
> reused. (per-customer? rotated?) They also have added code to keep track
> of double-spend occurances and trigger human intervention prior to
> unacceptable losses. Longer term as with most services (e.g. Just-Dice)
> they intend to move to off-chain transactions. They are also considering
> implementing replace-by-fee scorched earth(4) - in their case a single
> pool, such as Eligius, implementing it would be enough to make the
> attack unprofitable. It may also be enough security to allow users to
> use their deposits prior to the first confirmation in a Just-Dice style
> off-chain implementation.
>
> 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
>
> 2) http://eligius.st/~wizkid057/newstats/pushtxn.php
>
> 3) https://github.com/bitcoin/bitcoin/pull/3354 and
> https://github.com/bitcoin/bitcoin/pull/3883
>
> 4) https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-23 4:29 ` Jan Møller
@ 2014-04-23 6:35 ` Mark Friedenbach
0 siblings, 0 replies; 8+ messages in thread
From: Mark Friedenbach @ 2014-04-23 6:35 UTC (permalink / raw)
To: bitcoin-development
On 04/22/2014 09:29 PM, Jan Møller wrote:
>>Of course, this is an especially difficult case, as you must send the
>>double-spend after the original transaction - normally just sending a
>>non-standard tx to Eligius first would suffice. Note how this defeats
>>Andresen's double-spend-relay patch(3) as proposed since the
>>double-spend is a non-standard transaction.
>
> Why can't you send a non-standard tx to Eligius first in this scenario?
> Is it because LuckyBit is connected directly to Eligius, and does
> Eligius relay (not only mine) non-standard transactions?
>
Because you only want to double-spend if you loss the bet. If you tried
to double-spend every bet, there'd be no point :)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-23 4:03 ` Matt Whitlock
@ 2014-04-23 22:29 ` Tom Harding
2014-04-24 0:42 ` Simon Barber
0 siblings, 1 reply; 8+ messages in thread
From: Tom Harding @ 2014-04-23 22:29 UTC (permalink / raw)
Cc: bitcoin-development
On 4/22/2014 9:03 PM, Matt Whitlock wrote:
> On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
>> A network where transaction submitters consider their (final)
>> transactions to be unchangeable the moment they are transmitted, and
>> where the network's goal is to confirm only transactions all of whose
>> UTXO's have not yet been seen in a final transaction's input, has a
>> chance to be such a network.
> Respectfully, this is not the goal of miners. The goal of miners is to maximize profits. Always will be. If they can do that by enabling replace-by-fee (and they can), then they will. Altruism does not factor into business.
The rational miner works hard digging hashes out of the ether, and wants
the reward to be great. How much more valuable would his reward be if
he were paid in something that is spendable like cash on a 1-minute
network for coffee and other innumerable real-time transactions, versus
something that is only spendable on a 15-minute network?
There is a prisoner's dilemma, to be sure, but do the fees from helping
people successfully double-spend their coffee supplier really outweigh
the increased value to the entire network - including himself - of
ensuring that digital cash actually works like cash?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise
2014-04-23 22:29 ` Tom Harding
@ 2014-04-24 0:42 ` Simon Barber
0 siblings, 0 replies; 8+ messages in thread
From: Simon Barber @ 2014-04-24 0:42 UTC (permalink / raw)
To: bitcoin-development
Miners earn bitcoins, and clearly a network where reasonable certainty
can be achieved with 0-confirm transactions is more useful, thus will
result in those bitcoins being more valuable. One would expect rational
miners (or pool operators) to want to collaborate to reduce the
possibilities for double spend attacks as much as possible.
Simon
On 4/23/2014 3:29 PM, Tom Harding wrote:
> On 4/22/2014 9:03 PM, Matt Whitlock wrote:
>> On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
>>> A network where transaction submitters consider their (final)
>>> transactions to be unchangeable the moment they are transmitted, and
>>> where the network's goal is to confirm only transactions all of whose
>>> UTXO's have not yet been seen in a final transaction's input, has a
>>> chance to be such a network.
>> Respectfully, this is not the goal of miners. The goal of miners is to maximize profits. Always will be. If they can do that by enabling replace-by-fee (and they can), then they will. Altruism does not factor into business.
> The rational miner works hard digging hashes out of the ether, and wants
> the reward to be great. How much more valuable would his reward be if
> he were paid in something that is spendable like cash on a 1-minute
> network for coffee and other innumerable real-time transactions, versus
> something that is only spendable on a 15-minute network?
>
> There is a prisoner's dilemma, to be sure, but do the fees from helping
> people successfully double-spend their coffee supplier really outweigh
> the increased value to the entire network - including himself - of
> ensuring that digital cash actually works like cash?
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-04-24 1:01 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-22 21:31 [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise Peter Todd
2014-04-23 4:29 ` Jan Møller
2014-04-23 6:35 ` Mark Friedenbach
2014-04-23 4:45 ` Tom Harding
2014-04-23 4:03 ` Matt Whitlock
2014-04-23 22:29 ` Tom Harding
2014-04-24 0:42 ` Simon Barber
2014-04-23 4:22 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox