Why don't you go do some testing and find out where it falls down?

Otherwise it's all just buzzwords: REDIS HAZ WEBSCALE!!!!

You might also try looking at the implementations which alreay have used postgresql...

those aren't relevant. Look for "Invalid".

Adam had a whole thread on encrypted transactions. Though without compact zero knoweldge proofs (like the stuff I discussed in the coinwitness thread) it's hard to make them not super brittle and inefficient, because anyone you pay has to receive and validate the whole decrypted history of a coin, since it can't be validated without the history.

If you had a zero knowledge proof that the transaction was valid (e.g. that all the outputs and inputs added up) which the network checked then you could accept the coin without re-verifying the history and, importantly, without revealing the history to the recipients. The trick is finding a system for zero knoweldge proofs which is powerful enough to prove the right things but fast and low bandwidth enough to actually use which doesn't have annoying limitations like requiring a trusted initialization.

There were several other additional limitations:

* Very slow to validate (e.g. on the order of 1-2 tx per second)
* Required a trusted party to initiate the accumulator, and if they violate that trust they could steal coins
* Uses cryptography which is less well studied
* Only handled anonymized coins with one value, reducing the anonymity set size substantially
* Didn't conceal values
* Spent coins list is needed for validation and grows forever (e.g. no pruning of the critical validation state).

Of these only the first two and the last are probably real barriers, the others are more "doesn't work as well as some hypothetical future system might".

There was no way within their prior system to achieve size reductions to the currently mentioned, I'd speculated in some other threads on some technology that could make the proofs smaller and faster, but if they've gone that route there may be some other consequences. It's hard to say much of anything useful without more information being made public.

I would note that the prior ZC implementation has been made available for some time now, and no altcoin has picked it up.

Yea, haven't heard back from him yet.  They also asked me for a shipping address but I haven't anything else.

In any case, I'm very hopeful. I'm very much of the power-efficiency-matters crowd, and look forward to seeing more aggressively power efficient hardware— fastest to market with no heed of power usage is not a good strategy for someone not mining for the long term.

hm. They're already being auctioned for Bitcoin without any third party validation?  Kinda sad.

Miners already do this. Some pools will even trigger longpolls to trigger miners to get work early if enough new txn come in (or at least eligius did in the past, I'm not sure if they still bother).

Can we get a couple of useful bits of data for someone to work on this:

* Earliest confirmed version of 10.8 with the problem
* A sample of a corrupted DB
* console logs from *during time of corruption* including dmesg and system.log
* Information on how bitcoin built/installed, clang? gcc42? macports/brew for deps?
* if the people experiencing the problem have filevault (FDE) turned on or not, whether it was turned on during the install or after, and if it's ever been cycled on/off
* also whether people who have hit this are using stock fs settings or if have case-sensitivity/etc turned on

The 0.01 thing is finally gone in GIT IIRC, as the thing it was trying to do was largely addressed by the anti-dust-output changes. And indeed, you can avoid the anti-dust-output rule exactly as you describe, and there is nothing wrong with that.  The point of the anti-dust-output rule is to discourage people from creating UTXO which cost more to spend (in terms of marginal fees) then they yield in coin and your little protocol achieves that fine.

The threshold is 1 mBTC: main.cpp:int64_t CTransaction::nMinTxFee = 10000;  // Override with -mintxfee

Prioritize by fee in the stock code, at least, is made robust against that kind of gamesmanship by treating any fee below a minimum threshold as zero for the purpose of prioritizing the transactions.

Normal transactions do this all the time (ignoring creating faux-anonymous output values), but today people assume common use means common ownership.  Part of the advantage of CoinJoin is that if widely used it breaks the ability to assume that, recovering some privacy for everyone.

the post shows ~60% are happy with it, ...

Joe can pay for his sandwich directly— this is one option, but not a requirement. Please review the initial post, this is covered in detail.

See also Eben's brilliant comments regarding privacy problems as an ecological disaster.

Presumably they're going to send out test/demo units to some people. I don't see anything in particular concerning here, certainly it makes sense to get some third party validation before making a purchase... but they're not asking you to purchase yet.

Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature. It's not the only thing, some websites will, electrum will, the SX tools will. But armory, nothing bitcoinj based, or blockchain.info will.

It's a real bummer because I think that using a multi-signature escrow is the right and proper thing to do here. I don't think I should personally be holding money set aside for this— my computer security is good, but I think no single person should be entrusted with holding non-trivial amounts of other folks money.  How many bitcoins have been stolen that could have been avoided if the norm was to use in blockchain escrows for things, but people didn't because of silly wallet compatibility?    (And perhaps people will understand that I'm really not being a rabid bitcoin-qt advocate when I say that I'm not super eager to see lots of alternative implementations, they really do complicate the ecosystem and make new features harder for people to use)  [/OT]

If you don't use tor (or another similar network) then the peers you're talking to could record your IP, which you presumably want to keep private too. I mostly pointed it out to head off comments like "OMG YOUR PEERS CAN RECORD YOUR IP!" ... yes, they can, other things fix that. This is intended to address privacy in the blockchain.

In general DSA is pretty lame— there are attacks on DSA with reduced computation compared to solving the DLP given multiple signatures with nonces that happen to have certain properties relative to each other. The cases where the attacks are made possible are themselves unlikely enough that its not a practical concern, but its not correct to say that ECDSA is as strong as ECDLP as far as we know. Instead we know its not, but not concerningly so.

(Schnorr signatures are better in almost any way you can pick— better security proofs, ability to do efficient multisignature, etc. but their creator patented them and so pretty much no one has used them except academics.)

I don't consider increased cryptographic risk from pubkey reuse or disclosure of the pubkey (keep in mind: until you spend using a key the first time the public doesn't even know the EC pubkey you're using, they know its hash!) against real, hypothetical, or quantum attacks to be a major consideration. ... but I suppose you could say that it's just one more reason to not reuse addresses.

Weird choices. No exclusive ranges? (E.g. almost everyone could pick <100%), no 100%, no granularity between 48 and 100?.

Why not:
[0 - 0.5)
[0.5 - 1)
[1 - 2)
[2 - 4)
[4 - 8)
[8 - 16)
[16 - 30)
[30 - 40)
[40 - 50)
[50 - 60)
[60 - 80)
[80 - 100)
Is anyone really bothering to figure out their percentage of their net worth for assets that constitute less than 1% though? Who cares about precision with tiny amounts?