Melvin Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-15 📝 Original message:On 15 May 2013 13:38, ...
📅 Original date posted:2013-05-15
📝 Original message:On 15 May 2013 13:38, Peter Todd <pete at petertodd.org> wrote:
> Now that I have the replace-by-fee reward, I might as well spread the
> wealth a bit.
>
>
> So for all this discussion about replace-by-fee and the supposed
> security of zero-conf transactions, no-one seems to think much about how
> in practice very few vendors have a setup to detect if conflicting
> transactions were broadcast on the network simultaneously - after all if
> that is the case which transaction gets mined is up to chance, so much
> of the time you'll get away with a double spend. We don't yet have a
> mechanism to propagate double-spend warnings, and funny enough, in the
> case of a single txin transaction the double-spend warning is also
> enough information to allow miners to implement replace-by-fee.
>
>
> So I'm offering 2BTC for anyone who comes up with a nice and easy to use
> command line tool that lets you automagically create one version of the
> transaction sending the coins to the desired recipient, and another
> version sending all the coins back to you, both with the same
> transaction inputs. In addition to creating the two versions, you need
> to find a way to broadcast them both simultaneously to different nodes
> on the network. One clever approach might be to use blockchain.info's
> raw transaction POST API, and your local Bitcoin node.
>
> If you happen to be at the conference, a cool demo would be to
> demonstrate the attack against my Android wallet. I'll buy Bitcoins off
> of you at Mt. Gox rates + %10, and you can see if you can rip me off.
> Yes, you can keep the loot. :) This should be videotaped so we can put
> an educational video on youtube after.
>
Isnt it potentially inviting trouble by encouraging people to insert double
spends into the block chain?
Sure, zero conf isnt 100% safe, we all know that.
But neither is the postal service. Doesnt mean we should be going around
promoting the creation of tools to go into people's maiilboxes and open
their letters!
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130515/c2398578/attachment.html>;
📝 Original message:On 15 May 2013 13:38, Peter Todd <pete at petertodd.org> wrote:
> Now that I have the replace-by-fee reward, I might as well spread the
> wealth a bit.
>
>
> So for all this discussion about replace-by-fee and the supposed
> security of zero-conf transactions, no-one seems to think much about how
> in practice very few vendors have a setup to detect if conflicting
> transactions were broadcast on the network simultaneously - after all if
> that is the case which transaction gets mined is up to chance, so much
> of the time you'll get away with a double spend. We don't yet have a
> mechanism to propagate double-spend warnings, and funny enough, in the
> case of a single txin transaction the double-spend warning is also
> enough information to allow miners to implement replace-by-fee.
>
>
> So I'm offering 2BTC for anyone who comes up with a nice and easy to use
> command line tool that lets you automagically create one version of the
> transaction sending the coins to the desired recipient, and another
> version sending all the coins back to you, both with the same
> transaction inputs. In addition to creating the two versions, you need
> to find a way to broadcast them both simultaneously to different nodes
> on the network. One clever approach might be to use blockchain.info's
> raw transaction POST API, and your local Bitcoin node.
>
> If you happen to be at the conference, a cool demo would be to
> demonstrate the attack against my Android wallet. I'll buy Bitcoins off
> of you at Mt. Gox rates + %10, and you can see if you can rip me off.
> Yes, you can keep the loot. :) This should be videotaped so we can put
> an educational video on youtube after.
>
Isnt it potentially inviting trouble by encouraging people to insert double
spends into the block chain?
Sure, zero conf isnt 100% safe, we all know that.
But neither is the postal service. Doesnt mean we should be going around
promoting the creation of tools to go into people's maiilboxes and open
their letters!
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130515/c2398578/attachment.html>;