[bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

See 
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e 
for the latest version of this BIP.

<pre>
   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 <belcher at riseup dot net>
   Status: Draft
   Type: Standards Track
   Comments-Summary: No comments yet.
   Created: 2022-04-01
   License: CC0-1.0
</pre>

== 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 
<tt>change</tt> set to <tt>2</tt>.

<pre>
m / 84' / 0' / 0' / 2 / index
</pre>

A key derived with this derivation path pattern will be referred to as 
<tt>derived_key</tt> further
in this document.

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.

=== Timelock derivation ===

The timelock used in the time-locked address is derived from the 
<tt>index</tt>. The timelock is a unix time. It is always the first of 
the month at midnight. The <tt>index</tt> counts upwards the months from 
January 2020, ending in December 2099. At 12 months per year for 80 
years this totals 960 timelocks. Note that care must be taken with the 
year 2038 problem on 32-bit systems.

<pre>
year = 2020 + index // 12
month = 1 + index % 12
</pre>


=== Address derivation ===

To derive the address from the above calculated public key and timelock, 
we create a <tt>redeemScript</tt> which locks the funds until the 
<tt>timelock</tt>, and then checks the signature of the 
<tt>derived_key</tt>. The <tt>redeemScript</tt> is hashed with SHA256 to 
produce a 32-byte hash value that forms the <tt>scriptPubKey</tt> of the 
P2WSH address.

     redeemScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP 
<derived_key> OP_CHECKSIG
     witness:      <signature> <pubkey>
     scriptSig:    (empty)
     scriptPubKey: 0 <32-byte-hash>
                   (0x0020{32-byte-hash})

=== Certificate message derivation ===

To create a certificate needed for using fidelity bonds in cold storage, 
another application external to this standard will create a ECDSA 
keypair. The public key of this keypair and an integer called the 
`expiry` will be used to create a certificate message.

The certificate message is defined as:

    'fidelity-bond-cert|' + cert_pubkey + '|' + cert_expiry

where + denotes concatenation. `cert_pubkey` is encoded as a hex string, 
and `cert_expiry` is encoded as an ascii string of the integer.

This certificate message is then prepended with the string `\x18Bitcoin 
Signed Message:\n` and a byte denoting the length of the certificate 
message. The whole thing is then signed with the private key of the 
<tt>derived_key</tt>. This part is identical to the "Sign Message" 
function which many wallets already implement.

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.

It is most important for wallet implementions of this standard to 
support creating the certificate signature. Verifying the certificate 
signature is less important.


== Test vectors ==

<pre>
mnemonic = abandon abandon abandon abandon abandon abandon abandon 
abandon abandon abandon abandon about
rootpriv = 
xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
rootpub  = 
xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8

// First timelocked address = m/84'/0'/0'/2/0
derived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
derived public_key  = 
02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011
unix locktime       = 1577836800
string locktime     = 2020-01-01 00:00:00
redeemscript        = 
0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac
scriptPubKey        = 
0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad
address             = 
bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84

// Test certificate using first timelocked address
// Note that as signatures contains a random nonce, it might not be 
exactly the same when your code generates it
// p2pkh address is the p2pkh address corresponding to the derived 
public key, it can be used to verify the message
//  signature in any wallet that supports Verify Message.
// As mentioned before, it is more important for implementors of this 
standard to support signing such messages, not verifying them
Message       = 
fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
Address       = 
bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
Signature     = 
H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=

// 2nd timelocked address = m/84'/0'/0'/2/1
derived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf
derived public_key  = 
02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d
unix locktime       = 1580515200
string locktime     = 2020-02-01 00:00:00
redeemscript        = 
0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac
scriptPubKey        = 
0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae
address             = 
bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h

// timelocked address after the year 2038 problem = m/84'/0'/0'/2/240
derived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe
derived public_key  = 
03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226
unix locktime       = 2208988800
string locktime     = 2040-01-01 00:00:00
redeemscript        = 
05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac
scriptPubKey        = 
0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a
address             = 
bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5

// last timelocked address = m/84'/0'/0'/2/959
derived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ
derived public_key  = 
0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3
unix locktime       = 4099766400
string locktime     = 2099-12-01 00:00:00
redeemscript        = 
0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac
scriptPubKey        = 
0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85
address             = 
bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u
</pre>

Code generating these test vectors can be found here: 
https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors

==Reference==

* 
[[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design 
for improving JoinMarket's resistance to sybil attacks using fidelity 
bonds]]
* 
[[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket 
fidelity bonds doc page]]
* [[bip-0065.mediawiki|BIP86 - OP_CHECKLOCKTIMEVERIFY]]
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic 
Wallets]]
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for 
P2WPKH-nested-in-P2SH based accounts]]
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
* [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]]

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Eric Voskuil]

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 <bitcoin-dev@lists.linuxfoundation.org> 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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[eric]

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 <ZmnSCPxj@protonmail.com>
> Sent: Tuesday, May 3, 2022 7:37 PM
> To: Eric Voskuil <eric@voskuil.org>
> Cc: Chris Belcher <belcher@riseup.net>; Bitcoin Protocol Discussion <bitcoin-
> dev@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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ]

------- 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.

Cheers,
waxwing/AdamISZ

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ]

------- Original Message -------
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Good morning waxwing,
<snip>
>
> 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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ]

> 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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

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|<pubkey>|<expiry>" and 
"fidelity-bond-cert-teleport|<pubkey>|<expiry>").

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher]

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 should work towards.
> 
> 
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[eric]

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj]

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 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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ]

> > > 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