Every Bitcoin version ever released has been beta (intentionally).

There is nothing mandatory here.

0.8.2rc2 and above have a patch that makes getblocktemplate significantly faster (I've seen a factor 10 in some cases).

I completely disagree.

Yes, Bitcoin is exactly the same as other currencies in this respect. But we don't track serial numbers of dollar bills we get, do we? So why would we do accounting based on the currency?

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".

Obviously I mean getting a extended_address into mainline (that will need a BIP and maybe a bit of discussion on bitcoin-development, though), after a certain protocol number. That doesn't mean it actually needs support for any extended address, just support for the serialization in the addr packet. I've been wanting such an extension for a while, but never did any work that would make it useful. That would also mean you're not in a completely separate I2P island, as any nodes can (but not necessarily will) relay your I2P addresses across the rest of the network.

Using the service bit doesn't actually help if you mean you can do it without coordinating with other node implementations, as there may be a point where your service bit gets used for something else. My point is that no matter what, it's better to coordinate a bit (and people aren't opposed to supporting new transport protocols, afaik), and you don't actually need a service bit for this, as it's trivially discoverable by being on a different network altogether already.

I don't think there's a need to use a service flag for this. We could just bump the P2P protocol version number to support extended-length addresses (though we should do things like cjdns at the same time; I'd also like to see host keys in the protocol, but that's a far larger change).

The only data that belongs in (Bitcoin) transactions as they are transmitted via the P2P network and mined into blocks, is whatever the world needs to validate them. Anything else is just using it as an extremely expensive, slow and unreliable means of communication for data that is essentially private between sender and receiver anyway.

The correct solution is a payment protocol, where sender and receiver directly communicate with eachother to negotiate a transaction (including whatever optional metadata is needed, such as memo, comments, refund addresses, identities, ...), and then broadcast the Bitcoin part of it on the network to set it in stone.

Bitcoin at its core is not an accounting system, it is a currency. It implements this through its own ledger-like mechanism, though one that doesn't quite exactly match what we expect from a ledger. And I believe that doesn't matter.

Accounting is something you do at the "payment level", not at the "currency level". Dollars have no built-in way to track historical balances, and I don't think anyone considers that a shortcoming. We can keep track of credits and debits regardless.

I'm sure that with all developments at the wallet software (multiple clients, payment protocol, ...), it's perfectly possible to create a GAAP-conformant system, or at least one that easily integrates with accounting systems.

I don't think discussion about that belongs in this thread though - this is about solving a low-level scalability problem, not about how we manage high-level use of it.

No, as the inputs of the transaction are already consumed by the first transaction, the second one will be considered a double spend (even without specific code to detect this case).


The whole block will be considered invalid and ignored by other nodes.


Blocks are always accepted or rejected as a whole. There is no middle ground.


The fee of a transaction is defined as the value of its outputs minus the value of its inputs. As its inputs do not exist anymore for the second instance of the duplicate, you can't even talk about a notion of fee. These things only make sense when the transaction is valid.

Getrawtransaction queries the blockchain, not your wallet. Whether the transaction is in your wallet is irrelevant; without txindex=1, it only works for unspent transactions (slowly). With txindex=1, it will work for any transaction.

Have a look

The genesis block's output is not actually part of the transaction database, as it cannot be spent.

The reason is simply because no version of bitcoin ever added it to its database when creating a new datadir. The reason is unknown - it may have been a bug or it may have been intentional by Satoshi, but changing it now would be a hard fork (which would only be exploitable by Satoshi, but still), and there is no good reason to do so now.

Neither.

It queries the wallet, not the blockchain. The wallet contains a list of transactions, which is on-the-fly processed to produce the listtransactions output.

The client will not create such small change.

The "blocks" and "chainstate" directories. You can copy them independently, but the chainstate (which represents up to where you have blocks verified) must not be newer than the blocks.

Obviously, backup your wallet too- but that is independent from the block data.

It's not known whether it's a bug or intentional, but every code version behaved that way, so it can't just be changed.

Any version of bitcoind/bitcoin-qt's source code.

The transaction in the genesis block isn't added to the database at initialization, so a lookup to spend it would fail.

Changing that would mean giving Satoshi a red button to hardfork the network :p

This sounds like it's a limitation of the client. It's a (potentially accidental) hard network rule that the genesis block output cannot be spent.

Oh, I think I see your confusion.

The only way to request blocks is using getdata block or merkleblock, you can't just fetch individual transactions from it, as that would require the peer to have full transaction index. So what you hoped to do was send a merkleblock request to one peer, but without transactions, and then fetch the transactions themself from separate peers. That won't work.

Anyway, as said, in the future this may become a useful idea for an extension to the filtering protocol: adding a "only match the 3rd 1/5 of all transactions" to the filter specification.

I explained in #28 why that is not possible: even with disjunct filters, you'll get transactions matched by both.