Re: [Bitcoin-development] Large-blocks and censorship
On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote: My views on censorship resistance in the face of scaling: 1) I expect if I'm not careful about preserving my privacy with the way I use Bitcoin, then I will always run the risk of being censored by miners. This means connecting to the network anonymously, not reusing addresses, and perhaps even mixing my coins. The onus is on me here to avoid censorship, but I'm optimistic that this privacy preservation can be made pretty automatic. Yes, but keep in mind the meta risk, which is that as Bitcoin becomes centralized one of the types of transactions that will be censored are ones that preserve your privacy. For instance, as it costs thousands of dollars to setup a mining pool, and hence mining pools also become quite visible, it would be very easy for local governments to start doing things like specifying that transactions must be accompanied with a proof of identification. With that proof of course Bitcoin can remain totally legal, and the pool in business. 2) I expect anonymity systems to scale to accommodate Bitcoin full nodes, not Bitcoin to stay small to avoid putting pressure on anonymity systems to scale. Why do you expect that? It's always harder to hide a large amount of bandwidth than a small one, and stenography is limited by the bandwidth of the data it's hiding it. HD video streams aren't going to require more bandwidth in the future. 3) If 2 is too tall an order, then mining in a pool is always an option. There should always be some countries in the world free enough to allow mining pools to operate, and miners in countries that ban Bitcoin can simply connect to these anonymously. If not, then Bitcoin is toast anyway, is it not? If these miners are really interested in avoiding censoring transactions, then they will do their due diligence and choose a pool that doesn't do this. But even if they don't, censorship can be personally avoided by following 1. Right now the thing that keeps pools honest is that setting up another pool is pretty easy; note how most pools are run as hobbyist projects. Similarly you can always use P2Pool, which is totally decentralized. But if running the validating node required to run a pool costs thousands of dollars that competition just isn't there anymore and starting a new pool isn't an option. Remember there will be a chicken and egg problem in that the new pool has thousands of dollars in costs, yet no hashing power yet. As for constantly moving countries, The Pirate Bay is in the same position, and as well as they've done, they still wind up getting shut down periodically. Do you really want access to your funds contingent on some highly visible mining pools, constantly wondering if their local government will change their mind? Anyway, seems that my question was answered: There aren't any clever technical ways to avoid censorship if validating nodes and mining pools are centralized. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
On Thu, Mar 07, 2013 at 06:00:18AM -0500, Peter Todd wrote: It's also notably that auditable off-chain transaction systems are vulnerable. All of the trustworthy ones that don't rely on trusted hardware require at least some of their on-chain transactions to be publicly known, specifically so that the total amount of reserves held by off-chain transaction providers can be audited. At best you can use Gregory Maxwell's suggestion of maintaining a reserve account backed by funds that rarely move, where new deposits go to non-public addresses and result in the depositor receiving funds from the reserve account, but again, if the spendability of those funds is in question, the value of the reserve itself is also in question. Additionally miners can block fidelity bond sacrifice transactions easily; again a critical technologies required to implement some types of off-chain transaction systems, as well as for many other purposes. Oh, and it occured to me: merge-mining is also vulnerable to the exact same censorship forces. Again, with small blocks running P2Pool is feasible, and P2Pool does merge-mining just fine. With large blocks it's easy for the pool to ignore shares that try to merge mine, so your alt-chains competition is also censored. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
To summarize your post - it's another go at arguing for strongly limited block sizes, this time on the grounds that large blocks make it easier for $AUTHORITY to censor transactions? Is that right? -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
On Thu, Mar 07, 2013 at 06:42:32PM +0100, Mike Hearn wrote: To summarize your post - it's another go at arguing for strongly limited block sizes, this time on the grounds that large blocks make it easier for $AUTHORITY to censor transactions? Is that right? Yes. Now, can we solve this problem robustly with clever technology, as is done with UTXO fraud proofs? I can't see a way - can you? Gavin asked me to do a projection for what block sizes could be based on technology improving, and I think that analysis should consider carefully to what degree the current system's quite strong censorship resistance will be impacted. It's interesting to be talking about censorship of transactions, right as the support for implementing technical means to block SatoshiDice transactions is highest. If anything, I think Gregory Maxwell's findings he has posted on IRC showing roughly three quarters of transactions in blocks are SatoshiDice related shows how the current large number of validating nodes makes any effort at even discouraging unwanted traffic quite difficult. In other words, it's a strong sign the censorship resistance of Bitcoin works as intended. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
As an aside, there's a paper coming out in perhaps a few months that describes a new way to provide Chaum-style privacy integrated with Bitcoin, but without the use of blinding and without any need for banks. It's quite smart, I was reviewing the paper this week. Unfortunately the technique is too slow and too complicated to actually integrate, but you'd probably get a kick out of it. It's based on zero knowledge proofs. You can talk to Ian Miers if you like, perhaps he'll send you a copy for review. Back on topic. This idea is not new. I proposed the idea of regulating miners to freeze certain outputs two years ago: https://bitcointalk.org/index.php?action=printpage;topic=5979.0 I concluded that it was not a real risk because both mining and transactions can be done anonymously. Your argument rests on the assumption that you can't mine large blocks anonymously because Tor doesn't scale. Even if we go along with the idea that Tor is the only way to escape regulation (it's not), you should maybe take up its inability to move data sufficiently fast with the developers. Given that they routinely push two gigabits/second today, with an entirely volunteer run network, I think they'll be surprised to learn that their project is doomed to never be usable by miners. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
My views on censorship resistance in the face of scaling: 1) I expect if I'm not careful about preserving my privacy with the way I use Bitcoin, then I will always run the risk of being censored by miners. This means connecting to the network anonymously, not reusing addresses, and perhaps even mixing my coins. The onus is on me here to avoid censorship, but I'm optimistic that this privacy preservation can be made pretty automatic. 2) I expect anonymity systems to scale to accommodate Bitcoin full nodes, not Bitcoin to stay small to avoid putting pressure on anonymity systems to scale. 3) If 2 is too tall an order, then mining in a pool is always an option. There should always be some countries in the world free enough to allow mining pools to operate, and miners in countries that ban Bitcoin can simply connect to these anonymously. If not, then Bitcoin is toast anyway, is it not? If these miners are really interested in avoiding censoring transactions, then they will do their due diligence and choose a pool that doesn't do this. But even if they don't, censorship can be personally avoided by following 1. On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn m...@plan99.net wrote: As an aside, there's a paper coming out in perhaps a few months that describes a new way to provide Chaum-style privacy integrated with Bitcoin, but without the use of blinding and without any need for banks. It's quite smart, I was reviewing the paper this week. Unfortunately the technique is too slow and too complicated to actually integrate, but you'd probably get a kick out of it. It's based on zero knowledge proofs. You can talk to Ian Miers if you like, perhaps he'll send you a copy for review. Back on topic. This idea is not new. I proposed the idea of regulating miners to freeze certain outputs two years ago: https://bitcointalk.org/index.php?action=printpage;topic=5979.0 I concluded that it was not a real risk because both mining and transactions can be done anonymously. Your argument rests on the assumption that you can't mine large blocks anonymously because Tor doesn't scale. Even if we go along with the idea that Tor is the only way to escape regulation (it's not), you should maybe take up its inability to move data sufficiently fast with the developers. Given that they routinely push two gigabits/second today, with an entirely volunteer run network, I think they'll be surprised to learn that their project is doomed to never be usable by miners. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
