Re: [Bitcoin-development] Cartographer
On Sunday 28. December 2014 18.25.29 Mike Hearn wrote: Lately we have been bumping up against the limitations of DNS as a protocol for learning about the p2p network. Can you explain further where limitations and problems were hit? -- Thomas Zander -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 A big one is the privacy is way too good: every DNS request goes through multiple levels of caching and indirection, so there's no way to figure out who made the request to subject them additional targeting. A connection-oriented protocol gets rid of all those protections, giving us seed operators monetisation opportunities like selling usage statistics, per-client targeted results, etc. We recently got rid of all the call-home functionality that previously gave this type of insight; a connecyion-oriented seed protocol gives us this right back. There's also this pesky problem of ISP's censoring DNS results with dumb automated systems to block malware - easily fixed with Gregory Maxwell's suggestion of permuting the results with XOR - but that kind of end-user driven solution really misses out in the needs of other Bitcoin stakeholders like law enforcement and marketing companies. On 29 December 2014 09:47:29 CET, Thomas Zander tho...@thomaszander.se wrote: On Sunday 28. December 2014 18.25.29 Mike Hearn wrote: Lately we have been bumping up against the limitations of DNS as a protocol for learning about the p2p network. Can you explain further where limitations and problems were hit? -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUoS94MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQzHB/97jRf4iX0v/zDW0EkT 8My2ExCdOqwYToxqTF0DQhwBjVzh2OHH9tVFKPXfgg87xtIxYZjx70yQpw7O4anw 7E5eJpFRjTayafclzRupgMn2AVT9AN45zjxkEutAEO27mxJ2p0OQPkNKzVR38sGW 95siatZMej68jflr0o0JrRePaDn3jufZEYQ5IvS80HxEwjzLCx/qCnPKkiKEQjr0 EHbovZo/5DNmJys4an+hoZkPeDRGw30w86kxXaY2SQP8aefswfg6rTOcrfkuQQfQ AEYRZCZb6XxkL/gLU1dSgidswg+wgt/JW7QB+n6Z0fMGnX92EAxpwrvQUxDm55sC HhOT =dRuK -END PGP SIGNATURE- -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
Can you explain further where limitations and problems were hit? Well, look at the feature list :) The biggest need from my POV is querying support. It's awkward to try and retrofit flexible key=value pair queries onto DNS, it just wasn't designed for that. With HTTP it's easy. This will become more important in future as the protocol evolves. For example, some nodes will soon stop serving the block chain because they start pruning. Today this is managed with a hack: pruning nodes just stop providing *all* services to the p2p network. This takes them out of the DNS seeds entirely. But they can actually still provide download of the parts of the chain they still have, and they can provide transaction filtering and relay support, along with misc other things. With the current DNS protocol you get an all or nothing choice - so probably seeds that only support it will elect to only show nodes that have the entire block chain, because that's what Bitcoin Core would find most useful. SPV wallets have slightly different needs. In theory you could come up with a pile of hacks to specify what the client needs in the DNS query, but then you have a v2 protocol anyway and might as well go the whole way. Additionally, with DNS it's awkward to provide extra data in the responses beyond IP address and it's VERY awkward to sign the responses. Signing the responses has a couple of benefits. The biggest is, in future it'd be nice to have an authenticated and encrypted network, to raise the bar for sybil and MITM attacks. DNS seeding can't be upgraded to support that with any reasonable level of effort. And DNS is awkward to configure/set up. Actually DNS is just awkward, period. The second benefit of signing is it provides audibility. If you see a seed give bad answers, you can now prove it to other people. There is also the previously discussed issue that DNS seeds sometimes get blocked by aggressive networks because they start serving IPs that are infected with malware i.e. they look like fast-flux sites. Using a simple HTTP based protocol fixes all of these problems in one go. Now, re: privacy. Firstly, Peter, get help. I'm serious. You are starting to sound like an auto-generated parody of yourself. When you can't debate something as boring as HTTP vs DNS without trying to raise an angry mob using bizarre conspiracy theories, that's not normal. I don't think the DNS has caches issue is worth worrying about for a lot of reasons: 1. Full nodes try as hard as they can to open ports and advertise their IP addresses to everyone. Even if you change the defaults to disable that, you're about to connect to a bunch of random computers with no reputation anyway. 2. Lists of stale IP addresses are hardly useful to regular people and network operators can identify Bitcoin users by looking for traffic on port 8333, so it's unclear what threat model is being addressed here. 3. The biggest users of the seeds are all SPV wallets. Every single one of these already phones home to check for online updates. 4. DNS proxying only hides part of the IP address. If you're serious about this you want to be doing lookups via Tor. Whilst it's possible to use the DNS seeds via Tor in a reasonable way with exit diversity (and bitcoinj does), doing it requires low level Tor protocol programming https://github.com/bitcoinj/bitcoinj/blob/42f9d7c193fcd56fda7691b0ea934bae9d23f2d6/core/src/main/java/org/bitcoinj/net/discovery/TorDiscovery.java#L260 that is out of reach for most implementors. An HTTP lookup is trivial with any HTTP stack that supports SOCKS. 5. ISPs also deploy transparent HTTP caches. The Cartographer protocol uses HTTP with inline signing so responses can be cached, once the right headers are being set. tl;dr it's unclear that DNS caching actually solves any real privacy problem but regardless, you can get the same distributed caching with HTTP as with DNS. So in the end it makes little difference. I believe that Cartographer is a better protocol all round and there are no costs beyond the one-time upgrades, but even if for some reason you disagree with the five privacy points above, I think the benefits still massively outweigh the costs. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
On Monday 29. December 2014 11.30.42 Mike Hearn wrote: With the current DNS protocol you get an all or nothing choice Its a seed. Not the protocol itself. Firstly, Peter, get help. I'm serious. I think most would agree with me that, Mike, this answer is not just a little over the line, its unacceptable behavior in any collaborative group. Please be respectful and avoid ad-hominem attacks. -- Thomas Zander -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29 December 2014 12:49:45 CET, Thomas Zander tho...@thomaszander.se wrote: On Monday 29. December 2014 11.30.42 Mike Hearn wrote: With the current DNS protocol you get an all or nothing choice Its a seed. Not the protocol itself. Firstly, Peter, get help. I'm serious. I think most would agree with me that, Mike, this answer is not just a little over the line, its unacceptable behavior in any collaborative group. Please be respectful and avoid ad-hominem attacks. Yes I agree, Mike shouldn't be making ad-hominim attacks by calling people a parody You'll note my response however carefully avoiding talking about the person who originated the idea, and merely stuck to criticising - via parody - the idea itself. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUoUIUMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfnpB/9JMcBtq7nCudCvXWgZ TyKiSrK811L1PxtPih6UtzskFzNIKIVOgJrZcc0Cs7AoFoXiIPVEqzsqOOjZbhst Op2w2scUoQhvhweNLAUdAH5dY+GFJoOn5fol4BD95SuFuao/t1J8G4Ma4b+JGXR5 vlXtDD/dBJNWJeSVKN/Mgcp7eis3lXp1/rzc9/Ka45oXvUHFSxvQq2v/KgFeHKJ7 onx551+41MS7R1bedg+dPOtCFBFycW51Obt7vS8GudRqwKyuKoKIQzY910gHYdXL gTdQ16wXvp06fYlR4nJJPosE7ADP1udKJZNskVObJsX5z9sukI3r7noHNDDg3ZjH bS9/ =ouap -END PGP SIGNATURE- -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
Mike, In all seriousness, are you on the payroll of the NSA or similar to repeatedly attempt to introduce privacy leaks[1] and weaknesses[2] into the ecosystem not to mention logical fallacies like ad hominem attacks; disruption[3] and FUD[4]? Why do you answer objections by hand waving and misdirection as opposed to sound technical reasoning? Remember how hand waving ended for you the last time with your p2p getutxo pull-request[5] and the public flogging the ensued because you refused to accept your implementation was not only flawed but critically vulnerable to attack[6]. Given your intelligence, education and experience, it would seem logical that your behaviour is not random or irrational, but in fact calculated and planned. references: [1] http://www.reddit.com/r/Bitcoin/comments/2byqz0/mike_hearn_proposes_to_build_vulnerable/ [2] https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/ [3] http://www.reddit.com/r/Bitcoin/comments/28zts3/mike_hearn_interview_quotes_progress_on_the/ [4] https://www.youtube.com/watch?v=iMIzMVABFxQ [5] https://github.com/bitcoin/bitcoin/pull/4351 [6] http://www.reddit.com/r/Bitcoin/comments/2eq8gi/getutxos_a_convenient_way_to_crash_bitcoind/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
As an outside observer, I have to say I also found Peter's sardonic message tone inappropriate for furthering the discussion. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP: Voluntary deposit bonds
I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a pseudo-input). This is a hard-fork, and we could include it the next time a hardfork is made. The modifications to the code are minimal (no more than 12 lines modified where IsCoinBase() is called), and they generally involve removing code, not adding. Why ? Because sometime in the future (maybe 5-10 years) we may have to deal with problems of securing the blockchain, as the subsidy is lowered. We don't want the number of confirmation blocks to be increased in compensation because Bitcoin won't be able to compete with other payment networks. Then by having this hardfork now, we will be able to soft-fork later to any rule we may came come up with involving deposit bonds, proof-of-stake, and the penalization of double-mining (mining two blocks at the same height) to prevent short-range attacks. Can it hurt? No. I doesn't not change the incentives or the security in any way, as adding additional inputs to the coinbase transaction would be voluntary until the time for a soft-fork comes. We shouldn't hard-fork for this change only, but maybe we could do this change when the next hard-fork is scheduled (when we increase the block size?). Regards, S. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
Could you explain a bit further Sergio? I'm not sure I fully understand the proposal. How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote: I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a pseudo-input). This is something I've wanted since 2011, but hasn't been a priority. Because sometime in the future (maybe 5-10 years) we may have to deal with problems of securing the blockchain, as the subsidy is lowered. We don't want the number of confirmation blocks to be increased in compensation because Bitcoin won't be able to compete with other payment networks. Then by having this hardfork now, we will be able to soft-fork later to any rule we may came come up with involving deposit bonds, proof-of-stake, and the penalization of double-mining (mining two blocks at the same height) to prevent short-range attacks. I'm not sure this increases the priority of it. If someone feels it's worth the time, I'd suggest coding up a branch that hardforks it in at some far-off block height. Even if it doesn't get merged right away, at least the code will be available for testing and ready to go when/if that time comes. Luke -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/29/2014 09:10 PM, Mike Hearn wrote: How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? If a miner includes pay-to-fee transactions in a block, those fees could be claimed by another miner in the case the first miner's block is orphaned. Inputs to a generation transaction can not be similarly poached. That difference makes some services possible that would can not be safely achieved with pay-to-fee transactions. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUocjPAAoJEMP3uyY4RQ21zrMH/1f3vjac9XqOZbDItjiD6XXU EkpRUROjyQAs6/tO6dwWAIcXgulYREAJsU/udQNkTYteIDFlDzwkYL+NLXpYtwHs BiZJEEwmAEHFgOD3QmmqhTx867zIbEYIB/dpHlMOppE6fhTKFr9z6JdqAKlNcHHW tkW5sq8q9uq7StiUs3/mmZ0XXeEb84N+bPiJ9S7kuTm9QWnrF1oMLhAk4M6yX8hn 7MUowmfc9RZ4uIFkqxk6gkWJSRx7dlnCRP2TRhyABpZwAcZANuPhqBOZ6eJ6T9Fs DOJ14c5JYachXW5z8GqR+abeq0JPE76kEQt145B4degJ4DTQLLhlfdvjbuJvzy4= =Kfe2 -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote: How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? Pay-to-fee transactions can be stolen by another block at the same or greater height. Additional inputs to the generation transaction are tied to that block alone. Luke -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner sergioler...@certimix.com wrote: I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a pseudo-input). This is a hard-fork, and we could include it the next time a hardfork is made. The modifications to the code are minimal (no more than 12 lines modified where IsCoinBase() is called), and they generally involve removing code, not adding. If the motivation is purely enabling different rules in a soft-fork than I think nothing needs to be done. Instead of providing inputs to a coinbase: you provide an unusual anyone can spend transaction in the block which pays to fees; and simultaneously add a soft-forking rule that makes that anyone can spend rule no longer anyone can spend. To make that more concrete. E.g. You make your anyone can spend output PUSHhash of coinbase output script_pubkeys OP_NOP3. Now this anyone can pay transaction is really just a coinbase input. The construction is reasonably efficient, and also more flexible-- in that it could control the data under the hash in more flexible ways than available in the existing sighash flags. As an aside, I'm not sure that I agree with the claim that making coinbases have inputs is a simple modification... as we use one of the inputs already as the special coinbase field and at least that must be special cased. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
