Did it work with 0.3.21?

To me, Bitcoin is an interesting experiment. It may fail for various reasons, grow obsolete, or - who knows - change the world. Whatever happens, we'll learn a lot about independent online currencies and their feasibility, and I would sure love to see one succeed, even in just a niche market.

Also, in its current form, I don't see it as a competitor to paypal or other transaction processor. It's just this:

  The free currency of the internet.

(free as in freedom, obviously). The services built upon - including paypal-like infrastructures - grow every day, but there's a long way to go, and I hope I can contribute a bit to get there.

If prefer to keep things simple for now, but if we want to add that later, it may break the compatibility with this patch (we must chose to use Sign or SignCompact when signing. When verifying, no problem, if a bitcoin address is provided it'll use VerifyCompact, otherwise Verify).

What are the other opinions ?
[/quote]

What about currenty just encoding pubkey + signature together in a single hex or base58 string, so the "verifymessage address message signature" interface can be used. In can always be extended later to use the more compact representation.

Which version are you using? 0.3.21 should support this situation automatically. Earlier versions may need a -rescan. If transactions were done using copies of the wallet, you need 0.3.21 whatsoever.

I don't like the idea of openssl segfaulting on garbage data.

Is there an easy way for checking (by looking at the bytes ourselves, not by passing it to openssl and request to encode it again) that the input is a valid DER-encoded signature?

I'd like to see a way to pass the passphrase through a file descriptor instead of on the command-line, so it isn't visible on the process list.

It is a purely psychological thing, but you need people to think in the derived (indexed) unit rather than the internal (bitcoin) unit, as their pay in the latter one will decrease.

PS: this is not a serious proposal, just to show that it's possible to address (some of) the concerns.

(repost from general discussion)

Hello,

the past few months I've heard about many people who consider the limited money supply of Bitcoin as a flaw. I am no economist, and won't get involved in a discussion for or against deflation, but there is one claim I am sympathetic with: if people were paid in bitcoins, their pay rate might need to decrease gradually, and people definitely don't like to see decreasing numbers (purely a psychological thing). Hence my solution: IndexCoin.

IndexCoin is a currency backed by bitcoin, but with an exchange rate that varies in time. Actually, IndexCoin is nothing more than a different representation of bitcoin amounts. The exchange rate is determined by an index, which is defined by a central authority. Note however that many such authorities may exist, and people are free to choose one.

The authority publishes (using the necessary cryptographic arrangements, such as digitally signing) regularly an updated file which contains indexing points, Each point is defined as a block number together with an index value, plus a special index for any point in time before the first indexing (typically 1).

The IndexCoin client displays the amount for each transaction calculated for the time/block position in which the transaction took place, plus pseudo-transactions that represent the indexation, eg. "0.1% Interest on balance 1234.45 IDXC: +1.23445", if the index increased with 0.1% at a point in time where the wallet's balance was 1234.45 IDXC.

When doing a transaction, people can freely choose which index they want to use for the currency they send (or the address format could be modified to include information about the holder's native index). The client will then lookup the index value of that, and send the corresponding number of BTC, implicitly doing a feeless "currency convertion". If I use the Alpha-index, and you're using the Beta-index, I could choose to send you an amount in AlphaCoins or in BetaCoins.

Though I am not sure an index linked to such a volatile exchange rate would be a good idea, but exchange sites could be their own index authority, allowing eg. an indexcoin client that denominates values in "MTGUSD".

A payment contract could stipulate a trusted index authority to use for payments then.

Neither is bitcoin designed to retain the history for all time. Though not implemented yet, the system is designed to purse spend transaction outputs from storage, after the spending is buried deep enough in the block chain.

Exactly.


Again correct, but I'm not sure the default client will be able to create a corresponding txIn 9even though it's trivial).

By waste I mean: earn less than the electricity it costs you. And no, it is not designed to be wasteful in this respect.


The security of the network lies in the fact that you need - on average - to do as much work as was done in generating a part of the chain, to revert that part of the chain to your own version. The difficulty is irrelevant here, its only purpose is to prevent massive stale blocks by people working on different blocks at the same time. The security of the network is only determined by the total hashing speed, and even now, small CPu miners do contribute to that, but that does not mean they should if it is wasteful for them.

GPU mining code in the default client is an incredible mess. There are many algorithms tuned for different cards, and one has to support different versions of OpenCL and CUDA for different operating systems, making it unmaintainable and pulling in tons of dependencies. This is much better done in specialized packages, those will be better at it anyway.

1 BTC / month currently corresponds to 256 Mhash/s. There are no CPU's that can do that, and only a few GPU's can.

Yes, but at some point it's just not worth it.

Maybe, but that does not mean we want tons of people burning electricity for almost no additional strength to the network.

At the fact that 10000 users running a CPU miner would only result in a few % increased total hash rate. Mining is a business, the economics of which make it profitable only for those with the most efficient hardware. Don't give users false hope that it is otherwise. If they are persistent that they still want to mine on a CPU, they can run a CPU miner, which has better algorithms too.

Hello,

the past few months I've heard about many people who consider the limited money supply of Bitcoin as a flaw. I am no economist, and won't get involved in a discussion for or against deflation, but there is one claim I am sympathetic with: if people were paid in bitcoins, their pay rate might need to decrease gradually, and people definitely don't like to see decreasing numbers (purely a psychological thing). Hence my solution: IndexCoin.

IndexCoin is a currency backed by bitcoin, but with an exchange rate that varies in time. Actually, IndexCoin is nothing more than a different representation of bitcoin values. The exchange rate is determined by an index, which is defined by a central authority. Note however that many such authorities may exist, and people are free to choose one.

The authority publishes (using the necessary cryptographic arrangements, such as digitally signing) regularly an updated file which contains indexing points, Each point is defined as a block number together with an index value, plus a special index for any point in time before the first indexing (typically 1).

The IndexCoin client displays the amount for each transaction calculated for the time/block position in which the transaction took place, plus pseudo-transactions that represent the indexation, eg. "0.1% Interest on balance 1234.45 IDXC: +1.23445", if the index increased with 0.1% at a point in time where the wallet's balance was 1234.45 IDXC.

When doing a transaction, people can freely choose which index authority they want to use (or the address format could be modified to include information about the holder's native index). The client will then lookup the index value of the receiver, and send the corresponding number of BTC, implicitly doing a feeless "currency convertion".

Though I am not sure an index linked to such a volatile exchange rate would be a good idea, but exchange sites could be their own index authority, allowing eg. an indexcoin client that denominates values in "MTGUSD".

A payment contract could stipulate a trusted index authority to use for payments then.

You're right, it seems. This seems strange to me - I would expect the outputs to remain identical instead of the input, so that someone who sees a payment coming in will know for sure it will either confirm, be replaced by something with the same effect (or remain in limbo forever...). Any reason why there is a requirement on the inputs remaining identical?

I you're going to store your wallet in the block chain (only its keys, the transactions are there anyway), encrypted with a passphrase, I think you're better off using an idea that suggested here earlier: use the passphrase as random seed for generating your keys... no need to store anything anywhere, and exactly the same level of security.

The bitcoin protocol supports a version number in transactions, and there is code in the main client (though disabled) for handling this. I believe it should be possible to enable it again. This will allow you to create new versions of a transaction that override the old version as long as they are not included in a block.

So let me get this straight: bitcoin's signatures are always in DER encoding, but it will accept any BER-encoded signature?

I believe the attack you describe is possible and real, but the effect is less troublesome. As soon as a modified echo of the transaction is included in a block, both sender and receiver will see this transaction too. The old transaction will linger on however, unconfirmed.

All nodes in the network - even those who are not lookin to generate new blocks - are verifying all transactions and blocks generated by others. This on itself is beneficial for the network (especially if you have a lot of connections).

Generating blocks is only as good as the (average) number of blocks generated. If a node would try one 1 khash per second, it will generate 1/2144027 of a block per year. Sorry, that's pointless.

The current network hashing speed is estimated around 1.8 Thash/s. It requires around 50000 normal desktop systems (4 Mhash/s each) to get a 10% share of this number. The same can be accomplished with 300 high-end graphic cards. Doing it with anything else, is just a waste of electricity.