bip-0046: Address Scheme for Timelocked Fidelity Bonds #1599

pull theborakompanioni wants to merge 25 commits into bitcoin:master from theborakompanioni:bip-46 changing 2 files +200 −0
  1. theborakompanioni commented at 12:44 pm on May 23, 2024: contributor

    This is a continuation of @chris-belcher’s PR#1341 titled “Derivation scheme for timelocked address fidelity bond based accounts”, as Chris will quite possibly not be able to progress this any further. Please see comments in the PR, especially #1341 (comment):

    It will probably be the easiest to open a new PR that supersedes this one.

    TBD (from #1341#pullrequestreview-2055394826):

    As soon as all missing points are addressed, #1341 can be closed and this PR un-drafted. Happy for any and all feedback, particularly when it comes to finalizing it. :pray:

  2. Specify BIP-fidelity-bonds 
    For storing fidelity bonds in HD wallets
    bf2eb4f680
  3. chore(bip-0046): rename bip-fidelity-bonds to bip-0046 05e2c0c12f
  4. docs(bip-0046): add bip number to header section 8e109f98de
  5. chore(bip-0046): fix typos and grammar 64f93a239d
  6. docs(bip-0046): change title to 'Address Scheme for Timelocked Fidelity Bonds' 03a679958a
  7. chore(bip-0046): remove (optional) Comments-Summary header 57f1fe3f4b
  8. docs(bip-0046): add Comments-URI header 5209a28c1a
  9. docs(bip-0046): add Copyright section 164412d08b
  10. in bip-0046.mediawiki:5 in 164412d08b outdated 
    0@@ -0,0 +1,171 @@
1+<pre>
2+  BIP: 46
3+  Layer: Applications
4+  Title: Address Scheme for Timelocked Fidelity Bonds
5+  Author: Chris Belcher <belcher@riseup.net>
    murchandamus commented at 12:57 pm on May 23, 2024:
    It seems to me that it would be appropriate that you add yourself as a second author
    theborakompanioni commented at 1:46 pm on May 23, 2024:
    Hm, I am not sure this is entirely appropriate.. if anyone, you should be added as second author :wink: But thanks @murchandamus, let’s see how much work is still need (and hopefully with @chris-belcher approval) before un-drafting.
    murchandamus commented at 2:33 pm on May 23, 2024:
    My thinking here was that you seemed interested in moving this BIP forward, and given Chris’s absence, that made you a likely additional BIP champion. In contrast, I am not invested in this document beyond my editorial assignment, so I have no aspiration to be this BIP’s champion. ;)
    theborakompanioni commented at 8:35 am on May 27, 2024:
    Added myself to the Author header. Thanks @murchandamus.
  11. in bip-0046.mediawiki:20 in 164412d08b outdated 
    15+
16+This BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also defines how to sign fidelity bond certificates, which are needed when using fidelity bonds that are stored offline.
17+
18+== Copyright ==
19+
20+This document is placed in the public domain.
    murchandamus commented at 12:59 pm on May 23, 2024:
    The Preamble specifies the license as CC0-1.0, so the Copyright section should also commit to CC0-1.0
    theborakompanioni commented at 1:50 pm on May 23, 2024:
    Fixed. It was not my intention to change Chris’ idea. An honest mistake.
  12. KamPuc86zg approved
  13. in bip-0046.mediawiki:86 in 164412d08b outdated 
    81+</pre>
