I'm sure your english is much better than my ability to speak whatever language that you're native in, but I still can't understand your question.

Perhaps you could also try google translate?

None of that list of things actually do anything to address whats the payment protocol is doing.  x.509 is used to provide non-repudiation. The merchant tells you to pay 5 BTC to scriptpubkey X and they'll send you 10 widgets.  If the merchant scams you, you can show other people the signed invoice to convince them that the merchant really did make that agreement.  This means that none of the authentication for ephemeral keying things are actually useful (e.g. every one of your bulleted "alternatives"), nor is "have to trust the merchant not to scam you".

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Do take care there, it's not the right comparison.  _Generally_ more CAs == more vulnerable because any CA can author a cert for any domain.

The greater point is that the payment protocol, while it can use x.509 doesn't have security that turns totally brittle even if the CA infrastructure misbehaves.

I'd like to see better support for non-SSL CA stuff, but the options are pretty limited. Doing other things, however, is not mutually exclusive with also supporting x.509.

Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.

Case in point.
Yes, as I said, this subforum is generally lower in nonsense than the rest of the forum.

Again, please feel free to state concerns, but if you regularly cannot manage to do so in a polite, adult manner I'm going to have to ask you to leave.

Back to the thread subject, the limitations of the CA infrastructure have been extensively discussed both in this very thread and in the older bitcoin-development thread. I agree that the CA infrastructure is lame, but the world doesn't really have any good PKIs.

Fortunately, the way the payment protocol is designed the CA infrastructure being potentially weak isn't all that critical, as payment messages can be sent directly between buyers and sellers over whatever secure channel they already have. An evil CA cannot do as ShadowOfHarbringer suggests, it cannot prevent people from transacting with each other even inside the payment protocol (of course, the option of just not using it would work too), nor can it produce completely undetectable forgeries, nor could it impersonate anyone _at all_ unless it could already impersonate your secure communications channel. As far as I know the x.509 support does in the payment protocol is create a non-reputable signature for invoices for messages which you would be sending over a secure channel anyways.

If a community of users (now or in the future) prefers to send their payment messages with external PGP signing— because they don't even trust the CA infrastructure for non-repudiation—, they can do that instead of or in addition to the x.509 key signing.

Your incivility is going to scare off the actual technical people from responding on this forum. Already several of them don't, which I think is sad... relatively to the rest of the forum the technical sub-forum is mostly low rubbish.

Treating other people poorly has the effect of silencing their opinions here. It's possible to state just about any opinion without being excessively rude about it, but it seems is nearly impossible there to continue a conversation with some forum members while retaining a bit of human dignity.

Most of us are unpaid volunteers. Nothing I do with development makes me rich. This kind of ignorance just multiplies the offensiveness of your misplaced attacks.

FWIW, I didn't notice the attacks in this thread until someone reported-to-mod them because I had both Gweedo and ShadowOfHarbringer on ignore (though I've been considering removing the latter one lately). I strongly recommend everyone else use ignore aggressively, it can actually be pretty effective.  Even though I do ultimately end up clicking on much of what I've ignored, I find the extra clickthrough to be a good reminder that I've already written that poster's opinions off, and that I expect them to say some hurtful uninformed nonsense. It's less shocking when I find what I expect.

This is a duplicate of a recent thread, and wasn't news. In the future, please take a moment to search before starting a new thread.

In practice there is a pretty substantial difference between software which is manually updated by users and software where the normal practice is to invisibly download new code at every execution. There is still the issue of additional code. E.g. XSS on blockchain.info's explorer service (which there have been several easily exploitable ones) has no parallel risk in multibit or electrum.

There is also the issue of the centralized service receiving an encrypted copy of the wallet (usually encrypted with some weak user selected key) which also doesn't exist for multibit/electrum. There are fast (e.g. >1 million attempts per second) gpu crackers for bc.i wallets...  So the user of a cryptographically strong passphrase is another conditional.

I call shenanigans on this. The site can replace the JS at any time, in theory you could do some extension js pinning stuff, but the code I've seen only verifies that a couple scripts are the same as in git.  Pinning particular scripts does not prevent _additional_ scripts from changing the state, and I don't believe the pinning is widely used in any case.

You might be happy with what it provides, but I think its not unfair to say that it is categorically weaker than Electrum/Multibit/etc.

All of the reduced storage clients listed in these thread use a reduced security model where the wallet itself does not validate network rules (such as honest spending, or no unpermitted inflation) and instead trust their peers to do it for them (or in the case of Electrum a user selected server). Thin clients are also somewhat more vulnerable to being tricked by fake deposits (an issue exacerbated by the fact that most (all?) show a single confirmation as "confirmed"). There is also a privacy tradeoff, as all the thin clients send address lists or bloom filters to the systems serving them to indicate which transactions they are interested in...

AFAIK there is currently no software that gives equivalent security of all kinds to bitcoin-qt that has reduced storage requirements, but it's possible to do so (and bitcoin-qt will in the future).

No doubt the perpetrators of this "attack" can expect much riches. I recommend they commence immediately.

Wow, I'd just assumed that was a typo, not that you actually thought that. An index of all addresses is only about 1.5GB of additional data if efficiently stored.

If you're just cramming the whole blockchain into some off the shelf SQL database, then yea— 100GBytes wouldn't be surprising at all.

Keys resulting from BIP32 must always be compressed, it's part of the specification.

That "Hash:" line is part of the pgp signature. The file is called SHASUMS and not SHA256SUMS because it's sha1.

(Incidentally, those files are old and are likely only of historical interest)

In the centeralized world we have central banks that regulate inflation to keep prices stable.

Encrypting values sounds interesting, if the overhead is very low.  But perhaps of limited value, since disclosing an amount must disclose the whole transaction history.  I also don't see how you can pay a transaction fee (which requires making one output a public value, so the miner knows how much fee he got!) without disclosing the encryption key for the whole transaction.

If you traverse the history of a random transaction on the network you'll find that many of them are rapidly internlinked with hundreds of thousands of transactions. Even using a penny from one graph would end up disclosing the whole history's values. This would make the privacy very brittle. It can be argued that brittle privacy is worse for people than none.

If the scheme supported a way to 'emerge' a coin and make its value public without disclosing the history, even if this mechanism were fairly costly (e.g. a moderately big zero knoweldge proof) then that would be a way to infrequently break up the history without disclosing it, and this would perhaps be more useful. E.g. every once in a while you'd perform a transaction that makes the values public and provides a proof that the values are correct, but doesn't disclose the history.

There is a tool to do basically this, but even better: it ships them off to a server where they are coinjoined up in a single transaction, thus confusing simplistic taint analysis.

https://github.com/petertodd/dust-b-gone/

Everyone with dust in their wallet should use it— even if you don't care about your own privacy, giving up your dust inputs is good for the network and improves other people's privacy.

The algorithm is randomized and I'm not aware of any way to easily control when a coin gets used except by making it exactly the right unusual value.

E.g. you send the person 1.123456  and then get them to pay 1.123456 and it is very likely that they'll use the intended coin, though in that case there wouldn't be any other inputs.

Not that privacy attacks with dust aren't a concern, but it's isn't quite as trivial as being able to control when the coins are used directly.

A problem here is that any "factoring in" is just a guess. It's been increasing lately as there has been a series of hardware makers successfully shipping. Maybe it continues like a rocket. Maybe it doesn't.  The current rate of growth cannot continue forever though, or otherwise we will soon need to start converting the mass of the sun into energy to power the miners.

See the thread. The transaction was already in his wallet (thats what the gettransaction checks for), which wouldn't have been possible if a duplicate address had just been generated.  We don't know what exactly happened but there are several other hypothesis which are more consistent with the facts than there being an actual duplicate address generated.

E.g. a unclean wallet shutdown made it miss flagging that address as used, thus resulting in it handing it out again, or a mouse mis-targeting resulted in the OP generating an address but then copying another.

Also, now that the newly received coin has been spent we can see that both the new instance and old instance used the same public key (03a97dfbd26061494c9369cd469f8422f7c5f16e4fd6b4da42e42138e711f7fd6f), which means that it's 256 bits involved, not just 160. (E.g. if your hypothesis was a chance collision the probability of that is now 79,228,162,514,264,337,593,543,950,336 times lower than before we knew for sure that he was using the same public keys).

A collision didn't happen here, I'd stake my life on it gladly.  With respect to a bad PRNG, things are possible, but the code in Bitcoin-qt has been audited by many people (including myself personally) and that seems unlikely (also, if it were to happen, considering the design I would expect consecutive duplicate addresses and not just one).

"Just needing to downgrade" would have meant erasing the blockchain database because their 0.8 installs were not compatible (different database formats), which would have meant being offline for a long time to sync back up. Instead, at least in the initial repair they fixed by directly hard coding a different block or by blacklistingthe one on the 0.8-only fork.

Thats not the right way to ask someone to do that, the right way would be to ask them to perform a signmessage (file->signmessage plug in the address, and "this is alikim on bitcointalk", and post the signature and the exact message used). But I don't see any reason to doubt that this address is the OPs. I suspect you have your local timezone set in the forum, his post appears to be >10 minutes after the transaction to me.

Why was this moved back out of the technical support area?  Is the purpose of this thread to spread (apparent misplaced, see my prior posts) concerns or is it actually to figure out whats up technically?