Discussion:
A BIP proposal for conveniently referring to confirmed transactions
(too old to reply)
Clark Moody via bitcoin-dev
2017-07-14 18:43:37 UTC
Permalink
Raw Message
(copying from GitHub per jonasschnelli's request)

I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.

You could go with a variable-length encoding similar to Bitcoin's
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.

Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:

# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin's magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T

This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.

Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]

So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.

I know this is a departure from your vision, but it would be much more
flexible for the long term.


Clark
Велеслав via bitcoin-dev
2017-07-15 05:00:18 UTC
Permalink
Raw Message
Hello Clark Moody,
Thank you for your review of our proposal.
For reference please see the pull request: https://github.com/bitcoin/bips/pull/555 and the proposed specification: https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki. (I will inform the mailing if a BIP number is assigned and these become obsolete).
On variable length encodings:
We considered in-depth various variable length encodings; and found that for such short data-lengths they all came with a too-high overheard: especially when you design them to work correctly with 5-bit chunks. We will update the rational section of the BIP to include this comment.
Hence, we have proposed the concept of "Display Formats". Display Formats are individually tailored to a particular purpose and thus can be optimised to a much greater extent.
In the case there is a Hard-Fork that extends Bitcoin's Block Transaction Capacity over the 8191 of the provided display format, we will simply define a "Bitcoin Display Format 1". Considering the considerable disruption a Hard Fork causes; the creation of a secondary Display Format should not be of significant concern.
In the case there is a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity; it makes no sense to try and define for an undefined format now. We will simply use a new Magic Value and create a tailored Display Format for the new system.
In the case that it is nearing Year 2048, I think that we will be in a far-better position to define a new format that suits the needs of the Bitcoin users than now.
Many thanks for your careful review, it is much appreciated,
С МаОлучшОЌО пПжелаМОяЌО,
Велеслав
-------- Original Message --------
Subject: Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
Local Time: July 15, 2017 1:43 AM
UTC Time: July 14, 2017 6:43 PM
From: bitcoin-***@lists.linuxfoundation.org
To: bitcoin-***@lists.linuxfoundation.org
(copying from GitHub per jonasschnelli"s request)
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.
You could go with a variable-length encoding similar to Bitcoin"s
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.
Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:
# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin"s magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T
This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.
Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]
So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.
I know this is a departure from your vision, but it would be much more
flexible for the long term.
Clark
Tom Zander via bitcoin-dev
2017-07-17 13:40:29 UTC
Permalink
Raw Message
Post by Clark Moody via bitcoin-dev
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits
I’m not so clear on this, to be honest.

What is the point of having a user-readable tx-reference?

In the actual blockchain you will still be using txid, and if you want to
change that then a less readable but more compact format is useful because
we want to optimize for space, not for human comprehention.

Another usecase I can come up with is you wanting to spend a specific output,
or you reporting a specific tx as proof to a merchant (or tax office).

For any such usecases you sill need to actually provide a proof of holding
the private keys and using a human-readable format just doesn’t seem to make
much sense because a cryptographic proof of ownership is not going to be
readable however hard you try.

Apologies for missing the point,
can you list one or two usecases that you can see this being used for?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Loading...