* [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
@ 2017-05-23 15:30 Велеслав
0 siblings, 0 replies; 4+ messages in thread
From: Велеслав @ 2017-05-23 15:30 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
Hello List,
I would like to propose a BIP that specifies a way of referring to transactions that have been successfully inserted into the blockchain.
The format makes use of the excellent Bech32 encoding, and is designed to be short and useful for human use. A C reference implementation is included.
Special care has been taken so this BIP is naturally extendable to support future upgrades to Bitcoin, Bitcoin Sidechains, or even from other blockchain projects. However, only support for the Bitcoin Main Chain, and the Test Network is specified in this draft.
I hope that the participants of the bitcoin-development mailing list find this draft BIP both interesting and useful. You are welcomed to read the full text here: https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki
If assigned with a BIP number some small updates to the specification will be made in accommodation.
С наилучшими пожеланиями,
Велеслав
[-- Attachment #2: Type: text/html, Size: 1401 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
2017-07-14 18:43 Clark Moody
2017-07-15 5:00 ` Велеслав
@ 2017-07-17 13:40 ` Tom Zander
1 sibling, 0 replies; 4+ messages in thread
From: Tom Zander @ 2017-07-17 13:40 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On Friday, 14 July 2017 20:43:37 CEST Clark Moody via bitcoin-dev wrote:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
2017-07-14 18:43 Clark Moody
@ 2017-07-15 5:00 ` Велеслав
2017-07-17 13:40 ` Tom Zander
1 sibling, 0 replies; 4+ messages in thread
From: Велеслав @ 2017-07-15 5:00 UTC (permalink / raw)
To: Clark Moody, Jonas Schnelli; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]
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-dev@lists•linuxfoundation.org
To: bitcoin-dev@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5593 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
@ 2017-07-14 18:43 Clark Moody
2017-07-15 5:00 ` Велеслав
2017-07-17 13:40 ` Tom Zander
0 siblings, 2 replies; 4+ messages in thread
From: Clark Moody @ 2017-07-14 18:43 UTC (permalink / raw)
To: bitcoin-dev
(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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-07-17 13:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-23 15:30 [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions Велеслав
2017-07-14 18:43 Clark Moody
2017-07-15 5:00 ` Велеслав
2017-07-17 13:40 ` Tom Zander
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox