Me [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-15 to 2015-07-16
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:42:25

- reply

📅 Original date posted:2015-07-16
📝 Original message:> 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 <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/ <https://bitcoinfees.github.io/>
> On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Arne Brutschy <abrutschy at xylon.de>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150716/591bbb75/attachment.html>

2023-06-07 15:42:21

- reply

📅 Original date posted:2015-07-15
📝 Original message:> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.
I guess we sort of disagree here, perhaps my word “strength” was not the right word. Yes, running 6000 vs 7000 nodes makes no difference for the network strength, but (a) running 50 nodes vs 5000 does make a difference. I would love to see how the number of nodes drop if companies like blockcypher turn off their servers. Obviously it would not go 50. (b) running different clients (if blockcypher runs non-reference-bitcoinD client) makes the network less open wide-spread bugs
I feel we are really derailing the original topic btw :-)
> On Jul 15, 2015, at 9:11 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large number of standard nodes and actually make the network stronger? Personally I never bring claims like this if I just assume. A lot of people in the community really trust you, do you realize you potentially hurt them for no reason?
>
> Running normal full nodes only provides extra service to nodes synchronizing and lightweight clients. It does not "make the network stronger" in the sense that it does not reduce the trust the participants need to have in each other.
>
> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150715/8fca9ae0/attachment.html>

2023-06-07 15:42:21

- reply

📅 Original date posted:2015-07-15
📝 Original message:Have you talk to them? If not, how can you be sure they don’t run large number of standard nodes and actually make the network stronger? Personally I never bring claims like this if I just assume. A lot of people in the community really trust you, do you realize you potentially hurt them for no reason?
btw I do not work for them nor have any money invested in them in case anybody asks
> On Jul 15, 2015, at 8:59 AM, Peter Todd <pete at petertodd.org> wrote:
>
> On Wed, Jul 15, 2015 at 08:49:13AM -0700, Me wrote:
>>> Blockcypher's "confidence factor" model(1)
>>> under the hood - yet another one of those sybil attacking network
>>> monitoring things
>>
>>
>> Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please.
>
> For Blockcypher to succesfully do what they claim to do they need to
> connect to a large % of nodes on the network; that right there is a
> sybil attack. It's an approach that uses up connection slots for the
> entire network and isn't scalable; if more than a few services were
> doing that the Bitcoin network would become significantly less reliable,
> at some point collapsing entirely.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000093f699ccdb323aa638af1131249ec2e1bacbf367163807a

2023-06-07 15:42:20

- reply

📅 Original date posted:2015-07-15
📝 Original message:Thank you Simon for sharing your tests, if possible can you share TX hashes please. I would recommend to send them money post-mortem. What you did is really valuable information, however it can be classified as fraud. I really don’t want open this topic here, just suggesting to keep your record clean :-)
> the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)
Can you please share the TX Hash
> Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things
Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please.
> On Jul 15, 2015, at 8:18 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
>>
>> You perform a valuable service with your demonstration, but you
>> neglected to include the txid's to show that you actually did it.
>
>> Your advice is must-follow for anyone relying on an unconfirmed tx: it
>> must pay a good fee and be highly relayable/minable.
>
> Actually, I was looking at what I believe was (part of?) this attack
> yesterday in the logs on my full-RBF nodes and the txs involved *did*
> have good fees and were highly relayable/minable - the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)
>
> Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things - to estimate tx confirmation probability by looking
> at the % of nodes a tx has propagated too. But miners frequently use
> customized Bitcoin Core codebases that don't follow normal policies, so
> those measurements don't actually tell you what you need to know.
>
> hapeshift confirmed(2) the attack - confirming that they disabled
> unconfirmed tx acceptance - said they're going to "improve" their
> system... It'll be interesting to see what that actually entails.
>
> 1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
> 2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev