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.dillon...@googlemail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <m...@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----- ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