82+
83+
84+=== Address derivation ===
85+
86+To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>scriptPubKey</tt> of the P2WSH address.
    murchandamus commented at 1:05 pm on May 23, 2024:

    scriptPubKey or output script refers to the entire field, but the hash of the witness script is only the last part of the output script. In the context of native segwit outputs, it is called a witness program.

    0To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>witness program</tt> in the output script of the P2WSH address.
    theborakompanioni commented at 1:53 pm on May 23, 2024:
    Fixed. :+1:
  14. murchandamus commented at 1:09 pm on May 23, 2024: contributor
    Thanks for picking this up!
  15. fix(bip-0046): change license from Public Domain to CC0-1.0 00c7d0b815
  16. chore(bip-0046): scriptPubKey -> witness programm f9d370d3da
  17. docs(bip-0046): add Backwards Compatibility section 0b353bc7db
  18. chore(bip-0046): fix date format in Post-History header 722a388ae3
  19. chore(bip-0046): improve timelock point in time explanation a6f1cf3e0d
  20. chore(bip-0046): add tbk to Author header 25361d28ed
  21. docs(bip-0046): add Rationale section 2bc326e6af
  22. theborakompanioni commented at 8:43 am on May 27, 2024: contributor

    @murchandamus Addressed every raised point and will mark this as ready for review soon. It would be nice to know if everything has been addressed in a satisfactory manner and if this–after taking additional feedback into account–meets the official standard and guidelines. I hope I managed to keep it as simple and straightforward as possible, with minimal changes to the original document and in the best interest of @chris-belcher.

    Thank you again for your support.

    Edit: As the CI checks fail, should I create the table row entry in the readme file myself?

  23. theborakompanioni marked this as ready for review on May 27, 2024
  24. theborakompanioni commented at 9:02 am on May 28, 2024: contributor
    Ping @kristapsk @AdamISZ @openoms. Would you possibly be so kind as to read the document once again and see if there are no obvious mistakes or if something has been overlooked? :pray:
  25. AdamISZ commented at 2:22 pm on May 28, 2024: contributor

    Hi @theborakompanioni , thanks for this effort.

    It also defines how to sign fidelity bond certificates, which are needed when using fidelity bonds that are stored offline.

    I don’t think this should be in the document. See:

    You’ve convinced me that specifying the exact form of the fidelity bond certificate is a bad idea. I’ll leave it more general, saying just that wallets should be able to do SignMessage using the timelocked privkey. And I’ll leave the example signature in the test vectors.

    (etc.) from here.

    Now, to be clear, I think this has already been addressed in an edit to the BIP language. Notice it has a section on Signing Messages which only refers to general principles, not to a specific format for a certificate. So my point here is only that the phrase “it defines how to sign fidelity bond certificates” should be removed. Instead perhaps “It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates”.

    It would be useful to be able to keep the private keys of fidelity bonds in cold storage. This would allow the sybil resistance of a system to increase without hot wallet risk.

    (minor): Language/stylistic nit: I don’t believe these standard defining documents should have “would” type statements; that’s about proposals, not definitions. So here for example you’d write “It is very useful to be able …”, “This allows ..”.

    \x18Bitcoin Signed Message:\n

    (very minor): is there another more unambiguous way to write the starting byte?

    I have a more general comment which I think might be very important in practice, but I’m not sure how to address:

    the document defines two things specifically, as it has to: first, the BIP32 derivation and second, the time intervals.

    • For the first point, would it be more natural to choose a specific account? (See BIP44), than a third branch (2) at the lowest level, deviating from the BIP32 standard structure of external/internal (deposit/change)? My question here is somewhat academic, this has been in place in Joinmarket for a few years. Most wallet developers wouldn’t struggle with it, but it is a significant deviation from expected wallet structure.

    • For the second point, somewhat similar I guess: a specific time interval (one month) and a specific number of months feels like it’s too inflexible. To whatever extent use-cases exist for timelocked fidelity bonds outside joinmarket, it might be the case that this specific schedule is not at all workable.

    These two points seem like a perfect scenario for wallet descriptors, right? We have here a custom scriptPubKey format, a custom derivation, and even more, as per the above, we might realistically need to parameterise that customisation. But unfortunately I don’t know if it is even possible to use wallet descriptors for this - as of this discussion, I believe the answer was no, and .. is it still no?

    I guess this could be “BIP46 timelocked outputs” which wallets could support, and then another standard exists that is more flexible and supports a wider variety of use cases than just Joinmarket, later?

  26. murchandamus commented at 2:47 pm on May 28, 2024: contributor

    Good changes, thanks.

    Yes, please add a table entry to the README.mediawiki for your BIP!

    0+ |-
1+ | [[bip-0046.mediawiki|46]]
2+ | Applications
3+ | Address Scheme for Timelocked Fidelity Bonds
4+ | Chris Belcher, Thebora Kompanioni
5+ | Standard
6+ | Draft
  27. murchandamus added the label New BIP on May 31, 2024
  28. murchandamus added the label PR Author action required on May 31, 2024
  29. docs(bip-0046): add bip-0046 to readme 87bbc4aeb6
  30. docs(bip-0046): apply minor wording improvement suggestions 
    by @AdamISZ
    0a12bf8572
  31. theborakompanioni commented at 12:43 pm on June 6, 2024: contributor

    Hi @theborakompanioni , thanks for this effort.

    It also defines how to sign fidelity bond certificates, which are needed when using fidelity bonds that are stored offline.

    I don’t think this should be in the document. See:

    You’ve convinced me that specifying the exact form of the fidelity bond certificate is a bad idea. I’ll leave it more general, saying just that wallets should be able to do SignMessage using the timelocked privkey. And I’ll leave the example signature in the test vectors.

    (etc.) from here.

    Now, to be clear, I think this has already been addressed in an edit to the BIP language. Notice it has a section on Signing Messages which only refers to general principles, not to a specific format for a certificate. So my point here is only that the phrase “it defines how to sign fidelity bond certificates” should be removed. Instead perhaps “It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates”.

    Agreed, changed! Thanks :pray:

    It would be useful to be able to keep the private keys of fidelity bonds in cold storage. This would allow the sybil resistance of a system to increase without hot wallet risk.

    (minor): Language/stylistic nit: I don’t believe these standard defining documents should have “would” type statements; that’s about proposals, not definitions. So here for example you’d write “It is very useful to be able …”, “This allows ..”.

    Agreed, changed! :+1:

    \x18Bitcoin Signed Message:\n

    (very minor): is there another more unambiguous way to write the starting byte?

    Do you think 0x18 || "Bitcoin Signed Message:\n" is less ambiguous?

    I have a more general comment which I think might be very important in practice, but I’m not sure how to address:

    the document defines two things specifically, as it has to: first, the BIP32 derivation and second, the time intervals.

    • For the first point, would it be more natural to choose a specific account? (See BIP44), than a third branch (2) at the lowest level, deviating from the BIP32 standard structure of external/internal (deposit/change)? My question here is somewhat academic, this has been in place in Joinmarket for a few years. Most wallet developers wouldn’t struggle with it, but it is a significant deviation from expected wallet structure.

    A specific account does not feel more natural to me. What do others think about this?

    • For the second point, somewhat similar I guess: a specific time interval (one month) and a specific number of months feels like it’s too inflexible. To whatever extent use-cases exist for timelocked fidelity bonds outside joinmarket, it might be the case that this specific schedule is not at all workable.

    That is true. However, as mentioned in the document, this enables users to not backup timelock values.

    Importantly the user does not need to backup any timelock values.

    So I suppose this is a justified compromise between functionality and practicability. Is it?

    These two points seem like a perfect scenario for wallet descriptors, right? We have here a custom scriptPubKey format, a custom derivation, and even more, as per the above, we might realistically need to parameterise that customisation. But unfortunately I don’t know if it is even possible to use wallet descriptors for this - as of this discussion, I believe the answer was no, and .. is it still no?

    As mentioned in your link and here, JoinMarket would need to be adapted. I do not know how feasible such a change would be (also, it requires supporting the other script as well for some time, probably forever). I think this is the one (only?) remaining question to really focus on. I am agnostic to the outcome.

    I guess this could be “BIP46 timelocked outputs” which wallets could support, and then another standard exists that is more flexible and supports a wider variety of use cases than just Joinmarket, later?

    :dart: :100:

  32. AdamISZ commented at 4:43 pm on June 6, 2024: contributor

    Do you think 0x18 || “Bitcoin Signed Message:\n” is less ambiguous?

    Yeah let’s go with that. Again, very minor, but why not.

    As mentioned in your link and here, JoinMarket would need to be adapted.

    I’m really not sure.

    I don’t think I can pursue further with making any suggestion here until I’ve understood one point, as per the above stackexchange conversation; specifically, the quote

    “Strictly speaking, with just descriptors as specified in the documentation and the BIPs, it is currently not possible to create a descriptor with a timelock.”

    from @achow101 . Sure, miniscript produces a slightly different script than the one Joinmarket implemented, but why can’t there be the facility within a wallet descriptor to just specify the custom scriptPubKey? If it will be possible, then maybe we need to wait for that, if it won’t be possible, then, I guess ignore this whole line of thinking in this document and just keep everything as a rigidly defined set of times and BIP32 derivations. After all, it is correct for the isolated case of Joinmarket (but it seems a shame to write a BIP that only refers to one piece of software!).

  33. chore(bip-0046): less ambiguous message prefix style 
    by @AdamISZ
    821fb900f8
  34. chore(bip-0046): remove superfluous newline 8f0962a1ba
  35. theborakompanioni commented at 10:13 am on June 7, 2024: contributor

    Do you think 0x18 || “Bitcoin Signed Message:\n” is less ambiguous?

    Yeah let’s go with that. Again, very minor, but why not.

    Changed 👍

    As mentioned in your link and here, JoinMarket would need to be adapted.

    I’m really not sure.

    I don’t think I can pursue further with making any suggestion here until I’ve understood one point, as per the above stackexchange conversation; specifically, the quote

    “Strictly speaking, with just descriptors as specified in the documentation and the BIPs, it is currently not possible to create a descriptor with a timelock.”

    from @achow101 .

    Yep, @achow101’s input and opinion on that would be helpful and highly appreciated :pray:

    Sure, miniscript produces a slightly different script than the one Joinmarket implemented, but why can’t there be the facility within a wallet descriptor to just specify the custom scriptPubKey? If it will be possible, then maybe we need to wait for that, if it won’t be possible, then, I guess ignore this whole line of thinking in this document and just keep everything as a rigidly defined set of times and BIP32 derivations.

    Agree :100:%

    After all, it is correct for the isolated case of Joinmarket (but it seems a shame to write a BIP that only refers to one piece of software!).

    I always appreciate your writing and your way of thinking. With this, I just want to add one point, which is, that it is already extremely valuable for users to have a way to lock up coins for a specific amount of time, without the requirement of backing up any additional information. Having this widely implemented in wallets (when users urge the devs to implement it–or even switch wallets if their favorite software does not support it) is great, even if users subsequently do not make use of the additional benefits or functionality they’ll get by “proof of timelocked coins” (e.g. as Fidelity Bonds).

  36. murchandamus force-pushed on Jun 7, 2024
  37. Merge remote-tracking branch 'upstream/master' into bip-46 
    To fix the merge conflict caused by BIP 47 getting updated to final.
    1957127894
  38. murchandamus force-pushed on Jun 7, 2024
  39. murchandamus commented at 3:23 pm on June 7, 2024: contributor

    This PR had a merge conflict with the master branch due to BIP 47 getting updated to final. I merged master into this PR to resolve the merge conflict.

    It sounds like you may still be collecting feedback from @AdamISZ and possibly @achow101. Please let us know when you would like an editor to do another review.

  40. theborakompanioni commented at 6:07 pm on June 7, 2024: contributor

    This PR had a merge conflict with the master branch due to BIP 47 getting updated to final. I merged master into this PR to resolve the merge conflict.

    Nice. Thanks :pray:

    It sounds like you may still be collecting feedback from @AdamISZ and possibly @achow101. Please let us know when you would like an editor to do another review.

    Yes, I will request another review when the last remaining details have been clarified. Thank you @murchandamus

  41. theborakompanioni commented at 8:07 am on June 13, 2024: contributor
    Hey @murchandamus. Though not all options and eventualities have been fully investigated, they have been discussed well enough, therefore: Formally requesting a review. :pray:
  42. murchandamus removed the label PR Author action required on Jun 13, 2024
  43. in bip-0046.mediawiki:76 in 1957127894 outdated 
    71+</pre>
72+
73+A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further
74+in this document.
75+
76+For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner, but index does not increase forever like in other similar standards. The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check all of them if they have a balance and history.
    murchandamus commented at 4:59 pm on June 18, 2024:

    Micro-nit, please feel free to ignore if you disagree, or if you don’t need to otherwise update this BIP.

    0For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner, but index does not increase forever like in other similar standards. The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history.
  44. in bip-0046.mediawiki:133 in 1957127894 outdated 
    128+//  signature in any wallet that supports Verify Message.
129+// As mentioned before, it is more important for implementors of this standard to support signing such messages, not verifying them
130+Message       = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
131+Address       = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
132+p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
133+Signature     = H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=
    murchandamus commented at 5:15 pm on June 18, 2024:

    From what I understand, the “nth timelocked addresses” in the test vectors refer to the “UTXO key” in the above

    UTXO key ---signs---> certificate ---signs---> endpoint

    So, the second block here would appear to be a test vector of a signed certificate. If I understand that right, it might be good to add another test vector for a certificate signing an endpoint.

    Otherwise, if I misunderstood this, perhaps the test vector labels could be elaborated to clarify what we are looking at.

    theborakompanioni commented at 7:55 am on June 21, 2024:

    Hey @murchandamus! Thanks for the feedback. Yes, your are right–the block is a test vector of a signed certificate. However, I am not sure if a test vector certificate ---signs---> endpoint is suitable to be included in the BIP, as this is very application specific.

    If you want, the current method used in JoinMarket can be included, where it seems an endpoint consisting of two IRC nicknames is used (+additional information, replay protection, etc.).

    What your comment highlighted for me is that the certificate format is not properly defined (fidelity-bond-cert|<cert_pubkey>|<cert_expiry>). Especially the <cert_expiry> parameter. Is it acceptable to include this information and omit the application specific endpoint signing test vector?

    murchandamus commented at 8:52 pm on June 21, 2024:
    Given that we are still talking about a certificate that is used to participate in a Bitcoin application, I don’t see a problem. If other users do not care to use that part of the specification, they could simply omit it.
    theborakompanioni commented at 10:26 am on July 8, 2024:
    Added! :+1:
  45. murchandamus commented at 5:18 pm on June 18, 2024: contributor

    This BIP fulfills all formal criteria. I also took another look at the test vectors and was wondering whether there might still be a gap.

    Beside this open question, this BIP seems ready for merge to me.

  46. murchandamus added the label PR Author action required on Jun 18, 2024
  47. docs(bip-0046): apply minor wording improvement suggestions 
    by @murchandamus
    b7a5f9ce60
  48. docs(bip-0046): add test certificate for the 960th timelocked address 0f1eba2a60
  49. in bip-0046.mediawiki:76 in 0f1eba2a60 outdated 
    71+</pre>
72+
73+A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further
74+in this document.
75+
76+For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner, but index does not increase forever like in other similar standards. The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history.
    AdamISZ commented at 4:36 pm on June 21, 2024:
    Just a technical correction: the index does not go up forever in BIP32 and standards derived from it. It runs from 0 to 2^31 - 1 for unhardened, with the values from 2^31 to 2^32 -1 being the “hardened” equivalent.
    theborakompanioni commented at 5:21 pm on June 21, 2024:

    Thanks @AdamISZ :+1:

    Can you provide a concrete suggestion for a better wording?

    theborakompanioni commented at 7:43 pm on June 21, 2024:

    I suppose

    0-For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner, but index does not increase forever like in other similar standards.
1+For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner with a fixed upper bound:

    would be acceptable?

    murchandamus commented at 2:16 pm on June 26, 2024:
    I’m not sure whether emojis elicit a notification, so in case you didn’t see, it looks like @AdamISZ added a :+1: here. Happy to review again and presumably merge whenever you deem it ready.
    theborakompanioni commented at 10:26 am on July 8, 2024:
    Done. :+1:
  50. docs(bip-0046): apply minor wording improvement suggestions 
    by @AdamISZ
    0cdb745ee0
  51. docs(bip-0046): add cert format and clarify expiry param b916adebae
  52. docs(bip-0046): add endpoint signing example 4f788d69f5
  53. murchandamus approved
  54. murchandamus commented at 8:09 pm on July 10, 2024: contributor
    ACK, the changes look good to me
  55. murchandamus removed the label PR Author action required on Jul 12, 2024
  56. murchandamus merged this on Jul 12, 2024
  57. murchandamus closed this on Jul 12, 2024
  58. murchandamus commented at 12:17 pm on July 12, 2024: contributor
    Thank you for hanging in there @theborakompanioni, and for having @chris-belcher’s back.
  59. prusnak commented at 1:57 pm on July 12, 2024: contributor

    This goes against the spec in BIP-43, BIP-44 and BIP-84.

    Should have picked its own purpose, i.e. m/46’ and not modify already existing ones.

  60. AdamISZ commented at 3:16 pm on July 12, 2024: contributor

    This goes against the spec in BIP-43, BIP-44 and BIP-84.

    Should have picked its own purpose, i.e. m/46’ and not modify already existing ones.

    Very good point to raise, surprised it was never mentioned before.

    Obviously the original author’s intention was to “attach” these fidelity bonds to a specific wallet (and notably: though we implemented several address types in JM, we never implemented multiple address types in a single wallet), hence a new account within an existing BIP44 structure was chosen. But I do agree that alternative purpose makes a lot more sense.

    Given that as discussed at length above, this document only really currently makes sense as a standardization of Joinmarket wallets, I suggest we “half”-resolve it by adding something like:

    0To derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [44](https://github.com/theborakompanioni/bips/blob/4f788d69f501d26f6c88db7fe0cf19696b608059/bip-0084.mediawiki) but with change set to 2.
1
2m / [0/84/49]' / 0' / 0' / 2 / index
3
4The purpose field should match the wallet into which the fidelity bond is being placed (e.g. 49' for p2sh-p2wpkh, etc.). A key derived with this derivation path pattern will be referred to as derived_key further in this document...

    (side note: I guess you need to replace the BIP44 link there)

    This isn’t too relevant today as non-84 wallets are all but deprecated but any future version of Joinmarket may include taproot, so, probably not irrelevant in that sense.

  61. theborakompanioni commented at 2:22 pm on July 15, 2024: contributor

    It is quite difficult to find a balance between these things and each approach has its pros and cons. There are reasons and good arguments for both of these. I’m agnostic about the outcome, so it would be nice to gather workable suggestions so that a wallet can call itself BIP46-compatible and the “Status” of the document can move from “Draft” to “Proposed” or “Finalized” eventually.

    Should have picked its own purpose, i.e. m/46’ and not modify already existing ones.

    Besides the adaption of the purpose field of derivation path to m/46’ an additional change has been discussed to consider using script <derived_key> OP_CHECKSIGVERIFY <timelock> OP_CHECKLOCKTIMEVERIFY–effectively saving the OP_DROP statement.

    If it were to be changed, @AdamISZ it would be great for JM to support both, the (then) “old” approach, and the new agreed upon approach in this BIP. Even if it means that

    the original author’s intention was to “attach” these fidelity bonds to a specific wallet

    does not hold true any more (in the sense the statement is meant).


theborakompanioni murchandamus KamPuc86zg AdamISZ prusnak

Labels
New BIP

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-26 18:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me