j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM+
<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=723.msg8023#msg8023">Quote from: Red on August 07, 2010, 12:19:16 AM</a></div><div class="quote">So which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins.<br/></div>Now I'm confused again. I thought your scheme didn't have blocks, just transactions. What do you mean, whoever solves "the block" first?<br/><br/><div class="quoteheader">Quote</div><div class="quote">By the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join.</div>But standard DHTs are typically used to store chunks of MP3s or movies, indexed by a torrent file that has the hash for every piece. So it is easy for me to tell whether or not I'm getting bad data from any particular DHT node. I don't have to trust them.<br/><br/><div class="quoteheader">Quote</div><div class="quote">Nodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible.<br/></div>Huh? Lets say the network has 10,000 nodes in it. I query the network to find the network node closest to a transaction that I want to double-spend.<br/><br/>So I generate a private key. It has about a 1 in 10,000 chance of being closer than the current closest node. So I keep generating private keys until I have 5 that are closer. It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5. My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000.<br/><br/>I create 5 nodes with those keys (telling the rest of the network "honest, folks, I chose those keys RANDOMLY...") and I've won.<br/><br/><div class="quoteheader">Quote</div><div class="quote">All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out.</div>I'm not trying to generate a transaction with a particular hash, I'm trying to generate node ids that are "closer" to that transaction's hash than any other node currently on the network. That's much easier.<br/></div> text/html
https://whatsonchain.com/tx/66bfb99ece8f4cef3d577d08ea2aea39cdf22d8abf614ce3da4c4d5a37bfd4fa