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
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
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
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
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
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
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
7 matches
Mail list logo
