Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E845FAC1 for ; Thu, 16 Jul 2015 14:50:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6EAE3137 for ; Thu, 16 Jul 2015 14:50:15 +0000 (UTC) Received: by pdjr16 with SMTP id r16so45704410pdj.3 for ; Thu, 16 Jul 2015 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9pP03FIh6vSqri7g1Z+tdJG8wAYg2INYKKnXedJKjts=; b=BU4zhM0Kq1rA4zqAvW/0m++7FGoxQvkvydlsOyVztdiKpHyMf4BP/Zp4UmleK2R3Vr b0H5r6FCmkMVDi+aF8USzbOpa6+5E4habLmyVptluImSF2au6wieHNbwkjjtVCm1+Vi5 OuCFcdLnv3N2DlqEqkWqVz92Dk8Sct9vbPxqcTv9P/W1E5JY8P2XCZIuwV7kd6zG3Rn+ impuC20Yufph010+jDQZZYorKKs6Ts/R+7qrA288aNL7MAfYnPbhXb58H0IjXeyqH08D xwnpkItDaH0NVeZhZ0ufu7M6Ctjpj3Ztfpv5aoGiBVg5KEmhoVFRTHKBvxuzAigoBqof WZiw== X-Received: by 10.68.238.39 with SMTP id vh7mr19807098pbc.12.1437058215159; Thu, 16 Jul 2015 07:50:15 -0700 (PDT) Received: from [10.237.243.222] ([50.141.34.174]) by smtp.gmail.com with ESMTPSA id ml6sm8220019pdb.69.2015.07.16.07.50.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jul 2015 07:50:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B38068F-99E3-4FD8-87FE-8E546A2C52B7" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) From: Me In-Reply-To: <55A7BFF7.2050608@xylon.de> Date: Thu, 16 Jul 2015 07:50:16 -0700 Message-Id: <57C28E34-7B1C-4501-BB9C-5727862023F3@gmail.com> References: <24662b038abc45da7f3990e12a649b8a@airmail.cc> <55A7BFF7.2050608@xylon.de> To: Arne Brutschy X-Mailer: Apple Mail (2.3067) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 14:50:17 -0000 --Apple-Mail=_3B38068F-99E3-4FD8-87FE-8E546A2C52B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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 = wrote: >=20 > Hello, >=20 > 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). >=20 > 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. >=20 > Regards > Arne >=20 > On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote: >> With my black hat on I recently performed numerous profitable=20 >> double-spend attacks against zeroconf accepting fools. With my >> white hat on, I'm warning everyone. The strategy is simple: >>=20 >> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.=20 >> anything that miners don't always accept. >>=20 >> 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) >>=20 >> Example success story: tx1 paying Shapeshift.io with 6uBTC output >> is not dust under post-Hearn-relay-drop rules, but is dust under=20 >> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not=20 >> paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all=20 >> 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) >>=20 >> 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) >>=20 >> Shoutouts to BitPay who did things right and notified merchant >> properly when tx was reversed. >>=20 >> In summary, every target depending on zeroconf vulnerable and lost=20 >> significant sums of money to totally trivial attacks with high=20 >> 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 !=3D >> miner policy. >>=20 >> Consider yourself warned! My hat is whiter than most, and my skills >> not particularly good. >>=20 >> What to do? Users: Listen to the experts and stop relying on >> zeroconf. Black hats: Profit! >>=20 >> _______________________________________________ bitcoin-dev mailing >> list bitcoin-dev@lists.linuxfoundation.org=20 >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 > --=20 > Arne Brutschy > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_3B38068F-99E3-4FD8-87FE-8E546A2C52B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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 !=3D
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<= /a>

--
Arne = Brutschy <abrutschy@xylon.de>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_3B38068F-99E3-4FD8-87FE-8E546A2C52B7--