That's a good goal but it's plain that bitcoin was not designed to support the use of mobile wallets.

For instance, imagine you have your mobile wallet and you're at the merchant who has internet access and a bitcoin client.
You transfer your bitcoins to the merchant.
The merchant's client does its own verification of the transaction and then sends it through the network.
Now the merchant can either ask some large miners whether it's on the transaction list going to be hashed into the next block or wait for the next block.
Suppose you're standing there with no internet connection and the merchant says to you "Erm... The miners are not confirming recipt and your transaction wasn't hashed into the last block." What are you going to do?
In one case, the merchant is lying and has taken your money and doesn't want to give you the goods.
On the other hand, you think the merchant thinks that you've just arranged with an accomplice to already spend those coins and the merchant's transaction is being rejected as a double spend.
Without an independent connection that is at least disinterested, even if it's not secure there's nothing you can really do.
Also, standing there waiting for blocks to confirm is not ideal. A better system would facilitate more reliable prompt confirmations of transactions.

ByteCoin

So everyone following the message stream can see to whom messages are being sent but they can't read the messages.
You should have the option to keep the addressee private. All client software attached to the messaging stream would have to speculatively decrypt "private addressee" messages and if the decryption did not yield a valid message then the result is discarded. If the message is valid then you know you were the intended recipient and you display the message.


More generally, if an address has ever spent any coins to anyone then the public key is recorded in the block chain for all to see.

ByteCoin

Grue: I'm not seeing the relevance of the link in your post. It doesn't seem similar at all.

The point rand0mmm is making is that someone hearing about bitcoin, downloading and running the software and then wanting to transfer or buy something with bitcoins has to jump through lots of hoops to get them. The way I'd get bitcoins now is by signing up for an account on mtgox or some similar site and then going through the process of transferring money etc.

Presumably rand0mmm would like a little tab in the client saying "Add bitcoins" which would ask for credit card details or something similar so he could purchase some bitcoins using dollars or whatever his local currency is.

It's a far cry from what the client does at the moment but, if you see it through a beginner's eyes, it's a perfectly reasonable expectation from a "proper" application.

In the olden days you could just click on generate coins but with the proof of work so suitable for GPU mining, you might as well remove it.

Of course, the alternative would be to have a proof of work that was more suitable for CPUs. Something more memory intensive and possibly useful see http://bitcointalk.org/index.php?topic=203.msg3669#msg3669 and the rest of the thread for details. The target could be that half the proofs of work are just hashing and half are useful computations more suited to CPUs with memory.
GPU miners would shout and scream about losing their monopoly but I think the result would be a healthy re-engagement of the CPU owning community. Also, the "generate coins" button would start to do something again!

ByteCoin

Ok so you look at the TxIns of the transaction which contains the PrevOut of the transactions you're checking. You can therefore send a "getdata" with the hashes to get the actual transaction, but that's not sufficient. You need to be able to find out which block that (or those) transactions was hashed into so you can download it and check the merkle tree and link it to the block chain headers. I'm not sure what queries you'd have to send to find out which block a transaction was hashed into. Is it even possible at the moment?

I don't think there's a way to prove that the inputs haven't already been spent without essentially downloading the entire block chain subsequent to the block that contained the inputs and verifying that the inputs aren't used in any transactions. Even if a new query was created, there's no obvious way for your lightweight client to check it's not being lied to.

If I'm mistaken in any of the above, please correct my reasoning.

Of course with my "balance sheets proposal" you get the assurance that your inputs haven't been spent as soon as you download the relevant branch of the balance sheet tree and verify its hash in the block chain.

ByteCoin

Perhaps I did it wrong but I think most of it ended up here https://blockexplorer.com/address/1NgLdBTSYqnqwqiD2JioPRfqEkm3Zvs32u

ByteCoin

Since the prohibition on non-standard transactions, the only reason for a transaction to be overly "complex" is due to its large number of inputs and outputs.

In this case the solution is for the client software to offer the option of  recasting the transaction into two or more less complex ones, possibly using staging addresses, which would no longer incur fees.

ByteCoin

A better global metric of transaction volume would be the number of bitcoindays destroyed.

I believe that transactions are prioritized according to the value of the transaction multiplied by the amount of time since the coins were spent. A similar concept is useful in measuring the transaction volume.

If someone has 100BTC that they received a week ago and they spend it then 700 bitcoin days have been destroyed. If they take those 100BTC and send them to several addresses and then spend them then although the total transaction volume could be arbitrarily large the number of bitcoindays destroyed is still 700.

Currently, bitcoindays are replenished at around six million bitcoindays per day which reflects that there are about six million bitcoins in existence.

If there are days when there are few transactions then the total number of bitcoindays increases dramatically. If everyone exchanged all their bitcoins at once then the total number of bitcoindays would be reduced to zero. Some bitcoins will never be spent because the private keys have been lost (or never existed) so the number of bitcoindays will never actually fall to zero.

Note how transaction flooding and mix-network activity do not significantly influence the number of bitcoindays destroyed. I believe that the bitcoindays measure is a good indicator of market health and participation.

ByteCoin

It's probably not impossible, it's very likely to be very unlikely. So for example the address 1111111111111111111114oLvT2 has a hash160 of 0 and a balance of 0.02 bitcoins. It's likely that about 79,228 million million million million different public keys have this hash.
If you were to keep generating public keys at random or by exhaustive search you just have to find just one of those 79,228 million million million million that hashes to 0 then you can claim the money.
It is possible that no public key would have a hash160 of 0 in which case spending the money is impossible. It is very unlikely however.

ByteCoin 

I'd just like to point out that there are ways of transferring coins completely anonymously without having to trust a third party and without changing the protocol or network. The client software would have to be changed to support it though.

See the technical details at http://bitcointalk.org/index.php?topic=5965

If you're interested in transactions not being traceable it's best to rely on a cryptographic solution rather than a human or business.

ByteCoin

Using the notation in the ECDSA wikipedia article http://en.wikipedia.org/wiki/ECDSA
An ECDSA signature is (r,s).
When verifying the signature, one of the first things calculated is the modular inverse of "s" and "s" is not otherwise used.
Since the signature is generated once and verified thousands of times (at least once by each client) , why isn't the signature (r, inverse(s)) instead?

This would save one inversion per verification.
On the signing side, if you look at the way s is calculated, inverse(s) could be calculated just as quickly. Instead of inverting the random k parameter you'd invert z+rd

Is there something I'm missing? Did they really just overlook this?

ByteCoin

There are two distinct issues being discussed here:
The original article discusses a fork caused by a substantial fraction of the network suddenly adopting an incompatible set of rules.
The recent observation is that a relatively small number of miners control a large fraction of the hashing power and could plausibly form a cartel.
Both are worth discussing in their own right but the share little commonality.

I believe that both problems would leave clear evidence on aggregate although the fault in individual instances could probably not be decided. There seems to be no evidence to suggest that either is a problem at the moment.

The success or failure of a rule-change bitcoin fork will be determined by similar factors as the success/failure of an open-source software fork as similar pressures operate. The fork has to be adopted and the new code base must be maintained. A lack of adoption causes a lack of incentive to maintain and develop the code. Eventually, one or other version has fewer bugs, is easier to use, has better features or becomes a standard for some other reason unrelated to its quality.

On the topic of mining cartels: I believe that as the value of bitcoin rises and the ability to quickly convert bitcoins into cash improves, the incentive to develop the programming and organizational infrastructure to enable mining cartels will become hard to resist.
Much of the essential infrastructure development could be rationalized by the major miners in positive terms as an improvement to the stability and robustness of the network. A similar development has occurred in the conventional banking/financial sector over the last hundred years or so.
 
ByteCoin

Such people would be candidates for "shunning".

http://bitcointalk.org/index.php?topic=3441.msg50075#msg50075

In the same way that the consensus is to reward miners with 50BTC (at the moment) per block, we could form a consensus that bitcoins used in such flooding attacks could be invalidated. Dangerous ground but the concept needs to be explored!

ByteCoin

When a lightweight client asks for the block containing transaction it need only be told the header and enough of the merkle tree to verify that the transaction belongs in the block. I imagine that at the moment with relatively low numbers of transactions per block the bandwidth savings of not sending all the transactions in the block will be low.

Detecting payments to yourself could be done by passing a request for all transactions crediting a given address. I can't think of a way that lightweight clients could do this without essentially revealing their receiving addresses.

Of course with my "balance sheet" proposal, the amount of information clients have to download to start from "cold" is minimized and a good amount of anonymity is preserved - but this would be a breaking change.

ByteCoin

There is a problem with bitcoin because transactions are, to a certain extent, traceable. Also, it seems to be desirable to be able to pass messages between sender and recipient. This post outlines a simple method of implementing untraceable transactions to which either party can attach messages. This type of transaction will be propagated across the network and incorporated into blocks just like a normal transaction because to all observers (except the sender and intended recipient) it is indistinguishable from a normal transaction. It's not immediately obvious that Bitcoin could easily be altered to prevent this new type of transaction if the consensus was that it was undesirable.

Prerequisite: The recipient's address needs to have a publicly visible public key or alternatively the sender needs to have independent knowledge of the public key. In normal circumstances, this means that the recipient needs to have spent some of the coins sent to that address whereupon their public key is in the block chain.

Step 1: The sender performs his side of a Diffie–Hellman key exchange by multiplying the recipient's public key by his private key.

Step 2: The sender uses the hash of the resulting point as the secret key to generate another address termed the "transfer" address.

Step 3: The sender sends the bitcoins to the transfer address (plus multiples of 0.01BTC if message transmission in step 4 is desired).

Step 4: If a message transmission to the recipient is desired, the sender prepares one or more message bearing "k" values instead of random numbers. The messages m is encrypted (xor will do) with the hash of the concatenation of the secret key for the transfer address with a sequence number starting with zero. The resulting k values are used by the sender for the transfer of 0.01BTC from the transfer address to some  other addresses until the message is complete.

Step 5: The recipient monitors the network or block chain for public key revelations ie the first spend from a new address. When a new public key is detected the recipient multiplies the public key point by their secret keys for their public receiving addresses.

Step 6: The recipient uses the hashes of the resulting points as the secret keys to generate candidate transfer addresses and monitors the block chain for transactions to these addresses.

Step 7: The recipient notices that the transaction crediting the "transfer" address matches the one of the addresses calculated in step 6

Step 8: If there are any transactions from the transfer address, the recipient hashes the secret key with a trial sequence number and decrypts the "random" k parameter to recover the message.

Step 9: As both the recipient and the sender know the secret key to the transfer address, the recipient takes ownership of the coins if they wish to by transferring them (possibly in combination with other coins) to one or more new addresses. The recipient can attach a number of messages readable by the sender to these transactions using the methods of step 4.

The recipient and sender can use the transfer address indefinitely and symmetrically to transfer bitcoins and secure messages back and forth forever as they wish. The sequence numbers are incremented to ensure that k values remain distinct and remain indistinguishable to third parties from random numbers even if identical secret messages are transmitted.

Advantages: The transactions are not traceable as they transfer control of bitcoins without crediting the recipient's published receiving address. They look like normal transactions. Transfer addresses facilitate message passing in the k values of transfer signatures.

Disadvantage: Disputes between sender and recipient cannot be resolved by third parties using the block chain evidence. This is the price of this type of untraceability.

ByteCoin
 

Correct. This is the implementation detail I mentioned. One would have to ensure that the public key had never been seen before so that only its hash and not the full public key would be visible.

To prevent precomputation, the 192 (or whatever) bits the user is not expected to type in should not be constant but should be derived from a hash of the user specified bits. I believe the implementation  by jgarzik already handles this.

The man-in-the-middle type attack Hal mentions on redeeming the voucher seems very costly and unreliable for the attacker.

ByteCoin

It's not immediately obvious to me that this is possible. Please go into details about how it would be done.

ByteCoin

As very nearly every 256bit number is a valid secp256k1 private key, there's no reason to imagine (off the top of my head) why there should be any attack faster than brute force.

Note to self: I have thought of a possible implementation detail that would need to be taken care of in order to stop a birthday paradox attack. Details when I have time.

ByteCoin

If this were easy then surely Satoshi would have implemented it from the start; after all the address is one step removed from the public key presumably to prevent offline attacks trying to find the private key. It seems like you're looking to be another step removed. Is there much point?

ByteCoin

Thanks for bearing this useful fact in mind.

Another thing to consider, once any coins associated with an address have ever been spent then the public keys associated with that address are public by virtue of the signature in the transaction. If the merchant's public key is available in this fashion then the customer and merchant can generate a shared secret using Diffie-Hellman key agreement or some similar scheme. This shared secret could be used as the "authentication key" mentioned in the wikipedia article.

Of course, if you're thinking of now enabling currently forbidden scripting features then a lot of options become available.

ByteCoin

You CAN encode a message in a currently accepted transaction using the broadband subliminal channel inherent to DSA (and ECDSA).

It would require patching the code to include the message but it could be extracted by some maths on the data displayed by Bitcoin Block Explorer or by extracting it from the block chain file.


ByteCoin