From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E5648B4 for ; Thu, 16 Jul 2015 15:34:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D73332 for ; Thu, 16 Jul 2015 15:34:08 +0000 (UTC) Received: by ykeo3 with SMTP id o3so66875062yke.0 for ; Thu, 16 Jul 2015 08:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jjri1fDUvXRjkFRo3R235GFmojgLwSdaJzpkEa6KOPg=; b=pY2tUAqyi7B2Ez7MMpdG4SGkdbSL4OW267eOOpqy4cAqms2iM85lqY2A0KIBpOQb0D w5B9g+ojVztSbnbv8FT4xU7Yb79x+JAB8sSEv/doIQOOQLlmvXCKSQDlYIIT/iT8HWwX AgefUl4b/wG6X2cKqZFP+RBRAKbk33ATEHxK9JKkGb5O7grU0DbBhHLfhOSqrl0sLUZH gZavdTrSEgdZHMjQBjanwczr5PIYpWOh1xKJx9P0jrXu/zGK8k/ia1bsHPFhkv5b30v4 JzPhjFMOT0+/4PgnByoZFKTSWjfvElXYZeNXdxZoSI4Svy+BLmXQbRE9NRLXhqs20KQ1 36rA== X-Received: by 10.13.255.132 with SMTP id p126mr10494904ywf.157.1437060847623; Thu, 16 Jul 2015 08:34:07 -0700 (PDT) MIME-Version: 1.0 Sender: gregory.schvey@gmail.com Received: by 10.37.119.7 with HTTP; Thu, 16 Jul 2015 08:33:48 -0700 (PDT) In-Reply-To: <57C28E34-7B1C-4501-BB9C-5727862023F3@gmail.com> References: <24662b038abc45da7f3990e12a649b8a@airmail.cc> <55A7BFF7.2050608@xylon.de> <57C28E34-7B1C-4501-BB9C-5727862023F3@gmail.com> From: Greg Schvey Date: Thu, 16 Jul 2015 08:33:48 -0700 X-Google-Sender-Auth: tqFDGoj9wwOH-QqBrPcGwYCqIxk Message-ID: To: Me Content-Type: multipart/alternative; boundary=94eb2c08886657e3e9051affcd87 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 15:34:09 -0000 --94eb2c08886657e3e9051affcd87 Content-Type: text/plain; charset=UTF-8 Simon - tx hashes or it didn't happen Kidding aside, would be great if you could share the confirmed and double-spent hashes so the rest of us can dive in and learn from this. On Thu, Jul 16, 2015 at 7:50 AM, Me via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > minrelaytxfee setting proposed in the 0.11.0 release notes > > my guess, he is talking about this > https://bitcoin.org/en/glossary/minimum-relay-fee - slam dunk technique > for doublespend > > > > Related: is there somewhere a chart that plots `estimatefee` over > time? Would be interesting to see how the fee market evolved over > these past weeks. > > > I find this useful > https://bitcoinfees.github.io/ > > > > > > On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello, > > What are these pre- and post-Hearn-relay drop rules you are speaking > about? Can anybody shed some light on this? (I am aware of the > minrelaytxfee setting proposed in the 0.11.0 release notes, I just > don't see what this has to do with Mike Hearn, BitcoinXT, and whether > there's a code change related to this that I missed). > > Related: is there somewhere a chart that plots `estimatefee` over > time? Would be interesting to see how the fee market evolved over > these past weeks. > > Regards > Arne > > On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote: > > With my black hat on I recently performed numerous profitable > double-spend attacks against zeroconf accepting fools. With my > white hat on, I'm warning everyone. The strategy is simple: > > tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. > anything that miners don't always accept. > > tx2: After merchant gives up valuable thing in return, normal tx > without triggering spam protections. (loltasticly a Mike Hearn > Bitcoin XT node was used to relay the double-spends) > > Example success story: tx1 paying Shapeshift.io > with 6uBTC output > is not dust under post-Hearn-relay-drop rules, but is dust under > pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not > paying Shapeshift.io . > F2Pool/Eligius/BTCChina/AntPool etc. are all > miners who have reverted Hearn's 10x relay fee drop as recommended > by v0.11.0 release notes and accept these double-spends. > Shapeshift.io lost ~3 BTC this week in multiple > txs. (they're no > longer accepting zeroconf) > > Example success story #2: tx1 with post-Hearn-relay drop fee, > followed by tx2 with higher fee. Such stupidly low fee txs just > don't get mined, so wait for a miner to mine tx2. Bought a silly > amount of reddit gold off Coinbase this way among other things. I'm > surprised that reddit didn't cancel the "fools-gold" after tx > reversal. (did Coinbase guarantee those txs?) Also found multiple > Bitcoin ATMs vulnerable to this attack. (but simulated attack with > tx2s still paying ATM because didn't want to go to trouble of good > phys opsec) > > Shoutouts to BitPay who did things right and notified merchant > properly when tx was reversed. > > In summary, every target depending on zeroconf vulnerable and lost > significant sums of money to totally trivial attacks with high > probability. No need for RBF to do this, just normal variations in > miner policy. Shapeshift claims to use Super Sophisticated Network > Sybil Attacking Monitoring from Blockcypher, but relay nodes != > miner policy. > > Consider yourself warned! My hat is whiter than most, and my skills > not particularly good. > > What to do? Users: Listen to the experts and stop relying on > zeroconf. Black hats: Profit! > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -- > Arne Brutschy > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c08886657e3e9051affcd87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simon - tx hashes or it didn't happen

Kidding aside, would be great if you could share the confirmed and doubl= e-spent hashes so the rest of us can dive in and learn from this.=C2=A0

On Thu, J= ul 16, 2015 at 7:50 AM, Me via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
minrelaytxfee setting proposed in the 0.11.0 release note= s
my guess, he is talking about this=C2=A0https://bitcoin.org/en/glossary/minimum-relay-fee=C2=A0- slam dunk te= chnique for doublespend



Related: is there somewhere = a chart that plots `estimatefee` over
time? Would be interesting to see = how the fee market evolved over
these past weeks.

=
I find this useful
https://bitcoinfees.github.io/





On Jul 16, 2015, at 7:30 AM, Arne Brutsch= y via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= /div>
Hello,

What are these pre- and post-Hearn-relay d= rop rules you are speaking
about? Can anybody shed some light on this? (= I am aware of the
minrelaytxfee setting proposed in the 0.11.0 release n= otes, I just
don't see what this has to do with Mike Hearn, BitcoinX= T, and whether
there's a code change related to this that I missed).=

Related: is there somewhere a chart that plots `estimatefee` overtime? Would be interesting to see how the fee market evolved over
thes= e past weeks.

Regards
Arne

On 15/07/15 05:29, simongreen--= - via bitcoin-dev wrote:
With my black hat on = I recently performed numerous profitable
double-spend attacks against z= eroconf accepting fools. With my
white hat on, I'm warning everyone.= The strategy is simple:

tx1: To merchant, but dust/low-fee/reused-a= ddress/large-size/etc.
anything that miners don't always accept.
tx2: After merchant gives up valuable thing in return, normal tx
wi= thout triggering spam protections. (loltasticly a Mike Hearn
Bitcoin XT = node was used to relay the double-spends)

Example success story: tx1= paying Shapeshift.io with 6uBTC output
is not dust under post-Hearn-relay-drop rules, but i= s dust under
pre-Hearn-relay-drop rules, followed by tx2 w/o the output= and not
paying Shap= eshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all
miners who = have reverted Hearn's 10x relay fee drop as recommended
by v0.11.0 r= elease notes and accept these double-spends.
Shapeshift.io lost ~3 BTC this week in multiple= txs. (they're no
longer accepting zeroconf)

Example success = story #2: tx1 with post-Hearn-relay drop fee,
followed by tx2 with highe= r fee. Such stupidly low fee txs just
don't get mined, so wait for a= miner to mine tx2. Bought a silly
amount of reddit gold off Coinbase th= is way among other things. I'm
surprised that reddit didn't canc= el the "fools-gold" after tx
reversal. (did Coinbase guarantee= those txs?) Also found multiple
Bitcoin ATMs vulnerable to this attack.= (but simulated attack with
tx2s still paying ATM because didn't wan= t to go to trouble of good
phys opsec)

Shoutouts to BitPay who di= d things right and notified merchant
properly when tx was reversed.
<= br>In summary, every target depending on zeroconf vulnerable and lost
s= ignificant sums of money to totally trivial attacks with high
probabili= ty. No need for RBF to do this, just normal variations in
miner policy. = Shapeshift claims to use Super Sophisticated Network
Sybil Attacking Mon= itoring from Blockcypher, but relay nodes !=3D
miner policy.

Cons= ider yourself warned! My hat is whiter than most, and my skills
not part= icularly good.

What to do? Users: Listen to the experts and stop rel= ying on
zeroconf. Black hats: Profit!

___________________________= ____________________ bitcoin-dev mailing
list bitcoin-dev@lists.linuxfou= ndation.org
https://lists.linuxfoundation.org/mai= lman/listinfo/bitcoin-dev

--
Arne Brutschy <= abrutschy@xylon.de<= /a>>
_______________________________________________
bitcoin-dev m= ailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


______________= _________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--94eb2c08886657e3e9051affcd87--