The to address 13sUHUW8G23BLQEKFwVMf5cKUkiSuFK8XC seems to be occurring at a rate of about 2 per minute. This increases the size of the block chain at a rate of at least 256MB per year.

One partial solution which would have few adverse repercussions on legitimate transactions would be for clients only to relay transactions which refer to previous transactions which have been incorporated in a block.

ByteCoin 

Please provide either examples or at least a plausible argument for the existence of valid addresses shorter than 27 characters or longer than 34 characters. I've corrected you on this before http://bitcointalk.org/index.php?topic=1019.msg12683#msg12683

ByteCoin

Surely you're mistaken about how nLockTime transactions work. I believe that they are included in the next block just like normal transactions and any transactions which supersede it would be included in the blocks following them. Why else would there be a nLockTime field in every transaction in every block? The way you have it, there'd be no point recording the lock time in the blocks because the transaction would only be in the block once it's locked.

nLockTime as you explain it is an ugly solution. It creates the need for a parallel store of transactions that are neither in blocks nor eligible to be included in the next block. When a new miner starts up, how does he find out about nLockTime transactions which have been sent but haven't been locked? An extension to the network protocol would have to be made.

ByteCoin

I think realnowhereman's suggestions for improvement are excellent and comprehensive.

The only point I disagree with is that the fundamental unit of currency being "tens of nanocoins" is fine. I find it very surprising that so many people have trouble with converting between a decimal representation of a number of bitcoin and the number of fundamental units.
The mathematics is so elementary.

I'd like to add a suggestion that we revamp the Hash160ToAddress via the Base58Encoding so that leading zeros are not handled in the current peculiar fashion. It's hard to approve of a function that takes a fixed length input and outputs a more human friendly "address" which can vary in length between 27 characters and 34 characters inclusive.
are both valid addresses. It makes the first step of address verification on websites vastly more complex than it needs to be.


There's nothing stopping you downloading the chain in reverse one by one when you get notified of a new block. Your software could also store the chain in reverse and process it with no increased difficulty. There should be support in the network protocol for clients efficiently downloading the chain in reverse. As well as "start height", "version" could return the hash of the last received block to facilitate downloading most recent blocks first.

Not downloading and in fact discarding and forgetting old blocks is of course a central feature of my "balance sheets" proposal.

ByteCoin

PS
That's just a programming problem, you keep track of the unresolved dependencies and check them when you've worked back enough blocks.

That's a reality we already live with. There's little point verifying the block chain before block 105000 due to the "checkpointing" in the current (0.3.20.2) version of bitcoin (see main.cpp).

I must admit that I don't know anything significant about nLockTime. I will make a point of learning when it gets implemented or enabled.
In my advocacy for OP_BLOCKNUMBER I wanted to enable the recovery of bitcoins for which the private key had been lost. Suppose for example that you've sent payment to a merchant and their hard disk dies and renders their wallet unreadable. If you had engineered your transaction using OP_BLOCKNUMBER such that, if the payment is not spent within a month then the coins revert back then you have only lost the coins for one month. 

Can this be done with nLockTime while remaining secure for sender and recipient?

ByteCoin

I believe that transactions are verified when they are received before they are relayed. When a block is received, all the transactions in it are also checked before the block is relayed even though most of the transactions in the block have already been verified in the process of relaying them to the miner.

ByteCoin

I'm willing to evaluate the feasibility of proposed schemes if they are specified in sufficient detail. Your proposal is substantially different from bitcoin and the information you provide is not sufficient to provide a clear understanding of how it would work.

ByteCoin

(Assuming that signmessage were to use a single SHA256 pass)

When you spend coins by signing transactions, don't you sign a double SHA256 hash of the transaction? I'm looking at SignatureHash in script.cpp and Hash in util.h. So if an attacker passes to signmessage a single SHA256 hash of a valid transaction payload then the attacker can spend the signer's coins. The signer couldn't possibly work out what the effect of signing the attacker's message might be, without reversing SHA256. This is possibly the first cryptographic disadvantage of the double hashing scheme employed in bitcoin.

Also, in other applications it's common to form a contract by signing a hash of a message rather than a (short) message.

To avoid all these possible problems, you have to approve of the content you sign.

ByteCoin

PS Yes you could paper over the problem by making signmessage use a different hash function or prepend some idiosyncratic but standardized padding to the message before hashing or use >2 rounds of SHA256.

They wouldn't have to break RIPEMD160. If they broke SHA256 suitably they could create blocks of arbitrarily high difficulty with very little effort which would enable them to take control of the block chain.
When you send your transaction to spend the coins, you reveal your public key for which they would then solve the discrete logarithm problem to find your secret key. They would ensure that your transaction was never included in a block but their transaction spending your money could confirm very quickly.
I suppose that if you never try to spend the money, they can't steal it directly but they could inflate the value away.

ByteCoin

It's reasonable to expect that for a specially crafted message to somehow reveal the private key upon signing, one would have to be able to find messages that hash to particular values. This would constitute the worst possible failure of the relevant hash function.
Even if the hash function were completely broken as above, there is no method currently known that allows the recovery of the private key from a signed message faster than solving the discrete logarithm problem on the relevant elliptic curve. If one were to be found, it would constitute a very severe weakness in DSA and ECDSA.

If an attacker can force you to sign arbitrary messages, that's certainly a security flaw. The solution is to take good care that you approve of whatever content you are thinking of signing whether it be cheques, loan agreements, wills or numbers.

ByteCoin

There is some extra CPU cost certainly. If the goal is to reduce the CPU cost of transaction processing then there are other low-hanging fruit to pick beforehand.

• Change the software so that not all clients have to check all signatures. This was raised in http://bitcointalk.org/index.php?topic=6373.msg94314#msg94314 in the context of speeding transaction propagation.
• Use a smaller curve - 256 bits is very conservative
• Use a different group with faster operations like curve25519
• Remove the incentive for generating lots of transactions

Not recording the public key in the scriptSig would be a breaking change and so there are many other improvements we could apply at the same time.

ByteCoin

Although you may hear that the 10 minute average block generation time was calculated based on propagation times and expected future transaction volumes, you should bear in mind that 10 minutes is a nice round number and that no calculations or simulations have come to light so far.

The time to transmit the transactions and blocks is small compared to the time taken to verify the data. The main obstacle to faster propagation times for blocks and transactions is that the data is checked before it is relayed. From a programming point of view, this is convenient as we're always sure that our client's view of the world is consistent even if other clients are trying to deceive it. However, given that the vast majority of clients are honest, it does seem a bit of a waste that all the clients redo the same calculations.

In order to speed block propagation there are several strategies which are faster but more complicated:
When a client receives a new transaction or block it records from where it came and advertises that it has the new transaction straight away. If another client requests the new transaction then then it is relayed straight away. When the client has time to check the transaction, if it's found to be bad then the client deletes it and makes a note to check transactions from that sender before advertising it next time. A client would be forgiven after a certain amount of time.
For blocks, the client should check successive individual transactions in the block in random order.

ByteCoin

Great catch! Your solution would be a very elegant way of signing a transaction and implicitly revealing the public key.

ByteCoin

It's true that you get occasional orphan blocks (not "all the time") but transactions in the orphan block chain are mostly just incorporated into the same block number on the longer chain.  

For the purposes of discussion, I suggest that we define a blockchain reorg as one in which previously confirmed transactions become unconfirmed. This requires a longer blockchain to have replaced the current blockchain at a depth of several blocks. This has never happened (unless forced by a software change in response to a bug) nor is it likely to happen. If it did happen, as I mention in the other thread, bitcoin already has potentially bigger problems with normal transactions.

The situation which Satoshi outlines, in which OP_BLOCKNUMBER transaction causes problems is very unlikely. You have to have an OP_BLOCKNUMBER transaction which is very close to expiry and a block chain reorg which occurs in the vicinity of that critical period.

To completely avoid this unlikely circumstance you should be careful to spend the coins some time before expiry.

I don't understand how this could be possible. Please explain.

The reason why OP_BLOCKNUMBER is superior to OP_TIMESTAMP is that bitcoin functions without all the clients agreeing about exact times and engineering agreement seems hard. OP_BLOCKNUMBER is a proxy for time that everyone can agree on.


ByteCoin

Fees don't make anything useful significantly faster. Fees make your transaction have a higher priority for inclusion into the next block. They don't make the next block arrive any sooner and under today's circumstances they don't get into blocks sooner than transactions without a fee.

ByteCoin

I explain in the thread why I think Satoshi's objection to OP_BLOCKNUMBER is unjustified. Of all the features
that  make Bitcoin a promising system, I think the scripting is the most powerful and OP_BLOCKNUMBER would facilitate many types of transactions which users would find very useful.

Although we're grateful to Satoshi for creating Bitcoin, should the fact that Satoshi has "rejected" an idea be sufficient grounds for not implementing it?

ByteCoin

I'm sure I've heard this misunderstanding before from other people on this forum. It looks like the source might have been this post from Satoshi http://bitcointalk.org/index.php?topic=30.msg1169#msg1169.

Although Satoshi is correct in saying that ECDSA can only be used to sign, you have to be aware that ECDSA is merely a particular method of using elliptic curve key pairs to sign messages. There are a host of other cryptographic schemes you can implement if users hold such pairs. These include other signing schemes, key agreement and encryption.

It is important to note that all the common cryptographic schemes are implementable with bitcoin's keypairs.

ByteCoin

It's good enough if you don't mind the message being unencrypted.

Transactions aren't encrypted so the addressee can be known purely by the hash of the key. I thought you wanted the messages encrypted to the addressee, in which case you need their public key.

ByteCoin

It's not? If you're going to make something look like scientific notation by using "e" then 10.25e8 had better be 1025000000 BTC otherwise at least have the decency to choose a different letter like "z" or possibly a non letter.
If that's true then why does the URI look like it means something rather than just being gibberish?

The fact that the URI is suggestive of a meaning when viewed by a human creates an obligation that the meaning suggested should not be misleading. If the URI were really only for the consumption of the client software then you should just take the data to be conveyed in binary form and then use an efficient encoding into the supported character set.

ByteCoin

The day you can do your supermarket shopping with bitcoin is the day you can say bitcoin has finally arrived. Supermarket chains will not be early adopters of bitcoin and without them, the supermarkets will not come along. The early adopters will be small merchants looking for a legitimate edge or alternatively an illegitimate edge in which they defraud some customers.

I take your point about smartphones having internet connections but it would be nice to have a useable bitcoin wallet on a smaller device with a similar form factor to a usb stick, an oyster card or a token generator.

ByteCoin