public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* 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
* [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

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-07-14 18:43 [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions Clark Moody
2017-07-15  5:00 ` Велеслав
2017-07-17 13:40 ` Tom Zander
  -- strict thread matches above, loose matches on Subject: below --
2017-05-23 15:30 Велеслав

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox