<unnamed>

Public Key

npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypj

Profile Code

nprofile1qqsf3h4xsr5cyf4l2rejq4zhw70mh8tedfz5dlcqgtflhfva4t7r4hqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrxxywc

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 23:13:07 UTC

- reply

📅 Original date posted:2022-08-25
📝 Original message:Having previously developed an export format[1] for general cryptocurrency transaction information, I can attest to the value of the human-readable CSV. I was careful to mention the RFC 4180 spec so that implementations could avoid the pitfalls of incorrect CSV encoding.
[1]: https://github.com/harmony-csv/harmony
Clark
------- Original Message -------
On Thursday, August 25th, 2022 at 3:59 AM, Craig Raw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for your thoughts Ryan.
>
> Without reference to the quality feedback on this proposal, I was aware when submitting it for review that it provides an excellent opportunity for bike shedding. As developers, we have all experienced frustration with data formats. One thing that I did not perhaps make clear enough is that this format is not solely intended for developers, but general users who are probably not well represented on this list.
>
> While doing research for this proposal I spoke to several professional users of Sparrow Wallet (who are not developers). They all expressed a desire for the format to integrate with their business processes, which are driven by business tools such as Excel. Labelling provides an important function in UTXO and address management in these scenarios, and needs to be accessible and manageable outside of wallet software.
>
> If this is to be achieved, it immediately rules out JSON as a data format. Not only is JSON limited to editing only through specific software or text editors, but (in the latter case) it is fragile enough that a single missing character can cause an entire file to fail parsing. CSV is more forgiving in this regard. With respect to your comments on escaping, my expectation would be that developers will be using a mature CSV library rather than handling character escaping themselves. I would rather propose a format that is generally usable, even if occasionally a label is escaped incorrectly.
>
> Finally, I'll note that CSV files are already common and uncontroversial in Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (and no doubt many others) already export addresses and/or transactions with their labels as CSV files. This proposal simply attempts to create a standard for importing and exporting all the labels in a wallet.
>
> Craig
>
> On Wed, Aug 24, 2022 at 9:01 PM <rhavar at protonmail.com> wrote:
>
>> I'd strongly suggest not using CSV. Especially for a standard. I've worked with it as an interchange format many a times, and it's always been a clusterfuck.
>>
>> Right off the bat, you have stuff like "The fields may be quoted, but this is unnecessary as the first comma in the line will always be the delimiter" which invariably leads to some implementations doing it, some implementations not doing it, and others that are intolerant of the other way.
>>
>> And you have also made the classic mistake of not strictly defining escape rules. So everyone will pick their own (e.g. some will \, escape commas, others will not cause it's quoted and escape quotes, and others will assume no escaping is required since its the last column in a csv).
>>
>> Over time it morphs into its own mini-monster that introduces so much pain.
>>
>> On a similar note, allowing alternatives (like: txid>index vs txid:index) provides no benefit, but creates additional work for implementations (who quite likely only test formats they produce) and future incompatibilities.
>>
>> I know everyone loves to hate on it, but really (line-separated?) json is the way to go.
>>
>> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎", "label": "wow, such label" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txout": 4, "label": "omg this is so easy to parse" }
>> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txin": 0, "label": "wow this is going to be extensible as well" }
>>
>> -Ryan
>>
>> ------- Original Message -------
>> On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> I would like to propose a BIP that specifies a format for the export and import of labels from a wallet. While transferring access to funds across wallet applications has been made simple through standards such as BIP39, wallet labels remain siloed and difficult to extract despite their value, particularly in a privacy context.
>>>
>>> The proposed format is a simple two column CSV file, with the reference to a transaction, address, input or output in the first column, and the label in the second column. CSV was chosen for its wide accessibility, especially to users without specific technical expertise. Similarly, the CSV file may be compressed using the ZIP format, and optionally encrypted using AES.
>>>
>>> The full text of the BIP can be found at https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki and also copied below.
>>>
>>> Feedback is appreciated.
>>>
>>> Thanks,
>>> Craig Raw
>>>
>>> ---
>>>
>>> <pre>
>>> BIP: wallet-labels
>>> Layer: Applications
>>> Title: Wallet Labels Export Format
>>> Author: Craig Raw <craig at sparrowwallet.com>
>>> Comments-Summary: No comments yet.
>>> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
>>> Status: Draft
>>> Type: Informational
>>> Created: 2022-08-23
>>> License: BSD-2-Clause
>>> </pre>
>>>
>>> ==Abstract==
>>>
>>> This document specifies a format for the export of labels that may be attached to the transactions, addresses, input and outputs in a wallet.
>>>
>>> ==Copyright==
>>>
>>> This BIP is licensed under the BSD 2-clause license.
>>>
>>> ==Motivation==
>>>
>>> The export and import of funds across different Bitcoin wallet applications is well defined through standards such as BIP39, BIP32, BIP44 etc.
>>> These standards are well supported and allow users to move easily between different wallets.
>>> There is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, inputs or outputs in their wallet.
>>> The UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction.
>>> In both cases, care must be taken when spending to avoid undesirable leaks of private information.
>>> Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.
>>> Allowing users to export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.
>>> In addition, by using common formats, this BIP seeks to make manual or bulk management of labels accessible to users without specific technical expertise.
>>>
>>> ==Specification==
>>>
>>> In order to make the import and export of labels as widely accessible as possible, this BIP uses the comma separated values (CSV) format, which is widely supported by consumer, business, and scientific applications.
>>> Although the technical specification of CSV in RFC4180 is not always followed, the application of the format in this BIP is simple enough that compatibility should not present a problem.
>>> Moreover, the simplicity and forgiving nature of CSV (over for example JSON) lends itself well to bulk label editing using spreadsheet and text editing tools.
>>>
>>> A CSV export of labels from a wallet must be a UTF-8 encoded text file, containing one record per line, with records containing two fields delimited by a comma.
>>> The fields may be quoted, but this is unnecessary, as the first comma in the line will always be the delimiter.
>>> The first line in the file is a header, and should be ignored on import.
>>> Thereafter, each line represents a record that refers to a label applied in the wallet.
>>> The order in which these records appear is not defined.
>>>
>>> The first field in the record contains a reference to the transaction, address, input or output in the wallet.
>>> This is specified as one of the following:
>>> * Transaction ID (<tt>txid</tt>)
>>> * Address
>>> * Input (rendered as <tt>txid<index</tt>)
>>> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>>>
>>> The second field contains the label applied to the reference.
>>> Exporting applications may omit records with no labels or labels of zero length.
>>> Files exported should use the <tt>.csv</tt> file extension.
>>>
>>> In order to reduce file size while retaining wide accessibility, the CSV file may be compressed using the ZIP file format, using the <tt>.zip</tt> file extension.
>>> This <tt>.zip</tt> file may optionally be encrypted using either AES-128 or AES-256 encryption, which is supported by numerous applications including Winzip and 7-zip.
>>> In order to ensure that weak encryption does not proliferate, importers following this standard must refuse to import <tt>.zip</tt> files encrypted with the weaker Zip 2.0 standard.
>>> The textual representation of the wallet's extended public key (as defined by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>>>
>>> ==Importing==
>>>
>>> When importing, a naive algorithm may simply match against any reference, but it is possible to disambiguate between transactions, addresses, inputs and outputs.
>>> For example in the following pseudocode:
>>> <pre>
>>> if reference length < 64
>>> Set address label
>>> else if reference length == 64
>>> Set transaction label
>>> else if reference contains '<'
>>> Set input label
>>> else
>>> Set output label
>>> </pre>
>>>
>>> Importing applications may truncate labels if necessary.
>>>
>>> ==Test Vectors==
>>>
>>> The following fragment represents a wallet label export:
>>> <pre>
>>> Reference,Label
>>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
>>> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
>>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
>>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
>>> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output (alternative)
>>> </pre>
>>>
>>> ==Reference Implementation==
>>>
>>> TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220825/20dfb197/attachment-0001.html>

2023-06-07 23:13:01 UTC

- reply

📅 Original date posted:2022-08-24
📝 Original message:Craig,
Thanks for the proposal.
How does this proposal compare with SLIP-0015, which provides encryption by default? Would it be worth exploring a merge of the two approaches?
https://github.com/satoshilabs/slips/blob/master/slip-0015.md
Clark
------- Original Message -------
On Wednesday, August 24th, 2022 at 4:18 AM, Craig Raw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I would like to propose a BIP that specifies a format for the export and import of labels from a wallet. While transferring access to funds across wallet applications has been made simple through standards such as BIP39, wallet labels remain siloed and difficult to extract despite their value, particularly in a privacy context.
>
> The proposed format is a simple two column CSV file, with the reference to a transaction, address, input or output in the first column, and the label in the second column. CSV was chosen for its wide accessibility, especially to users without specific technical expertise. Similarly, the CSV file may be compressed using the ZIP format, and optionally encrypted using AES.
>
> The full text of the BIP can be found at https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki and also copied below.
>
> Feedback is appreciated.
>
> Thanks,
> Craig Raw
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <craig at sparrowwallet.com>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> Status: Draft
> Type: Informational
> Created: 2022-08-23
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document specifies a format for the export of labels that may be attached to the transactions, addresses, input and outputs in a wallet.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> The export and import of funds across different Bitcoin wallet applications is well defined through standards such as BIP39, BIP32, BIP44 etc.
> These standards are well supported and allow users to move easily between different wallets.
> There is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, inputs or outputs in their wallet.
> The UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction.
> In both cases, care must be taken when spending to avoid undesirable leaks of private information.
> Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.
> Allowing users to export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or bulk management of labels accessible to users without specific technical expertise.
>
> ==Specification==
>
> In order to make the import and export of labels as widely accessible as possible, this BIP uses the comma separated values (CSV) format, which is widely supported by consumer, business, and scientific applications.
> Although the technical specification of CSV in RFC4180 is not always followed, the application of the format in this BIP is simple enough that compatibility should not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example JSON) lends itself well to bulk label editing using spreadsheet and text editing tools.
>
> A CSV export of labels from a wallet must be a UTF-8 encoded text file, containing one record per line, with records containing two fields delimited by a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in the line will always be the delimiter.
> The first line in the file is a header, and should be ignored on import.
> Thereafter, each line represents a record that refers to a label applied in the wallet.
> The order in which these records appear is not defined.
>
> The first field in the record contains a reference to the transaction, address, input or output in the wallet.
> This is specified as one of the following:
> * Transaction ID (<tt>txid</tt>)
> * Address
> * Input (rendered as <tt>txid<index</tt>)
> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>
> The second field contains the label applied to the reference.
> Exporting applications may omit records with no labels or labels of zero length.
> Files exported should use the <tt>.csv</tt> file extension.
>
> In order to reduce file size while retaining wide accessibility, the CSV file may be compressed using the ZIP file format, using the <tt>.zip</tt> file extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128 or AES-256 encryption, which is supported by numerous applications including Winzip and 7-zip.
> In order to ensure that weak encryption does not proliferate, importers following this standard must refuse to import <tt>.zip</tt> files encrypted with the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as defined by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>
> ==Importing==
>
> When importing, a naive algorithm may simply match against any reference, but it is possible to disambiguate between transactions, addresses, inputs and outputs.
> For example in the following pseudocode:
> <pre>
> if reference length < 64
> Set address label
> else if reference length == 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> ==Test Vectors==
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output (alternative)
> </pre>
>
> ==Reference Implementation==
>
> TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220824/2c3e56ea/attachment.html>

