On Fri, Jun 28, 2013 at 10:09:16AM +0000, John Dillon wrote: > 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.
Agreed. Speaking of, I may have missed it but as far as I can tell Bitmessage doesn't encrypt node-to-node communications, a serious oversight. Any attacker that can sniff a large fraction of the network, like the NSA, can easily use this to track down the originating node of any message, just like they can do with Bitcoin. > 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. Ah! I had a feeling that might be you. Were you the person who was creating the 1BTC fee transactions as well? > 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 just got an email from someone saying they had a few Avalons with that patch installed actually; that was probably them. > 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. :) Keep in mind it's not just the mempool that needs changing - the network protocol semantics need to change too. For the "scorched-earth" strategy to work you need nodes tell their peers about the total fees a transaction has attached in addition tot he tx hash. Essentially you are advertising to your peers what would right now be an orphan, and your peers need to recursively get dependencies; I'm sure there's a bunch of edge cases there that would be need to thought out carefully. It's useful for a lot of things though, for instance when a zero-fee, zero-priority tx is given to a merchant who now wants to tell miners to mine it anyway due to a child tx. What I'd recommend actually for the nearer term is just adding recursive fee evaluation with a depth*breadth anti-DoS limit, adding the rpc and GUI adjfee and canceltx commands, adding better wallet support for conflicts, (someone is already workng on this) and adding a service bit with preferential peering. By preferential peering I mean you set aside a portion of your outgoing peer slots for peers with certain bits set and only fill those slots with those peers. In addition you can have DNS seeds return peers with specified service bits set: x0000000000000003.v1.seed.petertodd.org could be nodes with the first and second bits set. (we might want to define the upper 8 service bits as a service bit version field so we can redefine the other 56 in the far off future if required) -- 'peter'[:-1]@petertodd.org 00000000000000b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5
signature.asc
Description: Digital 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
