From: Mike Hearn <mike@plan99•net>
To: John Dillon <john.dillon892@googlemail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Date: Fri, 28 Jun 2013 12:20:03 +0200 [thread overview]
Message-ID: <CANEZrP07LOEDK7wV3afJJN9cEw8xQHoqA=Jk_GrQs2jrpCBC7w@mail.gmail.com> (raw)
In-Reply-To: <CAPaL=UV6vhVK6W0FiVoqM+=9C9TAUXVKwbuynq3NZYFzFR8TTQ@mail.gmail.com>
I suspect what you saw is mining nodes restarting and clearing their
mempools out rather than an explicit policy of replace by fee.
On Fri, Jun 28, 2013 at 12:09 PM, John Dillon
<john.dillon892@googlemail•com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@plan99•net> wrote:
>>> I see some of the the other things that were concerning for me at the
>>> time are still uncorrected though, e.g. no proxy support (so users
>>> can't follow our recommended best practices of using it with Tor),
>>
>> Yeah. That's not the primary privacy issue with bitcoinj though. I'm
>> much, much more concerned about leaks via the block chain than the
>> network layer. Especially as Tor is basically a giant man in the
>> middle, without any kind of authentication you can easily end up
>> connected to a sybil network without any idea. I'd be surprised if Tor
>> usage was very high amongst Bitcoin users.
>
> Tor does not act as a particularly effective man in the middle for nodes
> that support connections to hidden services because while your
> connections to standard Bitcoin nodes go through your exit node, the
> routing path for each hidden service peer is independent. Having said
> that we should offer modes that send your self-generated transactions
> out via Tor, while still maintaining non-Tor connections.
>
> Anyway Sybil attacks aren't all that interesting if you are the one
> sending the funds, and receivers are reasonably well protected simply
> because generating false confirmations is extremely expensive and very
> difficult to do quickly. After all, you always make the assumption that
> nearly all hashing power in existence is honest when you talk about
> replace-by-fee among other things, and that assumption naturally leads
> to the conclusion that generating false confirmations with a sybil
> attack would take more than long enough that the user would be
> suspicious that something was wrong long before being defrauded.
>
> I'd be surprised if anyone has ever bothered with a false confirmation
> sybil attack. I wouldn't be the slightest bit surprised if the NSA is
> recording all the Bitcoin traffic they can for future analysis to find
> true transaction origins. Which reminds me, again, we need node-to-node
> connections to be encrypted to at least protect against network-wide
> passive sniffiing.
>
> Regarding usage I would be interested to hear from those running Bitcoin
> nodes advertising themselves as hidden services.
>
>> It's not a library limitation anyway, it's a case of how best to
>> present information to a user who is not familiar with how Bitcoin
>> works. "Safe" and "Not safe" is still a rather misleading distinction
>> given the general absence of double spends against mempool
>> transactions, but it's still a lot more meaningful than "2 confirms"
>
> For what it is worth I ran a double-spend generator a month or so ago
> against the replace-by-fee node that Peter setup and I found that a
> small number of the double-spends did in fact appear to be mined under
> replace-by-fee rules.
>
> Specifically the generator would create a transaction from confirmed
> inputs, wait 60-180 seconds (randomized) to allow for full propagation,
> and then create a double-spend if the transaction hadn't already been
> mined. The transactions were randomized to look like normal traffic,
> including occasional bets to Satoshidice and similar for fun. (for the
> record the script had no way of knowing if a bet won and would happily
> attempt to double-spend wins) Fees for the replacement were power-law
> distributed IIRC, with some occasionally set to be quite hefty.
>
> Though possibly just an artifact of unusually slow transaction
> propagation it appeared that about 0.25% of hashing power was following
> replace-by-fee rules. (not including transactions involving gambling, I
> know Eligius and perhaps others block such transactions from their
> mempools making double-spends easy to accomplish by including
> Satoshidice outputs)
>
> I'm actually surprised by that figure myself given Peter Todd and I
> haven't made a serious attempt yet to get miners to use replace-by-fee
> rules. An interesting experiment would be to advertise that money is
> being given away by such a tx generator in the mining forum, although I
> would prefer to see solid mempool support for the "scorched-earth"
> double-spend countermeasure first; Peter sounds like he has some great
> ideas there, although as usual I am seeing very little in the way of
> code. :)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY
> l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq
> R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn
> WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z
> XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq
> j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw=
> =QtjI
> -----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-06-28 10:20 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 17:10 Jim
2013-06-27 17:30 ` Jeff Garzik
2013-06-27 18:04 ` Luke-Jr
2013-06-27 18:41 ` Gregory Maxwell
2013-06-27 19:18 ` Jim
2013-06-27 19:40 ` Jim
2013-06-27 19:50 ` Jim
2013-06-27 21:12 ` Alex Kravets
2013-06-27 21:56 ` Jeff Garzik
2013-06-27 22:53 ` Alex Kravets
2013-06-27 22:03 ` Gary Rowe
2013-06-28 10:59 ` John Dillon
2013-06-28 9:10 ` Mike Hearn
2013-06-28 14:24 ` Gavin Andresen
[not found] ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com>
2013-06-28 20:37 ` Bill Hees
2013-06-28 20:42 ` Jim
2013-06-30 11:42 ` Mike Hearn
2013-06-30 15:19 ` Jim
2013-06-30 16:39 ` Gary Rowe
2013-07-09 0:22 ` Robert Backhaus
2013-07-09 1:20 ` Caleb James DeLisle
2013-07-09 10:36 ` Mike Hearn
2013-07-09 10:56 ` Jim
2013-07-09 11:04 ` Mike Hearn
2013-07-09 11:13 ` Will
2013-07-09 11:15 ` Jim
2013-07-09 11:18 ` Mike Hearn
2013-07-09 14:00 ` Daniel F
2013-07-09 14:06 ` Jeff Garzik
2013-07-09 14:28 ` Mike Hearn
2013-07-09 14:46 ` Jim
2013-07-09 14:57 ` Daniel F
2013-07-09 15:27 ` Mike Hearn
2013-07-09 15:32 ` Nick Simpson
2013-07-09 15:51 ` Johnathan Corgan
2013-07-09 16:44 ` Mike Hearn
2013-07-09 15:59 ` Jeff Garzik
2013-07-09 16:03 ` Nick Simpson
2013-07-09 22:15 ` Andreas Petersson
2013-06-27 17:56 ` Gregory Maxwell
2013-06-27 18:05 ` Alex Kravets
2013-06-27 23:45 ` Caleb James DeLisle
2013-06-28 9:05 ` Mike Hearn
2013-06-28 10:09 ` John Dillon
2013-06-28 10:20 ` Mike Hearn [this message]
2013-06-28 10:32 ` John Dillon
2013-06-30 10:12 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP07LOEDK7wV3afJJN9cEw8xQHoqA=Jk_GrQs2jrpCBC7w@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=john.dillon892@googlemail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox