The majority of the python code is "classic Joric" address-from-user-passphrase generation, defaulting to a single round of SHA256 to coerce a passphrase into a key. It looks like the program itself wisely ignores all this and simply uses OpenSSL's random keygen functionality. So for example the function `generate` is 14 lines long but only the very last one is actually ever used, the rest is just there to compromise your security in case you call the function wrong.

No, the sequence number is a hint to miners; usually it is set to 255 (its maximum value). If not, you can sign a transaction where the signed input has sequence number 0, tweak it and increment to sequence number 1, tweak it again with sequence number 2, and so on. Each tweak requires a new signature, so the sequence number tells miners which of the conflicting transactions is the "real" one.

How useful this is, I don't know. You can't enforce miners respecting the sequence number, so any protocol depending on it can be trivially broken by colluding with miners. Maybe somebody will step in with a usecase, but I suspect this feature was not well-thought-out when it was introduced.

The ordering of inputs within a transaction is always fixed; if you reorder the inputs, then any non-SIGHASH_ANYONECANPAY inputs will need to be resigned.

Yes, except for the SIGHASH_ANYONECANPAY flag (which causes only one input to be signed), the sighash type does not affect which inputs are signed. In all cases, the current script is replaced by the scriptPubKey of the output it's spending, and the remaining scripts are blanked out.

An extra oddity is that in the SIGHASH_NONE and SIGHASH_SINGLE cases, the other inputs also have their sequence number blanked out.

Imagine you are a new user presented with two blockchains. The user cannot make any sense of the "response time patterns" encoded in them because the user is not in contact with any miners, she just sees a static blockchain. So she will select the one with the most work, just like today.

Now consider from the attacker's point of view. If the "honest miners" are using some mining method that requires communication for PoW (note that Bitcoin's proof of work does not require any such communication, it can be done totally offline, and is done offline --- mining hardware does not have network connections, they are devices where you give them a blockheader and they give you a nonce), while the attacker is simply making up response times to satisfy whatever rules you have added, then the attacker has a huge advantage and will be able to create a chain with much more work.

Can you explain why this is wrong? Can you also explain the incentive to honestly mine when you can get much more work per time from "dishonest" mining?

Why? I don't believe this is true period, and I definitely don't believe it is true when the delays needed to forge location are on the order of milliseconds.

For that matter, how does this timing translate into any sort of location data? How do you determine network weather conditions? How do you compensate for slowed links?

And you haven't touched the issue of public verification at all. Here is an easy first question: how do you define location for multiple observers? You cannot use relative distances, those are not well-defined. A less easy question is, how can you define location in a way that can be feasibly measured by participants long after the fact?

This is not a solution. This is magical thinking.


Again, a restatement of your earlier thoughts. It is not at all clear how to do this or whether it can be done.


Perhaps jl2012 has something specific in mind. But it is common sense that it is impossible to prove location in a decentralized way because the laws of physics do not admit a way to even measure it. (This is Mach's principle.) You would therefore have to localize to earth and attempt to prove location relative to earth. Well, the earth is an extremely noisy place and is occupied by attackers, so you would likely need to use some sort of proof of early knowledge of astronomical data...but now you require extremely specialized equipment to verify proofs, and all independent verifiers need to be collecting historical data for as long as they want to verify these proofs. So this is a no-go.


The problem is that you didn't give any answer as to why you think it's a workable solution, and it seems that you have a fundamental misunderstanding of what the problem is. It is not clear where this misunderstanding is, so the result is that communication becomes very difficult. I encourage you to develop a layman's understanding of relativity, and to spend some time studying cryptography to get a feel for what an argument for security needs to look like. The first such argument I read was Hash function requirements for Schnorr signatures, which operates in the absurdly-unrealistic "generic group model" but as I recall, is self-contained and the core argument is easy to follow. I'm not asking you to produce an academic cryptographic proof of your ideas (as I've indicated, I believe you can't because this problem is impossible), but to at least outline what your attack model is and how your system is secure under this model.

This is false. Key management is the job of wallet authors, and ordinary users do not need to be aware of them at all. The mapping between ECDSA keys and addresses is an implementation detail of the Bitcoin scripts used to support pay-to-address transactions, and should not affect decisions on the level of user behaviour. At the UI level, addresses are simply opaque payment identifiers. You use a new one for each payment you receive so that you can distinguish between them -- they are more akin to an invoice number than any sort of key. Reusing addresses is at best shoddy accounting, but likely indicates a deeper confusion about their semantic meaning.

And as others have said, address reuse is bad for the privacy of all users of the Bitcoin network, because it shrinks the set of ownership classes visible to an outside observer.


You absolutely need to rely on a wallet to manage your keys. Even if you are a professional cryptographer, Bitcoin requires the active use of dozens or hundreds of keys, which cannot be revealed or lost. Manually managing these is a recipe for disaster.

Addresses do not send funds. This is a dangerous misconception covered on the wiki.

Because Bitcoin needs a distributed consensus to function, and the only known way to achieve this is through proof of work. I've heard claims from parts of the Internet (as may have you) that you can use a proof-of-stake system to get a distributed consensus. As section six of my document on altcoins shows, this is fundamentally incorrect.

Let me just cut off this train wreck of a thread.

@cloverme The technical problems around storing users' money are by far the easiest --- getting the appropriate legal protection and authorization, security audits, accounting, backup/recovery, etc. systems in place are much much harder. But you seem to be struggling at a very fundamental level with the technical problems. These are also problems with traditional payment mechanisms, but Bitcoin makes them much more serious because it requires the programmer to deal in low-level cryptographic primitives, and its transfers are irreversible. So I implore you to not write code handling other peoples' money.

Managing multiple users by giving them each different wallets is not only a terrible idea from a scalability perspective, it does not make conceptual sense. The money you are holding is in your possession, and that means you need to track all of the keys material, track transactions, etc. Smearing this stuff across hundreds or thousands of files is insane.

Addresses are ephemeral: you generate a new one for each payment you intend to receive, and it identifies that specific payment. It is like an invoice number. Having one per user is also a conceptual confusion.

The correct way to do this involves a proper delegated key management setup (using BIP32, for example) designed and audited by experts in this field. It is possible to use bitcoind to manage keys, though this adds quite a bit of complexity to creating a secure system. The majority of your funds at all times should be "cold", as some other users are saying. This means that no network-connected system is in possession of cryptographic keys required to move them.

How could this be done?


Blockchains only do one thing: produce an ordering. They do not enable unforgeability.


I'm not sure what this means.


Proof of location shows up on #bitcoin and ##crypto every so often. There was a paper recently related to privately verifiable proof-of-location, but I can't seem to track it down. It's not clear to me that publically verifiable proof-of-location even makes sense --- "location" is not defined consistently and simultaneously for more than one observer!

That's not publically verifiable. As jl2012 observes it is not even privately verifiable because it is trivially forgeable (and definitely attacker controllable even if the actual miner is honest).

There is no way to prove past geographic location in a publically verifiable way. You definitely cannot prove geographic location of mining, which has variance on the order of minutes, since the earth is something like 100 milliseconds in circumference.

Hi Andrew,

In future it is better to create a new thread rather than resurrecting an old one, especially one as vivacious as this one.

As to the content of your article, I briefly skimmed it. A few comments -- your concerns about ASIC monopolies are largely addressed in my ASICs and Decentralization FAQ, and secondly, the "anti-monopoly" scheme by Sirer and Eyal is seriously and fundamentally broken by being progress-free. It seems to me that these authors are more concerned with promoting themselves with doomsday headlines than they are getting the fundamentals of what they write about correct, and it's best for the Bitcoin world if they not be given attention.

Andrew

This is a good idea. In the original coinjoin thread gmaxwell described a blinding scheme wherein users would initially provide their outputs in blinded form, have them blindsigned by the central server (or the "leader" node in a p2p setup) (or all participating parties, which is bandwidth-heavy), then reconnect anonymously to unblind them. For a p2p setup this means that somebody has to produce the blind signatures: either a leader must be selected, which adds complexity to the protocol, or every party signs every output, which leads to O(n^2) scaling.

With a ring signature on the other hand, each party would anonymously sign only their own outputs -- all nodes participate equally, with O(n) signatures. (Of course, the ring signatures are O(n) in size, so you might say this is still O(n^2) scaling. But since every signature uses the same keyring, this doesn't need to be passed around. Just the signature itself plus a blinding factor Q (one per signature, no need to use different ones per key in this case) as described in an earlier post.)

I did all of the writing but none of the ideas So I think it's fair to give gmaxwell all the credit.

Almost. If the signer actually threw away her q value, then yes. There is no way to enforce this. (But why wouldn't you? I dunno, depends on the context I guess..)

If you used the blinding scheme gmaxwell described above, all 1,000,000 could "admit" it wasn't them and nobody would be able to prove otherwise.

He cannot. As I have said twice now, it is not possible to do what he is asking.

Confirmation of valid transactions is always at the discretion of the miner. The dust output rules are part of the relay policy of most nodes, so it is difficult to transmit such a transaction to miners using the p2p network, but there is no reason you cannot contact them out of band.


How can you tell if there are problems or delays?

If you try refunding transactions given only the information available in your receiving transactions, you will be wrong a significant amount of the time. You cannot tell "the most common transactions" from others.