Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
I think it's worth noting that quite a large portion of Linux users probably get the mainline Bitcoin client from the packages. I think Bitcoin package maintainers are doing mostly a pretty good job :) On 6 May 2013 18:13, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 3:51 PM, Adam Back wrote: > > Maybe I could hack a pool to co-opt it into my netsplit and do the work > for > > me, or segment enough of the network to have some miners in it, and they > do > > the work. > > Or you can just let it mine honestly and take the Bitcoins. This is > fast (doesn't require weeks of them somehow not noticing that they're > isolated), and yields the values I listed as 'costs' if you would have > otherwise been able to use it to mine the difficulty down to 1. Cost > is just as much foregone income from the alternative attack you could > have done instead. > > > nor even topological, nor even > > particularly long-lived. > > At least for attacks that drive the difficulty down it does. > > If you want to talk about abusing a pool or creating a partition in > order to create short reorgs— I agree, those don't have to be long > lived and you can find many messages where I've written on that > subject. > > It's inconsiderate to propose one attack and when I respond to it > changing the attack out from under me. :( I would have responded > entirely differently if you'd proposed people segmenting the network > and creating short reorgs instead of mining the difficulty down. > > > Do you know if there is any downwards limit on difficulty? I know it > takes > > going slow for a long and noticeable time, but I am just curious on the > > theoretical limit. > > Every 2016 blocks can at most lower the difficulty by a factor of 4, > thats where the log4 (number of 2016 groups needed) and 4^n (factor in > cost reduction for each group) come from in the formulas I gave > previously. > > > I dont see the signatures. > > > http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download > > The signatures can't be inside the tarball because they sign the tarball. > > Seems like the website redesign managed to hide the signatures pretty > good. They're in the release announcements in any case, but that > should be fixed. Even when they were prominently placed, practically > no one checked them. As a result they are mostly security theater in > practice :(, — so— unfortunately, is SSL: there are many CA's who will > give anyone a cert with your name on it who can give them a couple > hundred bucks and MITM HTTP (not HTTPS!) between the CA's > authentication server and your webserver. Bitcoin.org is hosted by > github, even if it had SSL and even if the CA infrastructure weren't a > joke, the number of ways to compromise that hosting enviroment would > IMO make SSL mostly a false sense of security. > > The gpg signatures and gitian downloader signatures provide good > security if actually used, solving the "getting people to use them" > problem is an open question. > > And I agree, this stuff is a bigger issue than many other things like > mining the difficulty down. > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 04:43:07PM -0400, Peter Todd wrote: > Now determining the value of D has a nice compact proof: B1, BP and M > and B2. Taking the minimum of the difficulties of B1 and B2 (in case > they cross a retarget boundry; don't want to create strange incentives) > determine the expected return in Bitcoins from the block reward had the > hasher solved valid blocks instead and you can determine exactly how > much the proof-of-work was worth, kinda... One last thought... suppose you want to make these proof-of-works transferable on the blockchain, as is easily possible with announce/commit fidelity bond sacrifices. The problem is of course re-use - you don't want it to be possible to use the same proof-of-work for a different asset. So for D use the txid:vout pair of a txout that you can spend, then spend it to some output to create the start of the smartcoin/contract asset chain. The txout can only be spent once, so the PoW is inherently non-reusable. The final proof is a more compact than a fidelity bond proof, just the PoW block and a single transaction and existence proof rather than two or three. (announce, commit, and commit txin if sacrifice is via fees) Unfortunately PoW schemes do mean you are actually taking away from the overall security of the network, and if there was a lot of demand for these things it will lead to the undesirable effect of making it easy to rent hashing power. Botnet owners will be happy to have a task that requires even less communication than Bitcoin itself. Finally the varience inherent in them is annoying too. But it's an interesting idea. -- 'peter'[:-1]@petertodd.org 01358eaf811792b28798a04103b2e47aecf54268736514defd2f signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
On Mon, May 6, 2013 at 3:51 PM, Adam Back wrote: > Maybe I could hack a pool to co-opt it into my netsplit and do the work for > me, or segment enough of the network to have some miners in it, and they do > the work. Or you can just let it mine honestly and take the Bitcoins. This is fast (doesn't require weeks of them somehow not noticing that they're isolated), and yields the values I listed as 'costs' if you would have otherwise been able to use it to mine the difficulty down to 1. Cost is just as much foregone income from the alternative attack you could have done instead. > nor even topological, nor even > particularly long-lived. At least for attacks that drive the difficulty down it does. If you want to talk about abusing a pool or creating a partition in order to create short reorgs— I agree, those don't have to be long lived and you can find many messages where I've written on that subject. It's inconsiderate to propose one attack and when I respond to it changing the attack out from under me. :( I would have responded entirely differently if you'd proposed people segmenting the network and creating short reorgs instead of mining the difficulty down. > Do you know if there is any downwards limit on difficulty? I know it takes > going slow for a long and noticeable time, but I am just curious on the > theoretical limit. Every 2016 blocks can at most lower the difficulty by a factor of 4, thats where the log4 (number of 2016 groups needed) and 4^n (factor in cost reduction for each group) come from in the formulas I gave previously. > I dont see the signatures. http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download The signatures can't be inside the tarball because they sign the tarball. Seems like the website redesign managed to hide the signatures pretty good. They're in the release announcements in any case, but that should be fixed. Even when they were prominently placed, practically no one checked them. As a result they are mostly security theater in practice :(, — so— unfortunately, is SSL: there are many CA's who will give anyone a cert with your name on it who can give them a couple hundred bucks and MITM HTTP (not HTTPS!) between the CA's authentication server and your webserver. Bitcoin.org is hosted by github, even if it had SSL and even if the CA infrastructure weren't a joke, the number of ways to compromise that hosting enviroment would IMO make SSL mostly a false sense of security. The gpg signatures and gitian downloader signatures provide good security if actually used, solving the "getting people to use them" problem is an open question. And I agree, this stuff is a bigger issue than many other things like mining the difficulty down. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote: >On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote: >> bitcoins primaryvulnerability IMO (so far) is network attacks to induce >> network splits, local lower difficulty to a point that a local and >> artificially isolated area of the network can be fooled into accepting an >> orphan branch as the one-true block chain, > >It currently costs about 2016*25*$120 = six million dollars to >reduce the difficulty in your isolated fork by a factor of 4. Well I take your point that you have to produce 2016 blocks, but at a lower rate. But that doesnt directly translate into my cost, I am thinking pure network hacking. Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. I am just thinking $500k/day worth of relatively perfect crime reward is a lot of motivation for hacking networks. Many routers home and even carrier are vulnerable to people armed with cisco source code & 0-days. The netsplit doesnt have to be geographical, nor even topological, nor even particularly long-lived. If you control enough people's network routing at a low enough level, you dont even have to stop transactions, nor do any mining work, just stop blocks from the netsplit crossing over, and hold that position for say a day (if your netsplit has 1/24 of network hash rate in it, so the split gets 6 confirmations to reassure the victims) and let the miners do the work. Do enough transactions to do a big cash out (spend differently on the two netsplits). Obviously a big and human inattentive pool, dark-miner etc is the ideal target to put into the netsplit to increase the power while controlling less nodes. Malware could do the same thing for clients, dont forget most are running windows. Malware could also start a miner if none present. >> maybe even from node first install time. > >Protecting against that— making sure any such attack has to start from >a high difficulty— is, in my opinion, the biggest continued >justification for checkpoints. Do you know if there is any downwards limit on difficulty? I know it takes going slow for a long and noticeable time, but I am just curious on the theoretical limit. >> (btw I notice most of the binaries and tar balls are not signed, nor served >> from SSL - at least for linux). > >They are signed. I dont see the signatures. http://bitcoin.org/en/download I see no signatures for linux and none in the tarball. There are some public keys inside the tarball, thats it. Also no SSL. sourceforge support SSL so you can download that. But bitcoin.org doesnt even answer 443, and the source forge link is HTTP. But even if the sourceforge link was SSL one should not serve an SSL download link from an HTTP page, any more than type a password into an HTTPS form action on an HTTP page. The attacker can just redirect and the user doesnt know what is legitimate. Consequently even if there is code signing on the windows exe, the user doesnt know that, nor who they should be signed by, and as they are served via HTTP, its bypassable. I guess by far the easiest way to attack right now (at least linux users) is just to change the binaries to create a user operated netsplit, or just have all their wallets empty to you via a mix once the amount gets interesting. (All attacks hypothetical of course - I'm actually a white-hat type of person). Adam -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote: > [Aside] I was reading Peter's fidelitybond writeup for his idea on contract > value accounting, and he points to Stephan's post from last September on > payer-encoded metadata ( > https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which > Timo applies here. As a relative newcomer, this is what I am loving most > about Bitcoin. The widespread disclosure we do is a good thing for sure. Keep in mind that Bitcoin is brand new technology, and brand new fields tend to get lots of people coming in and trying to patent them. Public disclosure, and bitcointalk, the email list, and github all count, is a valuable tool to ward off potential threats in the future if it ever comes to that. FWIW it might not be a bad idea to see if archive.org would accept some of the key documentation like the development section of the forum, the email list archives, and the irc logs. Some issues, especially on the forum, with people's ability to edit posts after the fact, but we're breaking new ground here and the history should be archived. -- 'peter'[:-1]@petertodd.org 00f5a3175efc20cdac41f848d47dc7d00debe821ebfa69f91db9 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote: > Of course you'd probably need zerocoin to stand much chance of proving an > address private key of an unlinked coin was in the double-spend disclosed > attribute in the first place, and as we know zerocoin is not that efficient. Sounds like a lot of research potential with many far off possiblities. :) > >Make the node identity expensive to obtain. For instance, construct PoW's > >including the node pubkey somehow, > > that could be easily done with the work of creating a vanity address. eg > address containing many leading 0s. Bitcoin is interesting because it provides a nice way to determine the value of a proof-of-work. Lets suppose you have a digest D and want to create a proof of work for that digest. 1) Select a block B1 that is reasonably deep in the blockchain. (You don't want it getting re-orged out of existence) Six blocks deep is probably plenty. 2) Construct an invalid block header, BP, with SHA256(B1 | D) as the previous block hash. All other fields can be set to whatever is required by your hashing unit. (the merkle root would be an option too, but many hashing setups can't put arbitrary data into it) 3) Hash until you have found the PoW with the difficulty you want. 4) Timestamp BP in the blockchain, resulting in a merkle path M leading to a subsequent block B2. (1) Now determining the value of D has a nice compact proof: B1, BP and M and B2. Taking the minimum of the difficulties of B1 and B2 (in case they cross a retarget boundry; don't want to create strange incentives) determine the expected return in Bitcoins from the block reward had the hasher solved valid blocks instead and you can determine exactly how much the proof-of-work was worth, kinda... Things get a bit complex from here on. First of all there isn't a compact proof that will tell you how much the fees of solving that block would have been worth, and there can't be because miners can easily manipulate the apparent fees of a block in both directions. Also as with fidelity bonds (https://en.bitcoin.it/wiki/Fidelity_bonds) the question of which value to use, historic or current, is important too. If you use the Bitcoin face value increases or decreases of the value of a Bitcoin are arguably distorting. On the other hand, if you use historical exchange rates, which currency do you use and where do you get trustworthy historical exchange rate data? (2) 1) See https://github.com/opentimestamps 2) Which reminds me, I do need to get around to bugging Mt. Gox to PGP sign their exchange rate data and timestamp it properly, or do one or both myself. It should be archived at archive.org or something too, heck, the blockchain should be too, although timestamping that will require a bit more work... -- 'peter'[:-1]@petertodd.org 0190ee1bf5262b2557eb69b49d0e14e1d644ec44a8488f7f5181 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote: >> Hmm: maybe one could use a Brands private credential with offline double >> spend detection, with the reputation but not coin address of the node >> disclosed, and the nodes coin address embedded in the proof. Each node >> could be is own CA, providing a ZKP. If the node ever double spends a coin, >> it loses its reputation as the coin address is revealed. > >Be careful not to mix up the concept of a relay node with someone >posessing Bitcoins. Node's don't spend coins, people/wallets do. My comment was to say that a good behaviour bond for a relay node could be put on an address that is defined as unspendable until such time as an auditor can prove the node engaged in the undesired behaviour, at which point the audit receives the payment as part of his proof. Or until the node ceases to operate. Its a smart contract. However I added to that, that it is still possible to do that while preseving privacy, to point out that it is technically possible, for people to be aware of in their mental toolbox, if it helps solve an otherwise tricky problem. So that would be a privacy preserving smart contract, the parties are unknown, and unknowable (with unconditional security even), but still the smart contract executes. In some sense a privacy preserving smart-contract is closer to the real point of Szabo's smart-contract idea because you cant try to renege on the contract in a conventional court - because you cant identify your counter-party. Bitcoins privacy feature is fairly weak so that is probably often not true. Of course you'd probably need zerocoin to stand much chance of proving an address private key of an unlinked coin was in the double-spend disclosed attribute in the first place, and as we know zerocoin is not that efficient. > Make the node identity expensive to obtain. For instance, construct PoW's > including the node pubkey somehow, that could be easily done with the work of creating a vanity address. eg address containing many leading 0s. Adam -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 08:32:22PM +0200, Adam Back wrote: > But what exactly could you prove about a node? You dont really know if a > node is an originator for a double spend, it could be relay. And for > privacy and security you cant expect the node to use its coin address > private key. re: double-spends - punishing relay nodes and miners for them is a very bad idea. Ultimately it is the blockchain by which Bitcoin comes to consensus about what transactions belong in the blockchain - to punish double-spends implies a second consensus mechanism. Anyway it's unnecessary: you can hold the actual spender accountable for double-spends and punish them directly rather than adding a lot of complexity and dangerous assumptions about propagation to the Bitcoin core network. Some useful things you can hold relay nodes accountable for without a lot of complexity: 1) Having a reasonably correct view of the best block. Make the node sign a statement including a block hash sequence (the last 3-6 blocks) and what it believes the current time is. 2) Accurate knowledge of the blockchain. Sign a statement claiming that what block hash is for a given chain height. Note that due to reg-orgs this is actually a different statement than #1 and nodes should be careful what they are claiming. 3) Accurate knowledge of the UTXO set. Sign a statement claiming that a given txid:vout for the current best block hash is in or not in the UTXO set. 4) Accurate bloom filtering; same idea as #3 5) Make the node identity expensive to obtain. For instance, construct PoW's including the node pubkey somehow, or purchase fidelity bonds for the node's identity. Makes sybil attacks more difficult, among other things. 5) Provide useful propagation/mining services. Sign a txid and timestamp/blockhash-sequence, and hold the node accountable for how long it takes the txid to make it into the blockchain. Useful especially for miners offering the service of mining your transaction. > Hmm: maybe one could use a Brands private credential with offline double > spend detection, with the reputation but not coin address of the node > disclosed, and the nodes coin address embedded in the proof. Each node > could be is own CA, providing a ZKP. If the node ever double spends a coin, > it loses its reputation as the coin address is revealed. Be careful not to mix up the concept of a relay node with someone posessing Bitcoins. Node's don't spend coins, people/wallets do. > ps I have an opensource openSSL based Brands (& Chaum) credential library at > http://www.cypherspace.org/credlb/ I didnt actually implement the ECDL > version, just the DL version, but that is not so hard, and its on my todo > list. (There is also a strong RSA assumption version, also not > implemented). That stuff is cool, but we should focus first on simple efforts, like SSL transport, that do not require complex cryptography to obtain an improvement in security. Of course, not to say long-term research is bad, but that's just not going into the Bitcoin reference client in the near future. -- 'peter'[:-1]@petertodd.org 0124d42390b0db4c125f6be87835c49dc88f1bdeba527b77abc2 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
btw with nodes for transport security you might use self-certifying keys. Referring to Zooko's triangle, then the key is the node identity. Similar to a bitcion address. So then just another ECDSA key and use emphemeral ECDH for transport authenticated with the nodes key. Maybe there can be some value to reputation to a node - eg it can charge a higher micropayment for its p2p network services, a node with a good reptuation could charge a higher micropayment for relaying (though bitcoin itself probably doesnt like micropayments as bloating the transaction log). Another ZKS era idea I had was to have a gossip protocol for users to find out what other people think about the trustworthiness and reliability of nodes. If that info is distributed via gossip over multiple channels and network connections over time, and kept in something like a gnutella host cache (just a cache of random info with some eg random replacement policy) it becomes very hard for a dishonest node to censor evidence of its low reputation. It is best as Gregory said to be able to directly prove, and punish by block-chain validation, because that is more smart-contract like. Bisbehave and nodes wont connect to you or lose somehow. But what exactly could you prove about a node? You dont really know if a node is an originator for a double spend, it could be relay. And for privacy and security you cant expect the node to use its coin address private key. Hmm: maybe one could use a Brands private credential with offline double spend detection, with the reputation but not coin address of the node disclosed, and the nodes coin address embedded in the proof. Each node could be is own CA, providing a ZKP. If the node ever double spends a coin, it loses its reputation as the coin address is revealed. btw another old idea was to require proof of the existance of the private key of a high value coin in the double-spend revealed information. Then basically to get a higher good-behaviour bond, the node ties up more coins, and if a node cheats, the first person to discover this collects the forfeited good behaviour bond. Adam ps I have an opensource openSSL based Brands (& Chaum) credential library at http://www.cypherspace.org/credlb/ I didnt actually implement the ECDL version, just the DL version, but that is not so hard, and its on my todo list. (There is also a strong RSA assumption version, also not implemented). On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote: >> 1) Non-repudiation is only useful with fraud proofs, and they will have >> to be thought out for everything the node might claim. > >That isn't so. If a node is reliably rogue I can go manually gather >evidence and people can manually take action against it. Consider the >DNSseeds, right now fraud proofs really wouldn't matter— the limited >amount of trust put in those things is based not on "oh no, nodes will >ignore you in the future if you're bad", it's based on the ability of >misconduct to sully the operator's reputation. > >But without non-repudiation the ability to tie reputation to good >behavior is fairly limited especially if they perform targeted >attacks. "Wasn't me" > >Instead— I'd argue that non-repudiation is always useful when there is >trust. It's things like fidelity bonds— a trust generator that depend >on automatic enforcement— that are only useful with fraud proofs. > >> Anyway, the concept of a per-node identity keypair is the first step >> towards non-repudiation, and implementing SSL transport. > >Yea, indeed, per-node keys are useful for a bunch of things. Care is >needed to avoid problems like deanonymizing use over tor with them. > >-- >Learn Graph Databases - Download FREE O'Reilly Book >"Graph Databases" is the definitive new guide to graph databases and >their applications. This 200-page book is written by three acclaimed >leaders in the field. The early access version is available now. >Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote: > bitcoins primary > vulnerability IMO (so far) is network attacks to induce network splits, > local lower difficulty to a point that a local and artificially isolated > area of the network can be fooled into accepting an orphan branch as the > one-true block chain, Uh. It currently costs about 2016*25*$120 = six million dollars to reduce the difficulty in your isolated fork by a factor of 4. To reduce it by a factor of 1000 (what would be required to make a parallel fork that you could maintain in realtime with a single avalon device) the cost is sum(2016*25/4^n*120,n,0,ceil(log4(1000))) or about eight million dollars. Surely you can think of attacks on Bitcoin which are less expensive than eight million dollars. :P > maybe even from node first install time. Protecting against that— making sure any such attack has to start from a high difficulty— is, in my opinion, the biggest continued justification for checkpoints. > (btw I notice most of the binaries and tar balls are not signed, nor served > from SSL - at least for linux). They are signed. > With ToR, it has a similar bootstrap problem to bitcoin. So while that may > help it is also passing the buck, not necessarily solving the problem. And No, it doesn't. It has centrally controlled directories that publish an official Truth of the Network. Someone can isolate you and thus DOS you, but they can't put you on a fantasy tor network. But ... centeralized. > as I said I think its possible bitcoin has a higher assurance need in that > the attackers motivated my $$ might put more effort in than the odd It does, and we also consider decentralization a core value. But even the tor project would like to decentralize more. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 10:53 AM, Peter Todd wrote: > > We don't have non-repudiation now, why make that a requirement for the > > first version? Adding non-repudiation is something that has to happen at > > the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure > > you're connection isn't being tampered with and is encrypted. > > Because if you just want bitcoin p2p over SSL... just start up stunnel > on another port. Done. You've still solved nothing about the problem > of discovery issue. stunnel only works if both sides support it. re: discovery, the whole reason I brought up SSL was the idea that a seed whome you have a secure connection to, like HTTPS or SSL, can include the peer pubkey along with the peer's IP address, allowing you to be sure you've connected to the peer the seed is giving you rather than some other imposter. Equally it'll let you be sure you've connected to the correct peer the second time. For applications where you *don't* need non-repudiation SSL is already implemented and solves the secure peer communication issue, including encryption, in an efficient way without requiring a lot of code complexity to implement. SSL could be implemented as a Google Summar of Code project by an average developer, and importantly re-implemented by all the alt-clients out there with relatively little work. It may even be the case that some usage scenarios do find the CA system useful. I might want to do -addnode ssl://petertodd.org on my Android wallet to be sure I've connected to my Bitcoin node rather than some MITM ISP imposter. I already have a SSL cert from a CA for petertodd.org that I can use and my Android phone already has a list of CA's I can put a reasonable amount of trust in. > > 1) Non-repudiation is only useful with fraud proofs, and they will have > > to be thought out for everything the node might claim. > > That isn't so. If a node is reliably rogue I can go manually gather > evidence and people can manually take action against it. Consider the > DNSseeds, right now fraud proofs really wouldn't matter— the limited > amount of trust put in those things is based not on "oh no, nodes will > ignore you in the future if you're bad", it's based on the ability of > misconduct to sully the operator's reputation. Sure, but how will non-repudiation be implemented? By having the node sign the messages they send with their pubkey, and as Mike suggests likely doing so in some sort of chained hash or preferably merkle mountain range to allow for constructing proofs over multiple messages. That has nothing to do with encrypting the transport, and will always be a lot slower than SSL's symmetric cipher for when you don't need non-repudiation but do want to be sure you've connected to the right node. > > Anyway, the concept of a per-node identity keypair is the first step > > towards non-repudiation, and implementing SSL transport. > > Yea, indeed, per-node keys are useful for a bunch of things. Care is > needed to avoid problems like deanonymizing use over tor with them. Per-node keys really need to be per listening address by default. In fact, I'd argue for creating new keys on startup by default. -- 'peter'[:-1]@petertodd.org 015ef6fc2fc45adc1de0c344e99a59453bb09ac470a1d02b787d signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Bitcoin p2p seeding requirements hav some ToR similarities, and we went through the same security considerations with Zero-Knowledge systems freedom network. Though bitcoins attacker profile and motivation is different - so the defense maybe even more demanding. At least you have no shortage of nodes and perhaps merchant interest and general good-will to lean on. At ZKS I proposed we should fix the exit node issue (exit sees where you go often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel equiv) could terminate right on the web site. (ZKS freedom network is long dead but some of the ideas I think made it into ToR, eg I hope my end2end forward anonymity idea that is implemented in Zach Brown's cebolla.) Anyway I'd have about DNS being of limited value: bitcoins primary vulnerability IMO (so far) is network attacks to induce network splits, local lower difficulty to a point that a local and artificially isolated area of the network can be fooled into accepting an orphan branch as the one-true block chain, maybe even from node first install time. (btw I notice most of the binaries and tar balls are not signed, nor served from SSL - at least for linux). Therefore as it applies to discover, you want to be able to discover peers through as many network routes, and even steganographic protocols as possible. eg if a popular web server (say apache, or an apache module) put a steganographic peer discover relay from its own network area, even for a small bitcoin fee, that would help a lot. (Steganographic in the SSL sense would just mean that the peer seed request to /btcseed.cgi would not be distinguishable to someone highly sophisticated on the inside of the router all the peers traffic is routed through. Eg you could easily do this with a special magic header that overwrites something else or deletes some unnecessary header so that the request at least is a standard size, and pad the response to the same size as the site index.html or whatever). If the user picks a few SSL sites and cross checks (more for high value) a subset of peers available on all and uses them as his seed that seems like a better direction. In that way an attacker cant control the network without denying service to popular SSL sites, which would be a warning sign to users, or having at his disposal a SSL sub-CA cert (like happened with diginotar and gmail). You may be able to pin CAs for popular sites. Obviously to the extent you're using SSL you want to generally use EDH for forward-secrecy. And not RC4 :) Probably anysite that accepts bitcoin payment will be happy to run such a mod-bitcoin. With ToR, it has a similar bootstrap problem to bitcoin. So while that may help it is also passing the buck, not necessarily solving the problem. And as I said I think its possible bitcoin has a higher assurance need in that the attackers motivated my $$ might put more effort in than the odd dictatorship trying to pay lip service to preventing people reading pages on a blacklist. Given the vulnerability of DNS to poisoning I would not trust it too much. I know its just a bootstrap, but ideally you dont want to bootstrap from a known publicly vulnerable protocol - it invites DNS poison net splits against new users. Also to the extent that users local clock is under his control (with unuthentcated NTP?) he should also treat sudden dramatic changes in luck (deviations from 10min interval) as suspicious. Unfortunately at present because of the first past the post nature of the bitcoin lottery, reduced variance hashcash cannot be used, so its hard to infer too much even from quite significant luck changes. Adam On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote: >> Speaking of, off-topic for this discussion, but in the future >> node-to-node communicate should be encrypted and signed > >Yes, I'd like to do this. The threat isn't really ISPs which are >mostly trustable (the worst they normally do outside of places like >China is dick about with ads), the big threat is people who use >untrusted WiFi without realising and end up thinking they received >money when actually they were just connected to a hotspot running in >the attackers pocket. I'm rather expecting that kind of thing to >happen in future. > >I think we can converge on the best solution with several iterations: > >Iteration 1) Make it clear in the UI that if the phone is connected to >WiFi, payments from untrusted people should not be accepted. Currently >the Android app merely says the money won't be spendable for a few >minutes. It needs to communicate the "may not exist" aspect more >clearly. If you're connected via a cell tower, the existing wording is >fine - it's very unlikely your telco is trying to scam you in a >person-to-person transaction, traffic is encrypted and 3G+ connections >authenticate the network so you can't be MITMd except by your telco. >Assuming you have a good list of IPs, of course. > >Iteration 2) Give nodes k
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 10:53 AM, Peter Todd wrote: > We don't have non-repudiation now, why make that a requirement for the > first version? Adding non-repudiation is something that has to happen at > the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure > you're connection isn't being tampered with and is encrypted. Because if you just want bitcoin p2p over SSL... just start up stunnel on another port. Done. You've still solved nothing about the problem of discovery issue. > 1) Non-repudiation is only useful with fraud proofs, and they will have > to be thought out for everything the node might claim. That isn't so. If a node is reliably rogue I can go manually gather evidence and people can manually take action against it. Consider the DNSseeds, right now fraud proofs really wouldn't matter— the limited amount of trust put in those things is based not on "oh no, nodes will ignore you in the future if you're bad", it's based on the ability of misconduct to sully the operator's reputation. But without non-repudiation the ability to tie reputation to good behavior is fairly limited especially if they perform targeted attacks. "Wasn't me" Instead— I'd argue that non-repudiation is always useful when there is trust. It's things like fidelity bonds— a trust generator that depend on automatic enforcement— that are only useful with fraud proofs. > Anyway, the concept of a per-node identity keypair is the first step > towards non-repudiation, and implementing SSL transport. Yea, indeed, per-node keys are useful for a bunch of things. Care is needed to avoid problems like deanonymizing use over tor with them. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote: > On Mon, May 6, 2013 at 10:19 AM, Peter Todd wrote: > >> running hash of all messages sent on a connection so far. Add a new > >> protocol message that asks the node to sign the current accumulated > >> hash. > > We already depend on OpenSSL, why not just use standard SSL? > > SSL doesn't actually provide non-repudiation. We actually want > non-repudiation. I want to be able to prove to others that some node > deceived me. We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure you're connection isn't being tampered with and is encrypted. 1) Non-repudiation is only useful with fraud proofs, and they will have to be thought out for everything the node might claim. > (there are a number of other arguments I could make against SSL, but > that one is probably sufficient— or rather, it's an argument that we > should have some way of cheaply getting non-reputable signatures > regardless of the transport) Exactly. Implement an SSL-protected transport, and leave non-repudiation and broader issues of node identity as a later, long-term project. Many client won't even want to support all that complexity, but they'll still want to cheaply get the advantages SSL has with regard to MITM resistance and privacy with little effort. Anyway, the concept of a per-node identity keypair is the first step towards non-repudiation, and implementing SSL transport. > couple attempts it can be minutes before it gets a connection. We're > short on onion peers and I sometimes get inbound connections before I I run a fast node on EC2 that only accepts inbound connections over Tor and I regularly have about ~50 inbound peers. -- 'peter'[:-1]@petertodd.org 0042d8b5bc3ca04847f711b82b66f08b7360a565ebd0b131621c signature.asc Description: Digital signature -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 10:19 AM, Peter Todd wrote: >> running hash of all messages sent on a connection so far. Add a new >> protocol message that asks the node to sign the current accumulated >> hash. > We already depend on OpenSSL, why not just use standard SSL? SSL doesn't actually provide non-repudiation. We actually want non-repudiation. I want to be able to prove to others that some node deceived me. (there are a number of other arguments I could make against SSL, but that one is probably sufficient— or rather, it's an argument that we should have some way of cheaply getting non-reputable signatures regardless of the transport) >> Last time I looked, Tor wasn't really usable in library form and >> connecting to hidden services is really slow. So it'd be an issue to >> just re-use it out of the box, I think. > For phone stuff you should work with The Guardian Project - they've > implemented Tor on Android among other things and want to find easier > ways for apps to use it. Also look into torchat, which bundles a special tor build and runs a hidden service. Because of services like Blockchain.info attacking the casual privacy users not using their webwallet service I've been thinking that even for clients that don't normally use tor their own transaction announcements should probably be made by bringing up a connection over tor and announcing. But thats another matter... I've switched to running on tor exclusively for my personal node (yay dogfooding) and I've found it to connect and sync up very fast most of the time. The biggest slowdown appears to be the our timeout on the tor connections is very high and so if it gets unlucky on the first couple attempts it can be minutes before it gets a connection. We're short on onion peers and I sometimes get inbound connections before I manage to get an outbound. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 1:19 PM, Peter Todd wrote: > For phone stuff you should work with The Guardian Project - they've > implemented Tor on Android among other things and want to find easier > ways for apps to use it. You know my feelings about Java ;p but for hidden services, there really does need to be a lib for server apps. A proxy server approach is much more fragile, in certain scenarios, than directly implementing an internal Tor hidden service node, and handling the TLS connections within your own network framework. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote: > Iteration 1) Make it clear in the UI that if the phone is connected to > WiFi, payments from untrusted people should not be accepted. Currently > the Android app merely says the money won't be spendable for a few > minutes. It needs to communicate the "may not exist" aspect more > clearly. If you're connected via a cell tower, the existing wording is > fine - it's very unlikely your telco is trying to scam you in a > person-to-person transaction, traffic is encrypted and 3G+ connections > authenticate the network so you can't be MITMd except by your telco. > Assuming you have a good list of IPs, of course. You mean scam you with a zero-conf transaction that hasn't actually been broadcast? You know how I feel about zero-conf. > Iteration 2) Give nodes keys that appear in addr broadcasts and seed > data (whether it be via https or otherwise), and have each node keep a > running hash of all messages sent on a connection so far. Add a new > protocol message that asks the node to sign the current accumulated > hash. Not all messages really need to be signed, eg asking for > signatures of blocks is sort of pointless at high difficulty levels > because the structures are self proving and a simple watchdog timer > that looks for unusually slow progress is probably enough. If the > client keeps the same accumulated hash then when you encounter > something you care about the accuracy of, you can ask for a signature > over all traffic so far. We already depend on OpenSSL, why not just use standard SSL? Define a per-node compressed pubkey to pass around, and then do whatever is easiest to get the actual SSL up and running. If we have to use that pubkey to in-turn sign for a secondary RSA key or whatever due to compatibility, no big deal. Define a new service bit SSL and if you connect to a SSL supporting node switch to SSL within the same TCP connection. > Iteration 3) Do something about end to end encryption, just delegate > everything to Tor, or find some other way to obfuscate the origin of a > transaction (a mini onion network for example). Obfusication probably isn't the hard part, it's SPV bloom filter privacy that is the tough one, but probably a problem better handled by Tor. > Last time I looked, Tor wasn't really usable in library form and > connecting to hidden services is really slow. So it'd be an issue to > just re-use it out of the box, I think. For phone stuff you should work with The Guardian Project - they've implemented Tor on Android among other things and want to find easier ways for apps to use it. -- 'peter'[:-1]@petertodd.org 014671272e3a4dd966bb56d4a9a27751b5cd4dc75dc931660cb5 signature.asc Description: Digital signature -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
> Speaking of, off-topic for this discussion, but in the future > node-to-node communicate should be encrypted and signed Yes, I'd like to do this. The threat isn't really ISPs which are mostly trustable (the worst they normally do outside of places like China is dick about with ads), the big threat is people who use untrusted WiFi without realising and end up thinking they received money when actually they were just connected to a hotspot running in the attackers pocket. I'm rather expecting that kind of thing to happen in future. I think we can converge on the best solution with several iterations: Iteration 1) Make it clear in the UI that if the phone is connected to WiFi, payments from untrusted people should not be accepted. Currently the Android app merely says the money won't be spendable for a few minutes. It needs to communicate the "may not exist" aspect more clearly. If you're connected via a cell tower, the existing wording is fine - it's very unlikely your telco is trying to scam you in a person-to-person transaction, traffic is encrypted and 3G+ connections authenticate the network so you can't be MITMd except by your telco. Assuming you have a good list of IPs, of course. Iteration 2) Give nodes keys that appear in addr broadcasts and seed data (whether it be via https or otherwise), and have each node keep a running hash of all messages sent on a connection so far. Add a new protocol message that asks the node to sign the current accumulated hash. Not all messages really need to be signed, eg asking for signatures of blocks is sort of pointless at high difficulty levels because the structures are self proving and a simple watchdog timer that looks for unusually slow progress is probably enough. If the client keeps the same accumulated hash then when you encounter something you care about the accuracy of, you can ask for a signature over all traffic so far. Iteration 3) Do something about end to end encryption, just delegate everything to Tor, or find some other way to obfuscate the origin of a transaction (a mini onion network for example). Last time I looked, Tor wasn't really usable in library form and connecting to hidden services is really slow. So it'd be an issue to just re-use it out of the box, I think. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 12:20:12PM -0400, Jeff Garzik wrote: > > Security will be no worse than before - if any one server/seed is honest > > you're ok - and hopefully better due to the accountability. Obviously > > Indeed, the DNS seeds are just servers run by trusted individuals anyway. Yup, and lets be really clear here: what I'm saying about existing DNS seeds selecting peers from a wider pool isn't to fundementally reduce the trust in those seeds, it's to reduce the amount of effort the people *running* the seeds need to expend to return safe results. > In either case, bitcoinj definitely wants fixing for its over-reliance > on DNS seeds. This has been noted as a problem for a while. Anyway, DNS returns unsigned data usually - DNSSEC is not widely implemented - so at least an alternative seed system with SSL certs could provide a way of getting results from the seed to you in the first place with a different set of vulnerabilities. (I'm not going to say it's really more secure - your ISP can MITM your connections to those remote nodes anyway - but the types of attacks are at least different) Speaking of, off-topic for this discussion, but in the future node-to-node communicate should be encrypted and signed, and seeds should have a mechanism to return the pubkey the node will use for communication. This would protect against your ISP MITM attacking your communications with every node. Of course, Tor hidden service nodes do this already essentially. -- 'peter'[:-1]@petertodd.org 001882c602178bd4dc6501ecd65db1e1380224be98c923043c07 signature.asc Description: Digital signature -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
> > I've noticed on my Android phone how it often takes quite awhile to find > > a peer that will actually accept an incoming connection, which isn't > > surprising really: why should a regular node care about responding to > > SPV nodes quickly? I haven't seen that - remote nodes don't have any special code that knows what kind of client is connecting, so if you're seeing delays I suspect the issue is elsewhere. For example a seed that is serving peers which are overloaded, or the general delays inherent to bringing up a 3G data link from idle (this can take many seconds all by itself). I took out Jeffs seed a few weeks ago in git master because it was often serving nodes that were full, so that should speed things up a bit. The other seeds all run dynamic crawlers. There are lots other ways to optimise performance beyond having fresh seeds, for example, the Android app can (and probably will in future) support putting Bluetooth MAC addresses in the URLs it serves via QRcode/NFC. We prototyped it before but didn't finish. That means that the sending side can provide the receiving side with a transaction via a local Bluetooth socket, which eliminates the need to wait for P2P bringup on the send side. In a typical merchant scenario the receive side is more likely to have WiFi access and is more likely to be talking to the network frequently, so its list of IPs gathered from addr packets would be fresher, and it can do P2P bringup whilst the user is confirming/signing/uploading on the sending side. Overlapping the two buys precious seconds. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 12:12 PM, Peter Todd wrote: > I've noticed on my Android phone how it often takes quite awhile to find > a peer that will actually accept an incoming connection, which isn't > surprising really: why should a regular node care about responding to > SPV nodes quickly? > > For fast startup you would be better served with dedicated nodes that > are backed by fast hardware and high bandwidth internet connections. > You can discourage non-SPV use by refusing to relay full blocks. > > You can have trusted individuals vouch for these special servers with > SSL certificates so you run less of a risk of connecting to a malicious > one trying to limit what information you see. For the initial > implementation, maybe just make a quick SSL accessible service with HTTP > GET so you don't have to integrate SSL into the network protocol and > have a couple of these HTTP GETable servers running. (IE, the trust is > actually that the SPV seed is honest) > > Security will be no worse than before - if any one server/seed is honest > you're ok - and hopefully better due to the accountability. Obviously Indeed, the DNS seeds are just servers run by trusted individuals anyway. In either case, bitcoinj definitely wants fixing for its over-reliance on DNS seeds. This has been noted as a problem for a while. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote: More generally, I think this shows clearly how SPV nodes have weaker security than constantly operating full nodes, which we knew already, so why not build a better SPV-specific system instead? I've noticed on my Android phone how it often takes quite awhile to find a peer that will actually accept an incoming connection, which isn't surprising really: why should a regular node care about responding to SPV nodes quickly? For fast startup you would be better served with dedicated nodes that are backed by fast hardware and high bandwidth internet connections. You can discourage non-SPV use by refusing to relay full blocks. You can have trusted individuals vouch for these special servers with SSL certificates so you run less of a risk of connecting to a malicious one trying to limit what information you see. For the initial implementation, maybe just make a quick SSL accessible service with HTTP GET so you don't have to integrate SSL into the network protocol and have a couple of these HTTP GETable servers running. (IE, the trust is actually that the SPV seed is honest) Security will be no worse than before - if any one server/seed is honest you're ok - and hopefully better due to the accountability. Obviously you can use the existing bootstrap method in parallel at the same time. What's good about partitioning between SPV and full node bootstrapping, is the regular DNS seeds can optimize the other way: accept that some nodes may turn out to be evil, and limit the damage by returning peers from the widest pool possible even if some of those peers may be a bit slow and unreliable. An attacker can't dominate the results by running a small number of fast reliable nodes because the results returned comes from a huge pool, so they are stuck with getting access to lots of IP addresses, and maybe in the future we'll have even better methods of resisting sybil attacks, and we will be able to implement those methods even if they mean initial bootstrapping is slower. > Subject change to reflect that this is off-topic for the old thread. > > Eventually, I think it makes sense to move to a system where you get seeds > > from > > a DNS (or other mechanism), connect to one or a few of the results, do a > > getaddr, > > fill your peer IP database with it, and disconnect from the DNS seeded > > peer. > > > This obviously makes no difference from a security perspective. If a DNS > seed is compromised it can feed you nodes that just connect you back to the > sybil. If you seed from DNS then that's your root of trust. > > The problem with moving away from DNS seeding for bitcoinj clients at least > is that SPV clients are very sensitive to startup time. It isn't OK to > spend two minutes trying to connect to lots of long-dead IP addresses if > you're wanting to pay your bill in a restaurant. That means either you have > to spin up a lot of TCP connections in parallel, which I know from bitter > experience can cause problems with some crappy wifi routers (they think > it's a synflood), or you get a known fresh source of IPs like a DNS seed > response and then later on bring up connections to the P2P network from > that. > > Implementing the latter is complicated - you have to partition your nodes > so the seed peers are separated from the peers you found via addr > broadcasts and seeded peers can't pollute your addr-found peers unless it's > your first run. > > I've actually not experimented with this for a while. I'm hoping that by > the time this gets to the top of my todo list, network nodes will be stable > enough that actually you can always obtain at least one or two connections > if you try (say) 30 at once. But I have no idea if we're at that stage yet. > -- > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 'peter'[:-1]@petertodd.org 002a871dc011fe28fd8fbffe577c02b91d2de09aeca8216644ef signature.asc Description: Digital signature -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-develop
[Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Subject change to reflect that this is off-topic for the old thread. Eventually, I think it makes sense to move to a system where you get seeds > from > a DNS (or other mechanism), connect to one or a few of the results, do a > getaddr, > fill your peer IP database with it, and disconnect from the DNS seeded > peer. This obviously makes no difference from a security perspective. If a DNS seed is compromised it can feed you nodes that just connect you back to the sybil. If you seed from DNS then that's your root of trust. The problem with moving away from DNS seeding for bitcoinj clients at least is that SPV clients are very sensitive to startup time. It isn't OK to spend two minutes trying to connect to lots of long-dead IP addresses if you're wanting to pay your bill in a restaurant. That means either you have to spin up a lot of TCP connections in parallel, which I know from bitter experience can cause problems with some crappy wifi routers (they think it's a synflood), or you get a known fresh source of IPs like a DNS seed response and then later on bring up connections to the P2P network from that. Implementing the latter is complicated - you have to partition your nodes so the seed peers are separated from the peers you found via addr broadcasts and seeded peers can't pollute your addr-found peers unless it's your first run. I've actually not experimented with this for a while. I'm hoping that by the time this gets to the top of my todo list, network nodes will be stable enough that actually you can always obtain at least one or two connections if you try (say) 30 at once. But I have no idea if we're at that stage yet. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote: > You are welcome to optimise P2P addr broadcasts or develop better bootstrap > mechanisms. I think John's actually has a point here. If we're judging the quality of a protocol change by how compatible it is with DNS seeding, then we're clearly not using DNS seeding as seeding anymore (=getting an entry point into the P2P network), but as a mechanism for choosing (all) peers. Eventually, I think it makes sense to move to a system where you get seeds from a DNS (or other mechanism), connect to one or a few of the results, do a getaddr, fill your peer IP database with it, and disconnect from the DNS seeded peer. This probably means we need to look at ways to optimize current peer exchange, but that's certainly welcome in any case. -- Pieter -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Requirement for relay field in version packet (protocol version >= 70001)
It's expected to be there, yes. On Mon, May 6, 2013 at 9:56 AM, Addy Yeow wrote: > >From https://en.bitcoin.it/wiki/Protocol_specification#version, is the > relay field (bool/1 byte) required in all version packets coming from > client with protocol version >= 70001? > > > -- > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
You are welcome to optimise P2P addr broadcasts or develop better bootstrap mechanisms. On Sun, May 5, 2013 at 3:12 PM, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sorry I should have used the word bootstrapping there rather than > discovery. > But again I think that shows my point clearly. Centralized methods like DNS > should be used for as little as possible, just simple initial > bootstrapping, > and focus the development efforts towards the non-centralized peer > discovery > mechanisms. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBCAAGBQJRhlpyAAoJEEWCsU4mNhiP+NwH/3RY5vBpSYkwKgTmdKHRc/gw > BJCSV/1MEDECgBTxaRYSzYZyargjsdG50KaIaCq8M1+8DWkBEkH8JFif7UYMlZGM > WROMP6UjAnP1fJ3B2JChdMgRv1HdXJQDQVcO8UnSJschhX8lZZiUySbaqIPuRuV/ > lI7/JkUZvmnms4+HGiaqwfbPO0k6ytJNKxORrk4TzFnThh4dy9WytElc8JHZOFaQ > ly159X5JuEwh8DLOoUtPhaR6tJaJbJLBEt+QJiGnSktPsJCE8p9+4HQ0kMCQr3Ha > 05EHTZEw+TqEPaA7vFLgA/9tWjK9s1Y6sqLOAYiLp/0wSKzCkBO0C5LWFHsJ/XQ= > =aCgi > -END PGP SIGNATURE- > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Requirement for relay field in version packet (protocol version >= 70001)
>From https://en.bitcoin.it/wiki/Protocol_specification#version, is the relay field (bool/1 byte) required in all version packets coming from client with protocol version >= 70001? -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
