* [Bitcoin-development] Large-blocks and censorship
@ 2013-03-07 11:00 Peter Todd
2013-03-07 11:34 ` Peter Todd
2013-03-07 17:42 ` Mike Hearn
0 siblings, 2 replies; 7+ messages in thread
From: Peter Todd @ 2013-03-07 11:00 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4643 bytes --]
So with UTXO merkle-sum-fee-trees and fraud notices(1) we can
effectively audit the blocks produced by miners and provide a way for
SPV nodes to reject invalid blocks without requiring the whole
blockchain data.
Next step: How do we prevent censorship? Can we at all?
Basically while UTXO-style proofs allow anyone to determine if a block
is valid, it's fundementally still miners that choose what transactions
to accept into blocks in the first place. Unfortunately the very nature
of a blockchain is that it is meant to prove that transactions are
public and that a consensus exists about what transactions are
spendable, thus any attempt to hide the bare technical details, txins
and txouts, is futile. Even using encryption doesn't work, because
assuming you convinced a miner to accept your encrypted transaction,
that just shifts the part that makes the transaction public to the act
of revealing the key, which again must be done publicly in the
blockchain to prove consensus.
As transaction volume makes running a validating node more expensive, we
can expect the number of independent pools to decrease, or at the very
least make monitoring those pools easier as volumes grow beyond what
technologies such as Tor can effectively accomodate. This provides the
opportunity to pressure the remaining, identifiable, independent miners
into accepting restrictions on what transactions can be mined.
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.
Of course we can just assume that the current pseudo-anonymity of
transactions is "good enough", but consider the case of stolen coins:
even if the bulk of transactions are effectively anonymous, transactions
can always be made public delibrately and miners pressured into
preventing the movement of coins declared tainted.
Finally it's possible that some kind of chaum token system could be
implemented directly in the blockchain, but this has the problem that A:
no efficient ones are yet known, let alone demonstrated, and B: unless
non-chaum token systems are prohibited by a hard-fork with wide
adoption, the censorship risk is miners deciding to not mine any chaum
token transactions. It's easy to imagine a government deciding that
while they will accept transactions that occure on the public block
chain, and are thus at best pseudo-anonymous, are acceptable any attempt
to conduct truely anonymous transactions will be forbidden.
On the other hand, with small blocks the barriers to entry to becoming a
miner remain low, and mining anonymously behind low-bandwidth
anti-censorship technologies such as Tor remains feasible. Any attempt
by a major pool to censor, IE choose not to mine, a transaction will
naturally lead to an opportunity for an anonymous miner to get a profit
mining that transaction, thus we can expect transactions to be treated
fairly equally on a fee per KB basis. In addition, the ever present
possibility of this happening, further discourages large miners from
doing so in the first place, and in turn gives those miners additional
incentive to resist attempts to restrict what transactions they are
allowed to mine.
Of course off-chain transaction systems can still practice censorship of
transactions on their own, but because the decentralized blockchain
still exists communities subject to such censorship can always create
their own auditable and secure off-chain transaction systems for their
own use. Again, the existence of such systems creates economic
incentives to find ways to move value between all off-chain transaction
systems regardless of imposed restrictions, and again the overall
ability to transfer value freely is maintained.
1) https://bitcointalk.org/index.php?topic=137933.0
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 11:00 [Bitcoin-development] Large-blocks and censorship Peter Todd
@ 2013-03-07 11:34 ` Peter Todd
2013-03-07 17:42 ` Mike Hearn
1 sibling, 0 replies; 7+ messages in thread
From: Peter Todd @ 2013-03-07 11:34 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 11:00 [Bitcoin-development] Large-blocks and censorship Peter Todd
2013-03-07 11:34 ` Peter Todd
@ 2013-03-07 17:42 ` Mike Hearn
2013-03-07 18:30 ` Peter Todd
1 sibling, 1 reply; 7+ messages in thread
From: Mike Hearn @ 2013-03-07 17:42 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 17:42 ` Mike Hearn
@ 2013-03-07 18:30 ` Peter Todd
2013-03-07 21:19 ` Mike Hearn
0 siblings, 1 reply; 7+ messages in thread
From: Peter Todd @ 2013-03-07 18:30 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 18:30 ` Peter Todd
@ 2013-03-07 21:19 ` Mike Hearn
2013-03-07 21:31 ` Daniel Lidstrom
0 siblings, 1 reply; 7+ messages in thread
From: Mike Hearn @ 2013-03-07 21:19 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 21:19 ` Mike Hearn
@ 2013-03-07 21:31 ` Daniel Lidstrom
2013-03-10 8:18 ` Peter Todd
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Lidstrom @ 2013-03-07 21:31 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
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 <mike@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
>
[-- Attachment #2: Type: text/html, Size: 3976 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Large-blocks and censorship
2013-03-07 21:31 ` Daniel Lidstrom
@ 2013-03-10 8:18 ` Peter Todd
0 siblings, 0 replies; 7+ messages in thread
From: Peter Todd @ 2013-03-10 8:18 UTC (permalink / raw)
To: Daniel Lidstrom; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-03-10 8:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-07 11:00 [Bitcoin-development] Large-blocks and censorship Peter Todd
2013-03-07 11:34 ` Peter Todd
2013-03-07 17:42 ` Mike Hearn
2013-03-07 18:30 ` Peter Todd
2013-03-07 21:19 ` Mike Hearn
2013-03-07 21:31 ` Daniel Lidstrom
2013-03-10 8:18 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox