Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
Nice, Andrew. Just one minor point. SPV clients do not need to maintain an ever growing list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and thus has O(1) disk usage. Re-orgs past the event horizon cannot be processed but are assumed to be sufficiently rare that manual intervention would be acceptable. On Mon, Mar 2, 2015 at 8:48 AM, Andrew Miller amil...@cs.umd.edu wrote: We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- 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 -- 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] Useless Address attack?
Bitcoind protects against this by storing the addresses it has learned about in buckets. The bucket an address is stored in is chosen based on the IP of the peer that advertised the addr message, and the address in the addr message itself. The idea is that the bucketing is done in a randomized way so that no attacker should be able to fill your database with his or her own nodes. From addrman.h https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h: /** Stochastic address manager * * Design goals: * * Keep the address tables in-memory, and asynchronously dump the entire to able in peers.dat. * * Make sure no (localized) attacker can fill the entire table with his nodes/addresses. * * To that end: * * Addresses are organized into buckets. ** Address that have not yet been tried go into 256 new buckets. * * Based on the address range (/16 for IPv4) of source of the information, 32 buckets are selected at random * * The actual bucket is chosen from one of these, based on the range the address itself is located. * * One single address can occur in up to 4 different buckets, to increase selection chances for addresses that *are seen frequently. The chance for increasing this multiplicity decreases exponentially. * * When adding a new address to a full bucket, a randomly chosen entry (with a bias favoring less recently seen *ones) is removed from it first. ** Addresses of nodes that are known to be accessible go into 64 tried buckets. * * Each address range selects at random 4 of these buckets. * * The actual bucket is chosen from one of these, based on the full address. * * When adding a new good address to a full bucket, a randomly chosen entry (with a bias favoring less recently *tried ones) is evicted from it, back to the new buckets. ** Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not * be observable by adversaries. ** Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive) * consistency checks for the entire data structure. */ On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle thashizn...@yahoo.com.au wrote: Hi, so just a thought as my node relays addresses etc. If I wanted to really slow down communication over the P2P network, what's stopping me from popping up a heap of dummy nodes that do nothing more than exchange version and relay addresses, except I send addr messages with all 1000 addresses pointing to my useless nodes that never send invs or respond to getdata etc so clients connect to my dumb nodes instead of legit ones. I'm thinking that if I fill up their address pool with enough addresses to dumb nodes and keep them really fresh time wise, it could have a bit of an impact especially if all 8 outbound connections are used up by my dumb nodes right? I don't want to do this obviously, I'm just thinking about it as I'm building my node, what is there to stop this happening? -- 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 -- 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] Useless Address attack?
Also (I am fuzzy on the details for this), Bitcoind will detect when a node is misbehaving and (I believe) it will blacklist misbehaving nodes for a period of time so it doesn't continually keep trying to connect to tarpit nodes, for example. On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene kgree...@gmail.com wrote: Bitcoind protects against this by storing the addresses it has learned about in buckets. The bucket an address is stored in is chosen based on the IP of the peer that advertised the addr message, and the address in the addr message itself. The idea is that the bucketing is done in a randomized way so that no attacker should be able to fill your database with his or her own nodes. From addrman.h https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h: /** Stochastic address manager * * Design goals: * * Keep the address tables in-memory, and asynchronously dump the entire to able in peers.dat. * * Make sure no (localized) attacker can fill the entire table with his nodes/addresses. * * To that end: * * Addresses are organized into buckets. ** Address that have not yet been tried go into 256 new buckets. * * Based on the address range (/16 for IPv4) of source of the information, 32 buckets are selected at random * * The actual bucket is chosen from one of these, based on the range the address itself is located. * * One single address can occur in up to 4 different buckets, to increase selection chances for addresses that *are seen frequently. The chance for increasing this multiplicity decreases exponentially. * * When adding a new address to a full bucket, a randomly chosen entry (with a bias favoring less recently seen *ones) is removed from it first. ** Addresses of nodes that are known to be accessible go into 64 tried buckets. * * Each address range selects at random 4 of these buckets. * * The actual bucket is chosen from one of these, based on the full address. * * When adding a new good address to a full bucket, a randomly chosen entry (with a bias favoring less recently *tried ones) is evicted from it, back to the new buckets. ** Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not * be observable by adversaries. ** Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive) * consistency checks for the entire data structure. */ On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle thashizn...@yahoo.com.au wrote: Hi, so just a thought as my node relays addresses etc. If I wanted to really slow down communication over the P2P network, what's stopping me from popping up a heap of dummy nodes that do nothing more than exchange version and relay addresses, except I send addr messages with all 1000 addresses pointing to my useless nodes that never send invs or respond to getdata etc so clients connect to my dumb nodes instead of legit ones. I'm thinking that if I fill up their address pool with enough addresses to dumb nodes and keep them really fresh time wise, it could have a bit of an impact especially if all 8 outbound connections are used up by my dumb nodes right? I don't want to do this obviously, I'm just thinking about it as I'm building my node, what is there to stop this happening? -- 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 -- 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] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
You might consider the dimension taken by the cooperative mining approach of AI Coin, an altcoin that will launch April 27. The coin is an embodiment of principles described in my whitepaper last May, Bitcoin Cooperative Proof of Stake. http://arxiv.org/abs/1405.5741 Currently we do not use staking, as network-wide algorithmic trustworthiness provides the security directly. Network operations, although highly automated with intelligent software agents, has a human-in-the-loop for oversight. Our innovation enables immediate settlement of transactions. Peers in our network cooperate, taking turns creating new blocks. There is single version of the blockchain which is appended to by a single peer, and is replicated by the other peers. Our peers wrap Bitcoind instances, controlling transaction and new block routing to form a scalable super peer topology. Peers have self-signed X.509 certificates which encrypt messages and prevent impersonation. The tamper-evident technology that secures Bitcoin's blockchain and transactions is extended to secure the entire network. Inspired by an idea published by Nick Szabo, our peers maintain tamper-evident logs which are replayed, verified and signed by other peers. Aside from the whitepaper, more current technical information can be found on our forum - where I would be glad to answer questions and debate skeptics - instead of responding in this list off topic. http://ai-cointalk.org I would like thank those here and on IRC who last year encouraged me think outside the box. -Steve CTO AI Coin, Inc. 512.791.7960 http://ai-coin.org -- 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] Useless Address attack?
Hi, so just a thought as my node relays addresses etc. If I wanted to really slow down communication over the P2P network, what's stopping me from popping up a heap of dummy nodes that do nothing more than exchange version and relay addresses, except I send addr messages with all 1000 addresses pointing to my useless nodes that never send invs or respond to getdata etc so clients connect to my dumb nodes instead of legit ones. I'm thinking that if I fill up their address pool with enough addresses to dumb nodes and keep them really fresh time wise, it could have a bit of an impact especially if all 8 outbound connections are used up by my dumb nodes right? I don't want to do this obviously, I'm just thinking about it as I'm building my node, what is there to stop this happening?-- 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] Useless Address attack?
Interesting! Thanks Kevin, I now need to research this and include such protections in my node. Also (I am fuzzy on the details for this), Bitcoind will detect when a node is misbehaving and (I believe) it will blacklist misbehaving nodes for a period of time so it doesn't continually keep trying to connect to tarpit nodes, for example. On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene kgree...@gmail.com wrote: Bitcoind protects against this by storing the addresses it has learned about in buckets. The bucket an address is stored in is chosen based on the IP of the peer that advertised the addr message, and the address in the addr message itself. The idea is that the bucketing is done in a randomized way so that no attacker should be able to fill your database with his or her own nodes. From addrman.h: /** Stochastic address manager * * Design goals: * * Keep the address tables in-memory, and asynchronously dump the entire to able in peers.dat. * * Make sure no (localized) attacker can fill the entire table with his nodes/addresses. * * To that end: * * Addresses are organized into buckets. * * Address that have not yet been tried go into 256 new buckets. * * Based on the address range (/16 for IPv4) of source of the information, 32 buckets are selected at random * * The actual bucket is chosen from one of these, based on the range the address itself is located. * * One single address can occur in up to 4 different buckets, to increase selection chances for addresses that * are seen frequently. The chance for increasing this multiplicity decreases exponentially. * * When adding a new address to a full bucket, a randomly chosen entry (with a bias favoring less recently seen * ones) is removed from it first. * * Addresses of nodes that are known to be accessible go into 64 tried buckets. * * Each address range selects at random 4 of these buckets. * * The actual bucket is chosen from one of these, based on the full address. * * When adding a new good address to a full bucket, a randomly chosen entry (with a bias favoring less recently * tried ones) is evicted from it, back to the new buckets. * * Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not * be observable by adversaries. * * Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive) * consistency checks for the entire data structure. */ On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle thashizn...@yahoo.com.au wrote: Hi, so just a thought as my node relays addresses etc. If I wanted to really slow down communication over the P2P network, what's stopping me from popping up a heap of dummy nodes that do nothing more than exchange version and relay addresses, except I send addr messages with all 1000 addresses pointing to my useless nodes that never send invs or respond to getdata etc so clients connect to my dumb nodes instead of legit ones. I'm thinking that if I fill up their address pool with enough addresses to dumb nodes and keep them really fresh time wise, it could have a bit of an impact especially if all 8 outbound connections are used up by my dumb nodes right? I don't want to do this obviously, I'm just thinking about it as I'm building my node, what is there to stop this happening? -- 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 -- 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] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
This is great to see. On Monday 02 March 2015 11:48:24 Andrew Miller wrote: One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! This is indeed a problem in the research community. Often ideas from here are just overlooked, and e.g., re-invented or not properly acknowledged. Of course, this is (in almost all cases) not intentionally. It's just difficult to keep track of everything. Your paper is a definitely the right approach to bring the researchers closer to the Bitcoin community. Best, Tim -- 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
