Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
> > > As a better analogy: I am borrowing a piece of gold, smelting it down to > > > make > > > a nice shiny advertisement "I am totally not a bot!!", then at the end of > > > the > > > lease period, re-smelting it back and returning to you the same gold piece > > > (with the exact same atoms constituting it), plus an interest from my > > > business, > > > which gained customers because of the shiny gold advertisement claiming "I > > > am totally not a bot!!". > > > > > > That you use the same piece of gold for money does not preclude me using > > > the gold for something else of economic value, like making a nice shiny > > > advertisement, so I think your analysis fails there. > > > Otherwise, your analysis is on point, but analyses something else > > > entirely. Back to this analogy, I think it's imprecise in a way that's important to not overlook: you cannot re-use the same gold atoms in two different advertisements. Use of a fidelity bond, being basically a signature, is completely 'non-rivalrous' as I think the economists say. > Yes, that is why Tamas switched to defiads, as I had convinced him that it > would be similar enough without actually being a covenant scam like you > described. > > > In any case, I tend to agree with your other posts on the subject. For the > > burn to be provably non-dilutable it must be a cost provably associated to > > the scenario which relies upon the cost. This provides the global > > uniqueness constraint (under cryptographic assumptions of difficulty). > > > Indeed. > I suspect the only reason it is not yet a problem with existing JoinMarket > and Teleport is simply that no convenient software currently exists which > allows the same bond to be used by both, thus making it safe in practice but > not in theory. > But the theory implies that if somebody does make such software, effectively > both systems will become joined as effectively only a single identity exists > in both systems. > This may not be a problem either since the intent is that Teleport will > obsolete JoinMarket someday, but if other applications start using the same > scheme without requiring a commitment to a specific application, this may > also effectively render Teleport less useful as well. > > Regards, > ZmnSCPxj > ___ So, general comment: it seems like both you and Eric agree with my uncertain intuition up-thread and therefore do we all agree that the correct solution (to whatever extent there is one) is something like domain separation tags, as we discussed earlier? It's still a matter of social consensus: if appending "JM" to the end of a certificate signature is intended to mean that this fidelity bond can only be used in Joinmarket and not anywhere else, well we can only as individual users demand that (i.e. *I* might not accept it in Teleport, but what if Fred down the street does? It's not enough for me to rely on my own criteria!), and more subtly, it makes sense only if we all have an unambiguous definition of what Joinmarket *is* - ironically it is precisely the thing brought most into question by the achievement of real decentralization in a system. Cheers, waxwing/AdamISZ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning e, > Good evening ZmnSCPxj, > > Sorry for the long delay... Thank you very much for responding. > > > Good morning e, > > > > > Good evening ZmnSCPxj, > > > > > > For the sake of simplicity, I'll use the terms lender (Landlord), borrower > > > (Lessor), interest (X), principal (Y), period (N) and maturity (height > > > after N). > > > > > > The lender in your scenario "provides use" of the principal, and is paid > > > interest in exchange. This is of course the nature of lending, as a period > > > without one's capital incurs an opportunity cost that must be offset (by > > > interest). > > > > > > The borrower's "use" of the principal is what is being overlooked. To > > > generate income from capital one must produce something and sell it. > > > Production requires both capital and time. Borrowing the principle for the > > > period allows the borrower to produce goods, sell them, and return the > > > "profit" as interest to the lender. Use implies that the borrower is > > > spending > > > the principle - trading it with others. Eventually any number of others > > > end up > > > holding the principle. At maturity, the coin is returned to the lender (by > > > covenant). At that point, all people the borrower traded with are bag > > > holders. > > > Knowledge of this scam results in an imputed net present zero value for > > > the > > > borrowed principal. > > > > But in this scheme, the principal is not being used as money, but as a > > billboard > > for an advertisement. > > > > Thus, the bitcoins are not being used as money due to the use of the > > fidelity > > bond to back a "you can totally trust me I am not a bot!!" assertion. > > This is not the same as your scenario --- the funds are never transferred, > > instead, a different use of the locked funds is invented. > > > > As a better analogy: I am borrowing a piece of gold, smelting it down to > > make > > a nice shiny advertisement "I am totally not a bot!!", then at the end of > > the > > lease period, re-smelting it back and returning to you the same gold piece > > (with the exact same atoms constituting it), plus an interest from my > > business, > > which gained customers because of the shiny gold advertisement claiming "I > > am totally not a bot!!". > > > > That you use the same piece of gold for money does not preclude me using > > the gold for something else of economic value, like making a nice shiny > > advertisement, so I think your analysis fails there. > > Otherwise, your analysis is on point, but analyses something else entirely. > > > Ok, so you are suggesting the renting of someone else's proof of "burn" > (opportunity cost) to prove your necessary expense - the financial equivalent > of your own burn. Reading through the thread, it looks like you are > suggesting this as a way the cost of the burn might be diluted across > multiple uses, based on the obscuration of the identity. And therefore > identity (or at least global uniqueness) enters the equation. Sounds like a > reasonable concern to me. > > It appears that the term "fidelity bond" is generally accepted, though I find > this an unnecessarily misleading analogy. A bond is a loan (capital at risk), > and a fidelity bond is also capital at risk (to provide assurance of some > behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely > demonstration of a prior expense. But in those cases, the expense is provably > associated. As you have pointed out, if the burn is not associated with the > specific use, it can be reused, diluting the demonstrated expense to an > unprovable degree. Indeed, that is why defiads used the term "advertisement" and not "fidelity bond". One could say that defiads was a much-too-ambitious precursor of this proposed scheme. > I can see how you come to refer to selling the PoB as "lending" it, because > the covenant on the underlying coin is time constrained. But nothing is > actually lent here. The "advertisement" created by the covenant (and its > presumed exclusivity) is sold. This is also entirely consistent with the idea > that a loan implies capital at risk. While this is nothing more than a > terminology nit, the use of "fidelity bond" and the subsequent description of > "renting" (the fidelity bond) both led me down another path (Tamas' proposal > for risk free lending under covenant, which we discussed here years ago). Yes, that is why Tamas switched to defiads, as I had convinced him that it would be similar enough without actually being a covenant scam like you described. > In any case, I tend to agree with your other posts on the subject. For the > burn to be provably non-dilutable it must be a cost provably associated to > the scenario which relies upon the cost. This provides the global uniqueness > constraint (under cryptographic assumptions of difficulty). Indeed. I suspect the only reason it is not *yet* a problem with existing JoinMarket and Teleport is simply th
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good evening ZmnSCPxj, Sorry for the long delay... > Good morning e, > > > Good evening ZmnSCPxj, > > > > For the sake of simplicity, I'll use the terms lender (Landlord), borrower > > (Lessor), interest (X), principal (Y), period (N) and maturity (height > > after N). > > > > The lender in your scenario "provides use" of the principal, and is paid > > interest in exchange. This is of course the nature of lending, as a period > > without one's capital incurs an opportunity cost that must be offset (by > > interest). > > > > The borrower's "use" of the principal is what is being overlooked. To > > generate income from capital one must produce something and sell it. > > Production requires both capital and time. Borrowing the principle for the > > period allows the borrower to produce goods, sell them, and return the > > "profit" as interest to the lender. Use implies that the borrower is > > spending > > the principle - trading it with others. Eventually any number of others end > > up > > holding the principle. At maturity, the coin is returned to the lender (by > > covenant). At that point, all people the borrower traded with are bag > > holders. > > Knowledge of this scam results in an imputed net present zero value for the > > borrowed principal. > > But in this scheme, the principal is not being used as money, but as a > billboard > for an advertisement. > > Thus, the bitcoins are not being used as money due to the use of the fidelity > bond to back a "you can totally trust me I am not a bot!!" assertion. > This is not the same as your scenario --- the funds are never transferred, > instead, a different use of the locked funds is invented. > > As a better analogy: I am borrowing a piece of gold, smelting it down to make > a nice shiny advertisement "I am totally not a bot!!", then at the end of the > lease period, re-smelting it back and returning to you the same gold piece > (with the exact same atoms constituting it), plus an interest from my > business, > which gained customers because of the shiny gold advertisement claiming "I > am totally not a bot!!". > > That you use the same piece of gold for money does not preclude me using > the gold for something else of economic value, like making a nice shiny > advertisement, so I think your analysis fails there. > Otherwise, your analysis is on point, but analyses something else entirely. Ok, so you are suggesting the renting of someone else's proof of "burn" (opportunity cost) to prove your necessary expense - the financial equivalent of your own burn. Reading through the thread, it looks like you are suggesting this as a way the cost of the burn might be diluted across multiple uses, based on the obscuration of the identity. And therefore identity (or at least global uniqueness) enters the equation. Sounds like a reasonable concern to me. It appears that the term "fidelity bond" is generally accepted, though I find this an unnecessarily misleading analogy. A bond is a loan (capital at risk), and a fidelity bond is also capital at risk (to provide assurance of some behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely demonstration of a prior expense. But in those cases, the expense is provably associated. As you have pointed out, if the burn is not associated with the specific use, it can be reused, diluting the demonstrated expense to an unprovable degree. I can see how you come to refer to selling the PoB as "lending" it, because the covenant on the underlying coin is time constrained. But nothing is actually lent here. The "advertisement" created by the covenant (and its presumed exclusivity) is sold. This is also entirely consistent with the idea that a loan implies capital at risk. While this is nothing more than a terminology nit, the use of "fidelity bond" and the subsequent description of "renting" (the fidelity bond) both led me down another path (Tamas' proposal for risk free lending under covenant, which we discussed here years ago). In any case, I tend to agree with your other posts on the subject. For the burn to be provably non-dilutable it must be a cost provably associated to the scenario which relies upon the cost. This provides the global uniqueness constraint (under cryptographic assumptions of difficulty). Best, e > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning Chris, > Yes linking the two identities (joinmarket maker and teleport maker) > together slightly degrades privacy, but that has to be balanced against > the privacy loss of leaving both systems open to sybil attacks. Without > fidelity bonds the two systems can be sybil attacked just by using about > five-figures USD, and the attack can get these coins back at any time > when they're finished. I am not saying "do not use fidelity bonds at all", I am saying "maybe we should disallow a fidelity bond used in JoinMarket from being used in Teleport and vice versa". Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Hello ZmnSCPxj, You say "A taker can be a surveillor as well", as though that's simple and easy to achieve. In reality there are many defenses against that. Defending against the attack of a malicious taker aborting at the last step is the purpose of the podle commitments which joinmarket has implemented since 2016. This was in response to this attack actually taking place. Another important point is that this attack cant happen secretly, it is very obvious to everyone operating a maker that it happens. The podle defense means that an attacker doing this will constantly have to spend money on miner fees to create new UTXOs. Here's a writeup with links to other blog posts about the whole thing: https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b As well as podle as mitigation, the multiple mixdepths in the joinmarket wallet also helps a lot because it's not trivial for an attacker to actually learn all the UTXOs in all 5 mixdepths, which is necessary for the attack to work. Mitigation in Teleport works in a slightly different way: takers can only see UTXOs or transactions belonging to the maker once they have already gotten their own transaction confirmed. So if they were to abort the protocol early they would not only have spent miner fees but also waste their own time waiting for the OP_CSV timeout. It's worth remembering that the fidelity bond UTXOs are not linked to any resulting coinjoin or coinswaps on-chain. Yes linking the two identities (joinmarket maker and teleport maker) together slightly degrades privacy, but that has to be balanced against the privacy loss of leaving both systems open to sybil attacks. Without fidelity bonds the two systems can be sybil attacked just by using about five-figures USD, and the attack can get these coins back at any time when they're finished. Regards CB On 13/05/2022 13:44, ZmnSCPxj wrote: Good morning Chris, Hello waxwing, A user sacrifices X amount of time-value-of-money (henceforth TVOM) by committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z > X. But as an assessor of FB1 in Joinmarket, I don't know if it's also being used for Teleport, and more importantly, if it's being used somewhere else I'm not even aware of. Now I'm not an economist I admit, so I might not be intuit-ing this situation right, but it fees to me like the right answer is "It's fine for a closed system, but not an open one." (i.e. if the set of possible usages is not something that all participants have fixed in advance, then there is an effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed value 100 is there, whereas actually it's only 15, or whatever.) I don't entirely agree with this. The value of the sacrifice doesn't change if the fidelity bond owner starts using it for Teleport as well as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run any maker at all the sacrifice would still be 100, because it only depends on the bitcoin value and locktime. In your equation Y+Z > X, using a fidelity bond for more applications increases the left-hand-side, while the right-hand-side X remains the same. As protection from a sybil attack is calculated using only X, it makes no difference what Y and Z are, the takers can still always calculate that "to sybil attack the coinjoin I'm about to make, it costs A btc locked up for B time". I think another perspective here is that a maker with a single fidelity bond between both Teleport and Joinmarket has a single identity in both systems. Recall that not only makers can be secretly surveillors, but takers can also be secretly surveillors. Ideally, the maker should not tie its identity in one system to its identity in another system, as that degrades the privacy of the maker as well. And the privacy of the maker is the basis of the privacy of its takers. It is the privacy of the coins the maker offers, that is being purchased by the takers. A taker can be a surveillor as well, and because the identity between JoinMarket and Teleport is tied via the single shared fidelity bond, a taker can perform partial-protocol attacks (i.e. aborting at the last step) to identify UTXOs of particular makers. And it can perform attacks on both systems to identify the ownership of maker coins in both systems. Since the coins in one system are tied to that system, this increases the information available to the surveillor: it is now able to associate coins in JoinMarket with coins in Teleport, via the shared fidelity bond identity. It would be acceptable for both systems to share an identity if coins were shared between the JoinMarket and Teleport maker clients, but at that point they would arguably be a single system, not two separate systems, and that is what you
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning Chris, > Hello waxwing, > > > A user sacrifices X amount of time-value-of-money (henceforth TVOM) > > by committing in Joinmarket with FB1. He then uses the same FB1 in > Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, > and benefit Z in Teleport, then presumably he'll only do it if > (probabilistically) he thinks Y+Z > X. > > > But as an assessor of FB1 in Joinmarket, I don't know if it's also > > being used for Teleport, and more importantly, if it's being used > somewhere else I'm not even aware of. Now I'm not an economist I admit, > so I might not be intuit-ing this situation right, but it fees to me > like the right answer is "It's fine for a closed system, but not an open > one." (i.e. if the set of possible usages is not something that all > participants have fixed in advance, then there is an effective Sybilling > problem, like I'm, as an assessor, thinking that sacrificed value 100 is > there, whereas actually it's only 15, or whatever.) > > > I don't entirely agree with this. The value of the sacrifice doesn't > change if the fidelity bond owner starts using it for Teleport as well > as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run > any maker at all the sacrifice would still be 100, because it only > depends on the bitcoin value and locktime. In your equation Y+Z > X, > > using a fidelity bond for more applications increases the > left-hand-side, while the right-hand-side X remains the same. As > protection from a sybil attack is calculated using only X, it makes no > difference what Y and Z are, the takers can still always calculate that > "to sybil attack the coinjoin I'm about to make, it costs A btc locked > up for B time". I think another perspective here is that a maker with a single fidelity bond between both Teleport and Joinmarket has a single identity in both systems. Recall that not only makers can be secretly surveillors, but takers can also be secretly surveillors. Ideally, the maker should not tie its identity in one system to its identity in another system, as that degrades the privacy of the maker as well. And the privacy of the maker is the basis of the privacy of its takers. It is the privacy of the coins the maker offers, that is being purchased by the takers. A taker can be a surveillor as well, and because the identity between JoinMarket and Teleport is tied via the single shared fidelity bond, a taker can perform partial-protocol attacks (i.e. aborting at the last step) to identify UTXOs of particular makers. And it can perform attacks on both systems to identify the ownership of maker coins in both systems. Since the coins in one system are tied to that system, this increases the information available to the surveillor: it is now able to associate coins in JoinMarket with coins in Teleport, via the shared fidelity bond identity. It would be acceptable for both systems to share an identity if coins were shared between the JoinMarket and Teleport maker clients, but at that point they would arguably be a single system, not two separate systems, and that is what you should work towards. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Hello waxwing, > A user sacrifices X amount of time-value-of-money (henceforth TVOM) by committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z > X. > But as an assessor of FB1 in Joinmarket, I don't know if it's also being used for Teleport, and more importantly, if it's being used somewhere else I'm not even aware of. Now I'm not an economist I admit, so I might not be intuit-ing this situation right, but it fees to me like the right answer is "It's fine for a closed system, but not an open one." (i.e. if the set of possible usages is not something that all participants have fixed in advance, then there is an effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed value 100 is there, whereas actually it's only 15, or whatever.) I don't entirely agree with this. The value of the sacrifice doesn't change if the fidelity bond owner starts using it for Teleport as well as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run any maker at all the sacrifice would still be 100, because it only depends on the bitcoin value and locktime. In your equation Y+Z > X, using a fidelity bond for more applications increases the left-hand-side, while the right-hand-side X remains the same. As protection from a sybil attack is calculated using only X, it makes no difference what Y and Z are, the takers can still always calculate that "to sybil attack the coinjoin I'm about to make, it costs A btc locked up for B time". Regarding fidelity bonds being used for both, I expect that most fidelity bond owners will use their bonds with both Joinmarket and Teleport, to not do that is just leaving money on the table. If an attacker locks up the 100k btc or whatever the requirement is now, and actually does a successful sybil attack against Joinmarket, then they could at the same time do a successful sybil attack against teleport with little added cost. So both markets form a single fidelity bond ecosystem. This is a similar situation to merge-mining bitcoin with an altcoin that also uses SHA256^2 for proof of work. The two or more coins form one mining ecosystem. This results in the users of the small altcoin benefiting from having their transactions protected by bitcoin's massive hashrate. In this analogy the new small Teleport system can very quickly benefit from the large amount of fidelity bonds already used in Joinmarket. Yes the hypothetical attacker can attack all systems at once, but the defenders can defend all systems at once (and we can say not just that they "can" do it, but that they "will" do it, or else they leave money on the table). The mathematics which gives a huge advantage to the defender still applies. 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. I've made edits to this effect on the gist: https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e/revisions#diff-4f1f364f340b78bdfe9dca2ff50784bd312d49be220e5e5c2e4675447f79c6e8 It's worth noting that even if the certificate message is different across the two systems, a fidelity bond owner can still create two signatures over two different messages (e.g. "fidelity-bond-cert||" and "fidelity-bond-cert-teleport||"). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
> I suppose ultimately this brings up the question of the scope of this BIP. > The abstract points out that the BIP contains both a definition of address > derivation, but also how to sign fidelity bond certificates. > > My feeling is that the latter might be better not included? I note that the > 'Motivation' section gives motivation for standardisation of derivation (this > includes things like time schedule), but not the second area - certificate > signing. I think the second area is much more tricky, but much more to the > point is, isn't it the case that that second area, can be interpreted without > consensus between wallet developers? So say you were a hardware wallet > provider, or a "node in a box" provider - your customers want you to provide > the ability move funds around, including e.g. moving funds out of an old > Joinmarket wallet (in which say there is a now expired timelock address utxo) > by just entering its BIP39 seed. If this BIP addresses that, it should be > enough. > > I don't doubt that there's gains to be had from a broader community > discussing and agreeing the details of how to create a fidelity bond > certificate, but it's a separate, and more difficult, task. > > Cheers, > waxwing/AdamISZ Further to that last point, as the BIP draft currently says: " Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ascii string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages." So, isn't that an argument that we don't need to specify the certificate message format here? On the other hand, I can hardly disagree that it's worth presenting a kind of 'default' way of doing it. But I fear it is not at all simple to decide what a secure, general format should be (as per the discussion we started having here about domain separation tags). Cheers, waxwing/AdamISZ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
--- Original Message --- On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev wrote: > Good morning waxwing, > > Ah, yes, now I remember. > I discussed this with Tamas as well in the past and that is why we concluded > that in defiads, each UTXO can host at most one advertisement at any one time. > In the case of defiads there would be a sequence counter where a > higher-sequenced advertisement would replace lower-sequenced advertisement, > so you could update, but at any one time, for a defiads node, only one > advertisement per UTXO could be used. > This assumed that there would be a defiads network with good gossip > propagation so our thinking at the time was that a higher-sequenced > advertisement would quickly replace lower-sequenced ones on the network. > But it is simpler if such replacement would not be needed, and you could then > commit to the advertisement directly on the UTXO via a tweak. > > Each advertisement would also have a specific application ID that it applied > to, and applications on top of defiads would ask the local defiads node to > give it the ads that match a specific application ID, so a UTXO could only be > used for one application at a time. > This would be equivalent to domain separation tags that waxwing mentions. > > Regards, > ZmnSCPxj > I suppose ultimately this brings up the question of the scope of this BIP. The abstract points out that the BIP contains both a definition of address derivation, but also how to sign fidelity bond certificates. My feeling is that the latter might be better not included? I note that the 'Motivation' section gives motivation for standardisation of derivation (this includes things like time schedule), but not the second area - certificate signing. I think the second area is much more tricky, but much more to the point is, isn't it the case that that second area, can be interpreted without consensus between wallet developers? So say you were a hardware wallet provider, or a "node in a box" provider - your customers want you to provide the ability move funds around, including e.g. moving funds out of an old Joinmarket wallet (in which say there is a now expired timelock address utxo) by just entering its BIP39 seed. If this BIP addresses that, it should be enough. I don't doubt that there's gains to be had from a broader community discussing and agreeing the details of how to create a fidelity bond certificate, but it's a separate, and more difficult, task. Cheers, waxwing/AdamISZ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning waxwing, > --- Original Message --- > On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Hello ZmnSCPxj, > > This is an intended feature. I'm thinking that the same fidelity bond > > can be used to running a JoinMarket maker as well as a Teleport > > (Coinswap) maker. > > I don't believe it's abusable. It would be a problem if the same > > fidelity bond is used by two makers in the same application, but > > JoinMarket takers are already coded to check for this, and Teleport > > takers will soon as well. Using the same bond across different > > applications is fine. > > Best, > > CB > > Hi Chris, Zmn, list, > I've noodled about this a few times in the past (especially when trying to > figure out an LSAG style ring sig based FB for privacy, but that does not > seem workable), and I can't decide the right perspective on it. > > A user sacrifices X amount of time-value-of-money (henceforth TVOM) by > committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, > let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z > in Teleport, then presumably he'll only do it if (probabilistically) he > thinks Y+Z > X. > > But as an assessor of FB1 in Joinmarket, I don't know if it's also being used > for Teleport, and more importantly, if it's being used somewhere else I'm not > even aware of. Now I'm not an economist I admit, so I might not be intuit-ing > this situation right, but it fees to me like the right answer is "It's fine > for a closed system, but not an open one." (i.e. if the set of possible > usages is not something that all participants have fixed in advance, then > there is an effective Sybilling problem, like I'm, as an assessor, thinking > that sacrificed value 100 is there, whereas actually it's only 15, or > whatever.) > > As I mentioned in > https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059 > , I did wonder about domain separation tags because of this, and as I > vaguely alluded to there, I'm really not sure about it. > > If it was me I'd want to include domain separation via part of the signed > message, since I don't see how it hurts? For scenarios where reuse is fine, > reuse can still happen. Ah, yes, now I remember. I discussed this with Tamas as well in the past and that is why we concluded that in defiads, each UTXO can host at most one advertisement at any one time. In the case of defiads there would be a sequence counter where a higher-sequenced advertisement would replace lower-sequenced advertisement, so you could update, but at any one time, for a defiads node, only one advertisement per UTXO could be used. This assumed that there would be a defiads network with good gossip propagation so our thinking at the time was that a higher-sequenced advertisement would quickly replace lower-sequenced ones on the network. But it is simpler if such replacement would not be needed, and you could then commit to the advertisement directly on the UTXO via a tweak. Each advertisement would also have a specific application ID that it applied to, and applications on top of defiads would ask the local defiads node to give it the ads that match a specific application ID, so a UTXO could only be used for one application at a time. This would be equivalent to domain separation tags that waxwing mentions. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
--- Original Message --- On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev wrote: > Hello ZmnSCPxj, > > This is an intended feature. I'm thinking that the same fidelity bond > can be used to running a JoinMarket maker as well as a Teleport > (Coinswap) maker. > > I don't believe it's abusable. It would be a problem if the same > fidelity bond is used by two makers in the same application, but > JoinMarket takers are already coded to check for this, and Teleport > takers will soon as well. Using the same bond across different > applications is fine. > > Best, > CB > Hi Chris, Zmn, list, I've noodled about this a few times in the past (especially when trying to figure out an LSAG style ring sig based FB for privacy, but that does not seem workable), and I can't decide the right perspective on it. A user sacrifices X amount of time-value-of-money (henceforth TVOM) by committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z > X. But as an assessor of FB1 in Joinmarket, I don't know if it's also being used for Teleport, and more importantly, if it's being used somewhere else I'm not even aware of. Now I'm not an economist I admit, so I might not be intuit-ing this situation right, but it fees to me like the right answer is "It's fine for a closed system, but not an open one." (i.e. if the set of possible usages is not something that all participants have fixed in advance, then there is an effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed value 100 is there, whereas actually it's only 15, or whatever.) As I mentioned in https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059 , I did wonder about domain separation tags because of this, and as I vaguely alluded to there, I'm really not sure about it. If it was me I'd want to include domain separation via part of the signed message, since I don't see how it hurts? For scenarios where reuse is fine, reuse can still happen. Cheers, waxwing/AdamISZ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning e, > Good evening ZmnSCPxj, > > For the sake of simplicity, I'll use the terms lender (Landlord), borrower > (Lessor), interest (X), principal (Y), period (N) and maturity (height after > N). > > The lender in your scenario "provides use" of the principal, and is paid > interest in exchange. This is of course the nature of lending, as a period > without one's capital incurs an opportunity cost that must be offset (by > interest). > > The borrower's "use" of the principal is what is being overlooked. To > generate income from capital one must produce something and sell it. > Production requires both capital and time. Borrowing the principle for the > period allows the borrower to produce goods, sell them, and return the > "profit" as interest to the lender. Use implies that the borrower is spending > the principle - trading it with others. Eventually any number of others end > up holding the principle. At maturity, the coin is returned to the lender (by > covenant). At that point, all people the borrower traded with are bag > holders. Knowledge of this scam results in an imputed net present zero value > for the borrowed principal. But in this scheme, the principal is not being used as money, but as a billboard for an advertisement. Thus, the bitcoins are not being used as money due to the use of the fidelity bond to back a "you can totally trust me I am not a bot!!" assertion. This is not the same as your scenario --- the funds are never transferred, instead, a different use of the locked funds is invented. As a better analogy: I am borrowing a piece of gold, smelting it down to make a nice shiny advertisement "I am totally not a bot!!", then at the end of the lease period, re-smelting it back and returning to you the same gold piece (with the exact same atoms constituting it), plus an interest from my business, which gained customers because of the shiny gold advertisement claiming "I am totally not a bot!!". That you use the same piece of gold for money does not preclude me using the gold for something else of economic value, like making a nice shiny advertisement, so I think your analysis fails there. Otherwise, your analysis is on point, but analyses something else entirely. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good evening ZmnSCPxj, For the sake of simplicity, I'll use the terms lender (Landlord), borrower (Lessor), interest (X), principal (Y), period (N) and maturity (height after N). The lender in your scenario "provides use" of the principal, and is paid interest in exchange. This is of course the nature of lending, as a period without one's capital incurs an opportunity cost that must be offset (by interest). The borrower's "use" of the principal is what is being overlooked. To generate income from capital one must produce something and sell it. Production requires both capital and time. Borrowing the principle for the period allows the borrower to produce goods, sell them, and return the "profit" as interest to the lender. Use implies that the borrower is spending the principle - trading it with others. Eventually any number of others end up holding the principle. At maturity, the coin is returned to the lender (by covenant). At that point, all people the borrower traded with are bag holders. Knowledge of this scam results in an imputed net present zero value for the borrowed principal. While the lack of usability is a cost to the lender, it is not a benefit to the borrower. The lender incurs no risk, and will obtain no reward - as the loan is of no value. Failure to deploy capital is an opportunity cost, and locking it up is not deployment. Now, even if we accept the generous (economically irrational) assumption that money must increase in price (i.e. trades from more goods) over any given period, we are still left with the observation that the presumed appreciation would accrue to the lender absent lending, making it pointless. e > -Original Message- > From: ZmnSCPxj > Sent: Tuesday, May 3, 2022 7:37 PM > To: Eric Voskuil > Cc: Chris Belcher ; Bitcoin Protocol Discussion d...@lists.linuxfoundation.org> > Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for > BIP39 seeds > > Good morning e, > > > > It looks like you are talking about lending where the principal return is > guaranteed by covenant at maturity. This make the net present value of the > loan zero. > > I am talking about lending where: > > * Lessor pays landlord X satoshis in rent. > * Landlord provides use of the fidelity bond coin (value Y) for N blocks. > * Landlord gets the entire fidelity bond amount (Y) back. > > Thus, the landlord gets X + Y satoshis, earning X satoshis, at the cost of > having Y > satoshis locked for N blocks. > > So I do not understand why the value of this, to the landlord, would be 0. > Compare to a simple HODL strategy, where I lock Y satoshis for N blocks and > get Y satoshi back. > Or are you saying that a simple HODL strategy is of negative value and that > "zero value" is the point where you actively invest all your savings? > Or are you saying that HODL strategy is of some value since it still allows > you > to spend funds freely in the N blocks you are HODLing them, and the option to > spend is of value, while dedfinitely locking the value Y for N blocks is > equal to > the value X of the rent paid (and thus net zero value)? > > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning e, > It looks like you are talking about lending where the principal return is > guaranteed by covenant at maturity. This make the net present value of the > loan zero. I am talking about lending where: * Lessor pays landlord X satoshis in rent. * Landlord provides use of the fidelity bond coin (value Y) for N blocks. * Landlord gets the entire fidelity bond amount (Y) back. Thus, the landlord gets X + Y satoshis, earning X satoshis, at the cost of having Y satoshis locked for N blocks. So I do not understand why the value of this, to the landlord, would be 0. Compare to a simple HODL strategy, where I lock Y satoshis for N blocks and get Y satoshi back. Or are you saying that a simple HODL strategy is of negative value and that "zero value" is the point where you actively invest all your savings? Or are you saying that HODL strategy is of some value since it still allows you to spend funds freely in the N blocks you are HODLing them, and the option to spend is of value, while dedfinitely locking the value Y for N blocks is equal to the value X of the rent paid (and thus net zero value)? Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
It looks like you are talking about lending where the principal return is guaranteed by covenant at maturity. This make the net present value of the loan zero. e > On May 3, 2022, at 11:03, Chris Belcher via bitcoin-dev > wrote: > > Hello ZmnSCPxj, > > Such a system will have to be publicly advertised, in the same way we see > centralized cryptocurrency staking shops buying ads all over the place. > That's how they'll make retail hodlers aware that renting out your coins in > this way is possible. If JoinMarket/Teleport users notice such ads appearing > then we could change the taker code to remove the intermediate certificate > keypair, and have the fidelity bond UTXO key sign the endpoint (IRC nickname > or onion hostname) directly. This removes the possibility of fidelity bonds > in cold storage. It would have to be done for privacy, and it wouldn't be too > bad. Right now there's no cold storage solution for fidelity bonds yet > JoinMarket has about 600 bitcoins locked up and advertised, which must be all > on hot wallets. > > Best, > CB > >> On 03/05/2022 06:26, ZmnSCPxj wrote: >> Good morning Chris, >>> Hello ZmnSCPxj, >>> >>> Renting out fidelity bonds is an interesting idea. It might happen in >>> the situation where a hodler wants to generate yield but doesn't want >>> the hassle of running a full node and yield generator. A big downside of >>> it is that the yield generator income is random while the rent paid is a >>> fixed cost, so there's a chance that the income won't cover the rent. >> The fact that *renting* is at all possible suggests to me that the following >> situation *could* arise: >> * A market of lessors arises. >> * A surveillor creates multiple identities. >> * Each fake identity rents separately from multiple lessors. >> * Surveillor gets privacy data by paying out rent money to the lessor market. >> In defiads, I and Tamas pretty much concluded that rental would happen >> inevitably. >> One could say that defiads was a kind of fidelity bond system. >> Our solution for defiads was to prioritize propagating advertisements >> (roughly equivalent to the certificates in your system, I think) with larger >> bonded values * min(bonded_time, 1 year). >> However, do note that we did not intend defiads to be used for >> privacy-sensitive applications like JoinMarket/Teleport. >> Regards, >> ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Hello ZmnSCPxj, Such a system will have to be publicly advertised, in the same way we see centralized cryptocurrency staking shops buying ads all over the place. That's how they'll make retail hodlers aware that renting out your coins in this way is possible. If JoinMarket/Teleport users notice such ads appearing then we could change the taker code to remove the intermediate certificate keypair, and have the fidelity bond UTXO key sign the endpoint (IRC nickname or onion hostname) directly. This removes the possibility of fidelity bonds in cold storage. It would have to be done for privacy, and it wouldn't be too bad. Right now there's no cold storage solution for fidelity bonds yet JoinMarket has about 600 bitcoins locked up and advertised, which must be all on hot wallets. Best, CB On 03/05/2022 06:26, ZmnSCPxj wrote: Good morning Chris, Hello ZmnSCPxj, Renting out fidelity bonds is an interesting idea. It might happen in the situation where a hodler wants to generate yield but doesn't want the hassle of running a full node and yield generator. A big downside of it is that the yield generator income is random while the rent paid is a fixed cost, so there's a chance that the income won't cover the rent. The fact that *renting* is at all possible suggests to me that the following situation *could* arise: * A market of lessors arises. * A surveillor creates multiple identities. * Each fake identity rents separately from multiple lessors. * Surveillor gets privacy data by paying out rent money to the lessor market. In defiads, I and Tamas pretty much concluded that rental would happen inevitably. One could say that defiads was a kind of fidelity bond system. Our solution for defiads was to prioritize propagating advertisements (roughly equivalent to the certificates in your system, I think) with larger bonded values * min(bonded_time, 1 year). However, do note that we did not intend defiads to be used for privacy-sensitive applications like JoinMarket/Teleport. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning Chris, > Hello ZmnSCPxj, > > Renting out fidelity bonds is an interesting idea. It might happen in > the situation where a hodler wants to generate yield but doesn't want > the hassle of running a full node and yield generator. A big downside of > it is that the yield generator income is random while the rent paid is a > fixed cost, so there's a chance that the income won't cover the rent. The fact that *renting* is at all possible suggests to me that the following situation *could* arise: * A market of lessors arises. * A surveillor creates multiple identities. * Each fake identity rents separately from multiple lessors. * Surveillor gets privacy data by paying out rent money to the lessor market. In defiads, I and Tamas pretty much concluded that rental would happen inevitably. One could say that defiads was a kind of fidelity bond system. Our solution for defiads was to prioritize propagating advertisements (roughly equivalent to the certificates in your system, I think) with larger bonded values * min(bonded_time, 1 year). However, do note that we did not intend defiads to be used for privacy-sensitive applications like JoinMarket/Teleport. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Hello ZmnSCPxj, Renting out fidelity bonds is an interesting idea. It might happen in the situation where a hodler wants to generate yield but doesn't want the hassle of running a full node and yield generator. A big downside of it is that the yield generator income is random while the rent paid is a fixed cost, so there's a chance that the income won't cover the rent. JoinMarket takers since the start have checked that a fidelity bond doesn't appear twice. The technique doesn't deserve a section in the BIP because this BIP is only about specifying the wallets that hold fidelity bond UTXOs for makers, not takers which receive fidelity bond messages. In JoinMarket this is done in this code here: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/6b05f65260a487cd22f175ba64d499fbe8122530/jmclient/jmclient/taker.py#L1020-L1021 Best, CB On 01/05/2022 12:41, ZmnSCPxj wrote: Good morning again Chris, I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I am interested in application A, you are interested in application B, and you rent my fidelity bond for application B. We can use a pay-for-signature protocol now that Taproot is available, so that the signature for the certificate for your usage of application B can only be completed if I reveal a secret via a signature on another Taproot UTXO that gets me the rent for the fidelity bond. I do not know if this would count as "abuse" or just plain "economic sensibility". But a time may come where people just offer fidelity bonds for lease without actually caring about the actual applications it is being used *for*. If the point is simply to make it costly to show your existence, whether you pay for the fidelity bond by renting it, or by acquiring your own Bitcoins and foregoing the ability to utilize it for some amount of time (which should cost closely to renting the fidelity bond from a provider), should probably not matter economically. You mention that JoinMarket clients now check for fidelity bonds not being used across multiple makers, how is this done exactly, and does the technique not deserve a section in this BIP? Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning again Chris, I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I am interested in application A, you are interested in application B, and you rent my fidelity bond for application B. We can use a pay-for-signature protocol now that Taproot is available, so that the signature for the certificate for your usage of application B can only be completed if I reveal a secret via a signature on another Taproot UTXO that gets me the rent for the fidelity bond. I do not know if this would count as "abuse" or just plain "economic sensibility". But a time may come where people just offer fidelity bonds for lease without actually caring about the actual applications it is being used *for*. If the point is simply to make it costly to show your existence, whether you pay for the fidelity bond by renting it, or by acquiring your own Bitcoins and foregoing the ability to utilize it for some amount of time (which should cost closely to renting the fidelity bond from a provider), should probably not matter economically. You mention that JoinMarket clients now check for fidelity bonds not being used across multiple makers, how is this done exactly, and does the technique not deserve a section in this BIP? Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Hello ZmnSCPxj, This is an intended feature. I'm thinking that the same fidelity bond can be used to running a JoinMarket maker as well as a Teleport (Coinswap) maker. I don't believe it's abusable. It would be a problem if the same fidelity bond is used by two makers in the _same_ application, but JoinMarket takers are already coded to check for this, and Teleport takers will soon as well. Using the same bond across different applications is fine. Best, CB On 01/05/2022 10:43, ZmnSCPxj wrote: Good morning Chris, Excellent BIP! From a quick read-over, it seems to me that the fidelity bond does not commit to any particular scheme or application. This means (as I understand it) that the same fidelity bond can be used to prove existence across multiple applications. I am uncertain whether this is potentially abusable or not. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
Good morning Chris, Excellent BIP! >From a quick read-over, it seems to me that the fidelity bond does not commit >to any particular scheme or application. This means (as I understand it) that the same fidelity bond can be used to prove existence across multiple applications. I am uncertain whether this is potentially abusable or not. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds
See https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e for the latest version of this BIP. BIP: TBD. Preferably a two-digit number to match the bip44, bip49, bip84, bip86 family of bips Layer: Applications Title: Derivation scheme for storing timelocked address fidelity bonds in BIP39 phrases Author: Chris Belcher Status: Draft Type: Standards Track Comments-Summary: No comments yet. Created: 2022-04-01 License: CC0-1.0 == Abstract == This BIP defines the derivation scheme for BIP39 seed phrases 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. == Motivation == Fidelity bonds are used to resist sybil attacks in certain decentralized anonymous protocols. They are created by locking up bitcoins using the `OP_CHECKLOCKTIMEVERIFY` opcode. It would be useful to have a common derivation scheme so that users of wallet software can have a backup of their fidelity bonds by storing only the BIP39 seed phrase and a reference to this BIP. Importantly the user does not need to backup any timelock values. We largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation. This standard is already implemented and deployed in JoinMarket. As most changes would requires a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all. == Background == === Fidelity bonds === A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. A way to create a fidelity bond is to lock up bitcoins by sending them to a timelocked address. The valuable thing being sacrificed is the time-value-of-money. The sacrifice must be done in a way that can be proven to a third party. This proof can be made by showing the UTXO outpoint, the address redeemscript and a signature which signs a message using the private key corresponding to the public key in the redeemscript. The sacrificed value is an objective measurement that can't be faked and which can be verified by anybody (just like, for example PoW mining). Sybil attacks can be made very expensive by forcing a hypothetical sybil attacker to lock up many bitcoins for a long time. JoinMarket implements fidelity bonds for protection from sybil attackers. At the time of writing over 600 BTC in total have been locked up with some for many years. Their UTXOs and signatures have been advertised to the world as proof. We can calculate that for a sybil attacker to succeed in unmixing all the CoinJoins, they would have to lock up over 100k BTC for several years. === Fidelity bonds in cold storage === It would be useful to be able to keep the private keys of timelocked addresses in cold storage. This would allow the sybil resistance of a system to increase without hot wallet risk. For this reason there is an intermediate keypair called the certificate. UTXO key ---signs---> certificate ---signs---> endpoint (e.g. IRC nickname or tor .onion hostname) The certificate keypair can be kept online and used to prove ownership of the fidelity bond. Even if the hot wallet private keys are stolen, the coins in the timelocked address will still be safe, although the thief will be able to impersonate the fidelity bond until the expiry. === Fixed timelock values === It would be useful for the user to avoid having to keep a record of the timelocks in the time-locked addresses. So only a limited small set of timelocks are defined by this BIP. This way the user must only store their seed phrase, and knowledge that they have coins stored using this BIP standard. The user doesn't need to remember or store any dates. == Specifications == This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate can be signed by the deterministic address key. === Public key derivation === To derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with change set to 2. m / 84' / 0' / 0' / 2 / index A key derived with this derivation path pattern will be referred to as derived_key further in this document. For index, 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 959 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. === Timelock derivation === The timelock
