From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Large-blocks and censorship
Date: Thu, 7 Mar 2013 06:00:18 -0500 [thread overview]
Message-ID: <20130307110018.GA7491@savin> (raw)
[-- 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 --]
next reply other threads:[~2013-03-07 11:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 11:00 Peter Todd [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130307110018.GA7491@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox