The talk left me with the impression that their non-recursive SCIP proofs are inexpensive, so I wonder if recursion could be avoided.  For example, if the full state were encoded locally in pairs of adjacent blocks  - as the proposal in this thread would achieve - then a SCIP proof validating the next block could simply assume validity of the two prior blocks, which is fine if the node verifying this proof has verified the SCIP proofs of all preceding blocks as well.  Once blocks become individually unwieldy, perhaps verifying each block would simply take a few extra SCIP proof validations - with SCIP proof authors tackling the transaction and UTXO patricia/radix tree updates by branches.  Could this approach properly remove the need to nest SCIP proofs inside of SCIP proofs, or is there something obvious I'm missing?

Edit: I suppose this would mean that Alice would be sending a slightly different program for Bob to run to produce each SCIP proof in each block?   I guess these programs would have to be a protocol standard, since 'Alice' is really everybody, and would differ only by the hash of the previous block?  All of this is very vague and magical to me still...

After watching that video I can't help but think, with my very limited understanding of it, that SCIP combined with appropriate Bitcoin protocol changes (perhaps like, as you mentioned, localizing the full state in the blockchain using an authenticated UTXO tree) will be able to remove most of the reproduction of work necessary by the network that it currently must do in order to operate trust free, as well as make it possible to shard across untrusted peers the operation of combining new transactions into Merkle trees to produce new block headers for miners to work on.  These would mean the network could remain perfectly decentralized at ridiculously high transaction rates (the work done per node would, I think in theory, scale as O(M log(M) / N), where M is the transaction rate, and N is the total number of network nodes).  This might even mean an always-on zerocoin is feasible (always-on is important so that the anonymity set is maximal, and its users aren't a persecutable (relative) minority).

Anybody with a better understanding of SCIP and its applicability to Bitcoin able to pour cold water on these thoughts for me?

You're preaching to the choir

That's correct.  The bitcoin-denominated tokens issued on OT servers are promises issued by the aforementioned voting pool to redeem for real bitcoins at par.  OT deals with the issue of trust by spreading it out across multiple parties via a multisignature transaction on the blockchain.  What makes me uneasy is there are technical, logistical, and cognitive limits on the total number of parties able to participate in the voting pool, and so the issue of trust ultimately still remains.

Edit: Furthermore, once trust enters the equation, anonymity usually leaves, since most people aren't willing to trust their money to strangers.  Thus, we likely haven't actually attained censorship resistance.

If that's the end game, then I can't help but feel uneasy about having a dozen or so people collectively (via the proposed voting pool) having ultimate control over most of the bitcoins.  Systems that rely on trust tend not to be very decentralized (for cognitive reasons?).

I don't see how having one currency for 'store of value' and one for 'medium of exchange' is 1) possible to centrally plan, and 2) helps to do anything except dilute mining power and liquidity of both.  Bitcoin is a valuable medium of exchange because it commands significant mining power, it commands significant mining power because the block reward is valuable, and the block reward is valuable because it's a good store of value.  (Yes, 'significant' and 'good' are relative terms.)  And even if the currency functions could be separated this way, how would the 'medium of exchange' currency have avoided the very censorship problem it was designed to solve in the first place for the 'store of value' currency?  It's pretty difficult to move back and forth between the two if either one is censored.

The government level attacker would have to match that spent by the new miners, which is roughly proportional to the expected value of their block rewards, which is roughly proportional to the demand there is for the censorship-preserving fork.  Are you doubting this demand?  The effort can be trusted to be as real as the ASICs produced by chip makers, which would be being produced well in advance of the fork, and purely as a for-profit enterprise based on expected demand for the fork.

If demand for the censorship resistant fork is high, but the government level attacker is still willing to outspend the miners, well then the problem is completely orthogonal to the issue of block sizes.

And just to be clear, all of this matters only after 1) all governments across the world have successfully colluded to eradicate all non-hidden, censorship-resisting mining pools everywhere, and 2) mining pools aren't able to find any technical means to hide the location(s) of their machines, despite the funding available from parties (good and bad) with financial interest in resisting censorship.

Not to mention there are other, non-technical, ways to deanonymize miners: "Just register with us, the government, to collect your mining subsidy."

Excellent.  I think it's important for the small blocks crowd to enumerate these hypothetical difficulties then, so they can be addressed.  Were you convinced by my response to the one you already brought up?

So announce the PoW algorithm switch/reimplementation of the block size limit well in advance, giving ASIC manufacturers enough time to get their chips widely distributed.  New alt-coins haven't been able to survive 51% attacks because they've been worthless, and therefore don't command a significant enough mining force.  It can be assumed that this Bitcoin fork would not be worthless. and would thus command a significant mining force.

I'm curious though, suppose all of the reasonable hypothetical difficulties with reimplementing a block size limit could be addressed, would you then switch sides in this argument?

Transaction hashes are 32 bytes, but even only the first few bytes are enough to identify the tx in the mempool.  So it's actually about two orders of magnitude less data than sending full txs.

The first step that I'm skeptical of is where an issuer issues colored coins and promises to redeem them on demand, but without tracking the identities of their owners as ownership changes via the blockchain.  Wouldn't regulators argue that colored coin issuers are legally required to do this?  Aren't they otherwise essentially issuing bearer bonds, which seem to be de facto illegal now?  The functional similarities between such an issuer and, say, Liberty Reserve are somewhat discomforting.

Also, it seems by your logic that the only thing protecting the OT token issuers themselves from falling under regulation is potential anonymity provided by the blockchain's obfuscation of the colored coin owners.  But the above argument seems to suggest that the OT token issuer's identity must be known by the colored coin issuer for them to remain in compliance with regulation, and so the OT token issuer isn't "entirely divorced" from the colored coin issuer at all.

Um...  These attack blocks would be received on non-anonymous connections, as this behavior is indistinguishable from a non-mining node's.  Only sending has to be done via an anonymous connection, and as you mentioned earlier, this can be done quite efficiently (I thought transactions were more like 500 bytes, giving a 15x boost to scalability, but whatever.  Actually, as Mike Hearn mentioned somewhere on the forum before, only the first few bytes of transaction hashes actually need to be sent, so this boost can actually be quite a lot larger.).

Unless you mean the anonymous miner's non-anonymized bandwidth is likely smaller than a non-anonymous miner's, since the latter can use an efficient data center.  In which case, how much extra on-demand bandwidth beyond the usual steady transaction flow are you estimating is necessary to thwart these attack blocks?  Is this amount of bandwidth really only available to people who are willing to give up physical control of their machines?  Don't you think that any extra cost due to lowered economic efficiency might be externally funded by parties interested in preventing censorship?

Actually it seems pretty clear already how this can be done.  Some of us have been thinking ahead  Here's a good summary of it by gmaxwell: https://bitcointalk.org/index.php?topic=137933.msg1596626#msg1596626  Follow the thread/links back for more details.

One further improvement on this proposal is for nodes to partially verify blocks in order to make the block auditing more decentralized.

I'm not following why Tor is an issue at all in this proposed attack, since they're receiving all incoming data without Tor, at the same speed as non-Tor miners.  I'm really sorry if I'm just being thick here.

I certainly don't assume they would.  But mining pools are a dime a dozen, and it's not really a big deal if a jurisdiction turns unfriendly and takes one or two out, as miners can seamlessly migrate to another pool in a friendly jurisdiction.  Engineering for the scenario that all jurisdictions across the planet have become unfriendly toward Bitcoin is kind of silly IMHO.

I can't see why it matters if an evil miner fills his blocks with transactions that he hasn't relayed.  It doesn't put the Tor miner at any relative disadvantage, as he's still safe receiving the block data without Tor, correct?  Am I missing something here, retep?

If anyone's interested in the anonymous mining issue, here's an informative exchange found in this thread: https://bitcointalk.org/index.php?topic=157141.0

Personally, I'm fine with a situation where miners anonymously connect to pools that migrate to friendly jurisdictions, but that's just me.  And that's only the worst case scenario if the assumption that Tor can't scale is correct, which I've seen no argument for.  Perhaps retep or jdillon could explain this assumption here?

Whether it's expected to be short-term profitable to enforce the soft limit, or try to break it depends on the fraction of total mining power enforcing the limit, the extra fees earned by breaking it, and the amount of external subsidies and which side these subsidies favor.  But the long-term interests of miners are also very important, and they clearly favor miners on the side of enforcing the soft limit in order to protect against bloat and to prevent any race to the bottom in fees, both of which lower future profitability.

So if the soft limit is set too low, then miners will have a strong short-term incentive to "break the cartel" in order to earn some extra money, and if it's too high, their longer-term interests will kick in in order to raise future profitability.  A balance would almost certainly be struck between these competing interests.

I think you're misunderstanding the difference between the current hard limit, and the proposed soft limit.  A hard limit is where every node, mining or not, rejects a block for being oversized.  A soft limit is where miners converge on an appropriate limit amongst themselves, and non-mining nodes are fine with it being broken.  A soft limit is relatively easily changed, only requiring a large fraction of miners be on board, but a hard limit requires the entire network to switch in unison.  Much more difficult.

Miners can prevent these kinds of attacks with soft limits, i.e. collectively refusing to build upon blocks that are "too large".