Got it, for some reason I was not seeing that the coin owner knows their (blinded) coin ID from the moment the coin is created, and thus can track the proof for where that coin belongs in the spent tree... or they could not do so and trust that they'll be able to find someone else who has when they need it. Makes sense.

Not so, there were quite a few serious flaws in it. We've fixed them over time and repaired the damage. OP_RETURN in a scriptSig originally let you spend anyone's coin— "No need to check the rules, let me by!"—  value overflow let anyone summon a billion bitcoins out of thin air, the hash tree second preimage let anyone pick a block and doom it on the network, lshift (and related bugs): corrupt the memory of and crash all the nodes, duplicate transaction IDs with inconsistent rewrites left the chain vulnerable to irreconcilable forks between old and newly bootstrapped nodes. I'm sure I'm missing quite a few other deep protocol issues, plus a litany of more conventional bugs, memory leaks, and (serious) performance shortcomings.

As impressive as Bitcoin was on its first day it was far from perfect— atypically reliable for such new and novel software, perhaps, but it had to be.  Regardless of  the original being the work of just one person or more than one it has taken many people to get it to what it is today.

No, it's not a good thing and I expect that Satoshi would have agreed that its not good. But it's the thing we can do. Bitcoin was already pushing the envelope of the kind of system that can be engineered (esp. when you start talking about making compatible alt. implementations) and at the time there was really no prospect of building a system that accomplished the goals without the public verification. It's not even completely clear yet if Bitcoin itself is fully viable, if transactions were a bit more expensive to store or validate, if the software was a bit more complex to author and maintain— perhaps Bitcoin would be a big mess of failure, perhaps it still will.

Only very recently has the very cutting edge of computer science and cryptography— e.g.  things like Groth's 2010 paper and Gennaro, Gentry, Parno, and Raykova's 2012 improved system— suggested that we could build succinct zero-knowledge argument systems with performance and space requirements not so far off from what Bitcoin uses today that we could even _consider_ the possibility of privacy stronger than Bitcoin's pseudo-anonymity in a zero-trust fully decentralized system.  And this is real rocket science stuff, layer after layer of idea that was only conceived of in the last decade or two, while Bitcoin can be pretty completely grasped— and trusted— by someone with a conventional, industry level, understanding of information technology... and could have been implemented with 1970s computer science (though not with acceptable performance on 1970s hardware— we're hardly keeping up as is).

Yes.

See also: "Vigorous debate" over Shamir/Ron's supposedly DPR-linked "Founder" ends in minutes.

Well, not really, he's what you get when you Google for that address.  He's still a user on the forum and we've had the "zomg you're in the early transactions" discussions with him before here: https://bitcointalk.org/index.php?topic=311328.msg3347186#msg3347186

They are referring to 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv: total received coin matches exactly to the numbers in the paper..

It doesn't even look like that at all, the "early adopter" coins in question are the ones sent to 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv.

Seems weird to me to assign that particular party to Satoshi: the earliest of the connected blocks was mined a week after Bitcoin's public announcement... and it aggregated up all that coin in a single address, in a pretty decidedly non-anonymous way.

What it looks like to me is that party sent a bunch of funds to an early exchange (perhaps Britcoin, based on the date), and presumably the at that point they changed ownership.

Again, I'm confused and disappointed. Like the first from these authors this paper seems really seems second rate, not well researched— even about the operations of Bitcoin, and rather high on soundbite-grade speculation compared to substance.

You may note that I'm responding to Maaku claiming that 1 confirm on λ=1/10  is as secure as 1 confirm on λ=1/600.

Depends on the threat that you're talking about. For example, the cost of a finney attack in the 10 second model is _much_ _much_ lower. If you're just taking about the accidental reorganization probability _and_ the network latency is negligible compared to both numbers (uh, wouldn't be for 10 seconds), then thats another matter.

Sounds a lot like the MMR stuff Peter Todd has been talking about, but I don't think it applies in the anonymous context.

In an anonymous system the unspent coins are blinded in some way or another and you use a proof to show that your spend is spending a coin from the set of unspent coins (without revealing which blind-unspent coin it was), and then that unblinded coin is put into a list to prevent spending it again.

Any way that avoids the storage problem by linking the spend to the particular unspent coin (e.g. removing it) isn't anonymous.

I know how to prevent it from growing forever though, but it trades off the anonymity set and the reliability of storage:. E.g. you have generations of unspent coins, and all unspent coins from a particular generation must be spent before a certain time. Once that time passes your spent list can also be purged.

At least in what Peter Todd's been thinking about there is an additional complication that when adjacent branches in this updating tree of unspent outputs you must update your proof... so it creates an interesting business opportunity for nodes that track the whole state in order to help offline spenders figure out the proof they need.

 

I'm not so sure about that.

Your (correct) KDF queries are generated from the password, and perhaps a salt.  Right?

We're assuming that the attacker somehow has your encrypted wallet key. He's trying to guess your password, and he's previously done KDF work for you.

The attacker guesses your password is "bob", now he generates the resulting KDF queries and sees that they match the work you asked him to do. He goes and simulates your full process, looks up his saved kdf results, and can now steal your coin.

The problem there is because the process is deterministic given your password and the wallet seed he can just regenerate the correct queries and ignore the chaff ones. (Unless you have a KDF which has some homomorphism that allows blinding, and I think thats both asking too much of implementors and escaping from the realm of memory hard KDFs that we'd prefer to use)

Wow! Theymos, thats awesome!

If it is using the 'type-2' public derivation, e.g. as is the case for all keys in a current armory wallet (IIRC), and the attacker knows the extended public key (e.g. attacker has a watching wallet) then yes.

This is why in BIP32 the recommended top level uses the 'type-1' private derivation which doesn't have this surprising property (but also lacks the nifty ability for a untrusted party to generate addresses for the wallet).

Worse, multibit just connects to whatever nodes are returned in a DNS query, which is easily spoofed.

If electrum really has multiple servers plus SSL authentication working now then I think its easily arguable that its security is strictly superior to multibit.

Some of the concerns about KDF costs could potentially work by making the KDF work delegatable.

Adam3us' blind puzzles are probably a bit too far rocket-science for this BIP, but simply restructuring the encryption like:

Key = HMAC(  KDF(HMAC(passphrase,salt)), passphrase||salt)

This would make it possible for a mobile device to ask a fast computer to do that KDF for it without completely losing all security.  Mike Caldwell had indicated that the ability to delegate was a shortcoming of BIP38 that he'd like to see addressed.

1/10th?

It's important to realize that if the rate blocks are being found is not a large multiple of how long it takes for a block to be propagated to and accepted by ~all of the network that the network will start suffering from convergence failures and see enormous reorgs. Even before the point where it would cause convergence failure a block time which is too fast relative to latencies would confer an an advantage to large hashpower consolidations (e.g. attackers).

Reducing the block size has some effect on propagation time, but it doesn't eliminate the effect of network latency.

More frequent blocks would also multiplicatively increase the header costs for SPV nodes. E.g. 10 years of headers would be 400MBytes for 1m blocks than 40MBytes.

... What do you think doing that will accomplish?  Having some ~no difficulty odd block won't contribute to the security, and could be found basically instantly. Worse, because they have no reward except in that they gate finding another block with a reward, fast mining consolidations would be incentivized to find them fast and keep them secret unless they find the next w/ reward block.

This really feels like development via oracle, where you fling poop at me until you find something I can't deflect.   If you want to try out random speculative ideas, why not create an altcoin? The market is a better oracle than I am.

Add txindex=1 to your bitcoin.conf, and restart bitcoin with -reindex.  It will rebuild your database with an index of all transactions. Adds about 1.4Gbytes of required storage.

But only if they have the same key. This is offtopic for this thread.

Sorry, you haven't stated a coherent proposal— e.g. how these "smaller blocks" fit into the consensus or any other specific details, so I can't really comment on it. All I could do is guess at what you actually meant, and I expect you'd then reply that I'd gotten my guesses wrong.

Generally ideas like this are unworkable because even if a block is very small it takes time to propagate around the network due to latency (e.g. the speed of light is finite). If the time between blocks is not a substantial multiple of the time it takes for a block to reach ~all the nodes then blocks will frequently be found faster than the network has heard about the prior ones and the consensus will fragment and there will be frequent large reorganizations. Such a state makes transactions unsafe until they have many confirmations and provides an advantage to large consolidations of hash-power (e.g. an attacker) because they're less diluted by forks.

When talking about sharding you have to figure out how to handle transactions that cross shards. E.g. if you have small inputs in one consensus and large ones in another, what happens when a transaction which is written that spends from both. If you mean to split by the transactions actual value, then you don't get any scaling gain from splitting because any transaction's input could come from either of the prior consensuses.

Beyond that, as others noted— what you're describing sounds like too much a departure from the rules of bitcoin to get adoption... and also discriminating against transactions by value is arguably undesirable: Thats behavior characteristic of the bad rent-seeking behavior of classic payment networks. If you charge lower fees per resource used based on txn value then someone who wanted to make trouble could split their coins into lots of tiny pieces and use disproportional resources.