j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMV <div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=723.msg8035#msg8035">Quote from: gavinandresen on August 07, 2010, 01:20:01 AM</a></div><div class="quote">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/></div><br/>My scheme doesn't have blocks. I was referring here to how the existing system operates.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=723.msg8035#msg8035">Quote from: gavinandresen on August 07, 2010, 01:20:01 AM</a></div><div class="quote">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/>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>Yes, It's much easier!<br/><br/>You've made a quite plausible argument for this particular case. Kudos! <br/><br/>I'm not going to do the math either because that is really not the point. I'm not proposing "The solution". I'm suggesting that the amount of compute resources doesn't need to scale so badly to satisfy bitcoin's requirements. I'm only trying to show that there are other reasonable designs that can meet bitcoin's requirements with significantly lower CPU usage, and in the case of this thread less latency.<br/><br/>I think with the brain-trust that is this forum, any limitations in a distributed solution are easily discovered and rectified. Just as is being done with the current implementation. Perhaps I chose a poor way to create a node ID. Freenet proposes an entirely different way of shared generation of node IDs. It doesn't suffer from the issues you point out. Perhaps it has other issues in this situation. But I'm confident there exist a distributed implementation that would work.<br/><br/>Is the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction? <br/><br/>(100,000 was Satoshi's number of expected core nodes for a system that supported millions of users)<br/><br/> </div> text/html
https://whatsonchain.com/tx/bb4ab33f15e30c722c24f42c5e9f59a00224d4285ddd82222c2a253cd6fa56ad