Topic: RFC: Comment field in Transactions (Read 2371 times)

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.

I agree with the idea. Any progress made on this?

That was on purpose :-)

Yes off course the reference ID would have a fixed size. Therefore comment might be the wrong choice for a name, I chose the title mainly to catch the eye of all interested people. Hashes would be one way to go, but as stated above I think UUIDs is the way to go, because Hash always implies something else being hashed, question is "of what?" whereas a UUID is easy to generate, there is no attempt to associate it with anything else.

mind. blown.

I though it was funny that calling this an RFC is kind of a play on words. RFC means Request For Comments, and in this case you're requesting that comments be added to transactions. So it's a request for comments in both senses.

If such a field was clearly proscribed and had to be linked to a transaction (thus costing bitcoins to be used), I think such a field could be useful.  It should be a fixed size and IMHO only large enough for a hash where the recipient must come up with some sort of context to that field.  Such a field could contain alphanumeric characters, binary data, a hash, a nonce, or some other sort of stuff whatever it might be.

I would hate to see Bitcion getting turned into something like TwitterFS, but I think that can be kept under control through the use of transaction fees.  That may be unfortunate where transaction fees may have to show up for all transactions if this gets abused, but that is at least an option for the network miners to consider.  A flood of 0.01 BTC transactions all at about the same time would indicate some sort of mischief going on in that regard.

Well a reference is part of the transaction, so it should be in the main chain. There is no "reference chain" to add references and comments to the transactions in the main chain is there? I agree that the main chain should only be used for the main Bitcoin purpose which is tracking and exchanging Bitcoins, but IMHO the comment/reference is just as important as the amount being spent. Using an address per transaction is actually more of a hack than adding a comment would be.

So I guess you'd vote against it on behalf that it opens the discussion for a lot of other "nice to have" data in the transactions?

I think there is general agreement that arbitrary data (a comment field) should be an optional component of transactions.

The main point of contention now is whether or not to put that in the main block chain.

I think 32-64 bytes is sufficient for most uses -- reference id's and hashes.  Custom block chains might want much larger limits: 512 bytes?  4k?

Ok, right now there's a huge discussion going on in https://bitcointalksearch.org/topic/version-0318-2162 and I would support the changes to accepting only standard transaction would it not disallow exactly what I've been looking for: the ability to reuse a BC Address for multiple transaction and being able to distinguish their purpose.

Admittedly it's a hack, but a rather clever one, it was possible to insert a comment to a transaction followed by an OP_DROP which would remove it when checking the TX on the clients.

Why would one do this? Right from the terminology it's clearer, I wouldn't create a new bank account just to receive a single payment from someone, what I'd do is give him a payment slip, with a reference ID, and I'd later check if I have received a transaction with that ID.
And for the more practical minded people, it's safer! Why? Because if you generate a new address for each transaction, and you then loose the wallet, but have an old backup, in which the new keypairs aren't, you will be able to recover the Coins that you have received for keypairs in your wallet but the new ones will be lost forever.

You see it's rather more logical to separate transactions and accounts (as the new name suggests for addresses).

I therefore put it to a vote to include an official means to add a reference ID into transaction should one be supplied. To keep it simple and to keep the block chain small we could agree on allowing UUIDs in their 16 byte representation as IDs.

Any comments?