2023-06-07 18:11:52 UTC

- reply

📅 Original date posted:2018-05-03
📝 Original message:Paul,
The current BIP-49 / 84 use the purpose field of the derivation path to specify
the address format.
I think sticking with the one-BIP-one-format method works. Otherwise, you
would need to modify this proposed BIP each time a new format comes along.
In that case, existing wallets that claim BIP-XXXX compliance will be
incomplete.
-Clark
On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown <paul at 345.systems> wrote:
> Hi
>
> I realised after I sent my previous response that the encoding was wrong
> and that my smiley face at the end of the BIP number comment got turned
> into a ? and the tongue in cheek context was lost :-(
>
> Anyway, back onto subject. I've been thinking some more on the SLIP-0032
> adoption in this proposal and specifically the address format to use when
> generating addresses.
>
> My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however,
> I wonder whether there is some merit in extending the derivation path with
> an additional level below coin type to represent the address format, with
> the value determined by the context of the coin type value in the
> derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type
> is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc).
> A separate spec similar to SLIP-0044 could be created that defines the list
> of address formats and the derivation path values.
>
> When importing root master seeds or distributing the xpub's for each
> cosigner to each party the discovery process in the proposal would need
> extending to try each address format in turn to determine whether there is
> a 'hit' when checking balances. It does mean that the import process is
> slower however the additional flexibility of supporting multiple address
> formats possibly outweighs this. I'm just thinking that having a rule to
> follow during discovery, particularly where non-Bitcoin coins are
> concerned, is more explicit than leaving it open to the wallet implementer
> to figure out (for altcoins, what address format to use?).
>
> It also means that future address formats are supported as they are simply
> added to the new spec list for the coin type (can be done by anyone,
> similar to the way SLIP-0044 works now) - it doesn't require a new BIP to
> support. For example, if address format was a derivation level in BIP44,
> would BIP49 and BIP84 be needed?
>
> I'm somewhat musing out loud here, but I like the idea of being able to
> mostly self-discover as much as possible and reducing or eliminating the
> need for proprietary metadata attached to the wallet.
>
> Cheers
> Paul
>
> From: clarkmoody at gmail.com <clarkmoody at gmail.com> On Behalf Of Clark Moody
> Sent: 25 April 2018 15:36
> To: Paul Brown <paul at 345.systems>; Bitcoin Protocol Discussion <
> bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one
> BIP32 derivation path (new BIP)
>
> Thanks for the proposal, Paul.
>
> > - What address format is expected when discovering balances and creating
> transactions?
>
> Your solution does not solve your first bullet point, since the xpub
> encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At
> the least, you should propose new version bytes to change the "xpub" in the
> encoding to some other string.
>
> Alternatively, I would suggest that you use the xpub serialization format
> described in SLIP-0032 (
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It
> includes the derivation path within the xpub itself and uses Bech32 for
> encoding.
>
> Given a normal xpub with no additional information, a wallet must scan the
> address space for the various formats. SLIP-0032 solves this bootstrapping
> problem and avoids the UX nightmare of users being required to know to
> which BIP number the xpub conforms.
>
> Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)
>
> Thanks
>
>
>
>
> -Clark
>
> On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev <mailto:
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi
>
> I have written a new BIP describing a BIP32 derivation path that supports
> a single or multi-signature and multi-coin wallet from a single master
> seed. It combines BIP44 and BIP45 and adds in a self-describing structure
> in the derivation path for multiple multi-sig combinations within the
> single wallet along with an extended public key export file format for
> public key distribution between parties. I can particularly see this being
> useful for multiple Lightning Network 2of2 accounts for different payment
> channels.
>
> The BIP can be found here:
> https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki
>
> I appreciate that this might be re-hashing old ground as BIP44 in
> particular has been widely adopted, however, BIP44 does leave itself open
> to a lot of interpretation from a wallet portability perspective such as:
>
> - What address format is expected when discovering balances and creating
> transactions?
> - Does the master seed represent a single-sig or multi-sig wallet?
> - If multi-sig, how many cosigners and what are their extended public keys
> (so that the wallet can generate the correctly formatted redeem script with
> public keys in the right order)?
> - If multi-sig, how do you prevent collisions on the same address index
> (in a wallet that is occasionally connected)?
>
> BIP45 solves the collision that occurs when the individual parties in a
> multi-sig group each give out a new address from a wallet, where the wallet
> hasn’t been able to sync to mark the address as ‘used’ (this could happen
> if they gave out addresses independently at the same time). It uses a
> cosigner index in the derivation path so that each party has their own path
> to their addresses. However, BIP45 drops the multi-coin support that BIP44
> has.
>
> This is a useful discussion on the problems of a collision and the merits
> of separating cosigners in the derivation path:
> https://www.mail-archive.com/[email protected]/msg05188.html
>
> For the purposes of the BIP text (and the example paths used to generate
> keys) I’ve temporarily assigned it the number 46. It looks like that is
> available and seemed somewhat appropriate given that it builds on the good
> work of BIP44 and BIP45.
>
> Paul Brown
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> mailto:bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180504/90c4be2c/attachment-0001.html>

2023-06-07 18:08:43 UTC

- reply

📅 Original date posted:2017-12-14
📝 Original message:An alternative to "training" users to understand SI prefixes could be to
make 100 satoshi = 1 mu, spelling out the Greek letter.
Although the Units <https://en.bitcoin.it/wiki/Units> page on the wiki has
been brought up to argue against naming 10,000 satoshi = 1 finney, I would
like to support this designation. It seems to be gaining some popular
support on Twitter & podcasts. So at $10,000 BTC/USD, 1 finney = $1.00. The
smallest unit of value would be 0.0001 finney = 1 satoshi. Finney has a
natural abbreviation as fin, and 100 mu = 1 finney.
The Units page also refers to "bitcent" as 0.01 BTC, but if a "bit" is 100
satoshi, then what is a "bitcent" in that context?
/bikeshed
@Natanael you're exactly right. There are already multiple uses of "bits"
within bitcoin itself.
@Sjors I don't think a redefinition of 'satoshi' is going to happen ;-)
-Clark
On Thu, Dec 14, 2017 at 4:01 PM, Natanael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Reposting /u/BashCo's post on reddit here, for visibility:
>
> ---8<---------------------------------------------------------------
>
> > Before anyone says 'bits' are too confusing because it's a computer
> science term, here's a list of homonyms [https://en.wikipedia.org/wiki
> /List_of_true_homonyms] that you use every day. Homonyms are fine because
> our brains are able to interpret language based on context, so it's a
> non-argument.
>
>
> This ignores the fact that there exists multiple meanings of bits *within
> the same context*, and that beginners likely can't tell them apart.
>
> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
> value with somebody who doesn't understand Bitcoin. Then explain that the
> cryptography uses 256 bit keys. I would be surprised if you could find
> somebody who would not be confused by that.
>
> Let's say a website says a song is 24 bits. Was that 24 bit audio
> resolution or 24 bit price? Somebody writes about 256 bit keys, are that
> their size or value?
>
> You guys here can probably tell the difference. Can everybody...? Bits
> will cause confusion, because plenty of people will not be able to tell
> these apart. They will not know WHEN to apply one definition or the other.
>
> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171214/73f8b8ef/attachment-0001.html>

2023-06-07 18:04:38 UTC

- reply

📅 Original date posted:2017-07-14
📝 Original 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