📅 Original date posted:2019-07-28
📝 Original message:In summary I see three mechansims of making use costly:
1. burn
2. time locked funds, locker will incure opportunity cost
3. proven coin age, holder did incure opportunity cost
I dislike burn as usage of a service is infinite while coin supply is finite.
I prefer time locked funds over coin age as locked funds do not need proof of
unspentness, they can not be spent. Therefore time locked funds can be sufficiently
proven with SPV. The user of the service could post SPV proof with the request.
Regards,
Tamas Blummer
> On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:
>> A way to create a fidelity bond is to burn an amount of bitcoins by
>> sending to a OP_RETURN output. Another kind is time-locked addresses
>> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
>> sacrificed is time rather than money, but the two are related because of
>> the time-value-of-money.
>
> Timelocking bitcoins, especially for long periods, carries some special
> risks in Bitcoin:
>
> 1. Inability to sell fork coins, also creating an inability to influence
> the price signals that help determine the outcome of chainsplits.
>
> 2. Possible inability to transition to new security mechanisms if
> a major weakness is discovered in ECC or a hash function.
>
> An alternative to timelocks might be coin age---the value of a UTXO
> multiplied by the time since that UTXO was confirmed. Coin age may be
> even harder for an attacker to acquire given that it is a measure of
> past patience rather than future sacrifice. It also doesn't require
> using any particular script and so is flexible no matter what policy the
> coin owner wants to use (especially if proof-of-funds signatures are
> generated using something like BIP322).
>
> Any full node (archival or pruned) can verify coin age using the UTXO
> set.[1] Unlike script-based timelock (CLTV or CSV), there is no current
> SPV-level secure way to prove to lite clients that an output is still
> unspent, however such verification may be possible within each lite
> client's own security model related to transaction withholding attacks:
>
> - Electrum-style clients can poll their server to see if a particular
> UTXO is unspent.
>
> - BIP158 users who have saved their past filters to disk can use them to
> determine which blocks subsequent to the one including the UTXO may
> contain a spend from it. However, since a UTXO can be spent in the
> same block, they'd always need to download the block containing the
> UTXO (alternatively, the script could contain a 1-block CSV delay
> ensuring any spend occurred in a later block). If BIP158 filters
> become committed at some point, this mechanism is upgraded to SPV-level
> security.
>
>> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
>> fidelity bonds essentially for free, assuming they never intended to
>> transact with their coins much anyway.
>
> This is the thing I most like about the proposal. I suspect most
> honest makers are likely to have only a small portion of their funds
> under JoinMarket control, with the rest sitting idle in a cold wallet.
> Giving makers a way to communicate that they fit that user template
> would indeed seem to provide significant sybil resistance.
>
> -Dave
>
> [1] See, bitcoin-cli help gettxout
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190728/4428e34b/attachment-0001.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 18:19:44
in reply to nevent1q…3p4y
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 18:19:44Event JSON
{
"id": "89688edac51023a334a371f70ff1b17e5c7347be6d48bd49675ae710bc92f156",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686161984,
"kind": 1,
"tags": [
[
"e",
"e5951fd065af963dd1caf477c2dc7ac75e75b8c5de9df2bf7554616176c13878",
"",
"root"
],
[
"e",
"705c6bd9450fee25b4278d1bc34660cbf1e1b712fbdb6c02009bf3b2e163315e",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2019-07-28\n📝 Original message:In summary I see three mechansims of making use costly:\n\n1. burn\n2. time locked funds, locker will incure opportunity cost\n3. proven coin age, holder did incure opportunity cost\n\nI dislike burn as usage of a service is infinite while coin supply is finite.\n\nI prefer time locked funds over coin age as locked funds do not need proof of\nunspentness, they can not be spent. Therefore time locked funds can be sufficiently\nproven with SPV. The user of the service could post SPV proof with the request.\n\nRegards,\n\nTamas Blummer\n\n\u003e On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:\n\u003e\u003e A way to create a fidelity bond is to burn an amount of bitcoins by\n\u003e\u003e sending to a OP_RETURN output. Another kind is time-locked addresses\n\u003e\u003e created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being\n\u003e\u003e sacrificed is time rather than money, but the two are related because of\n\u003e\u003e the time-value-of-money.\n\u003e \n\u003e Timelocking bitcoins, especially for long periods, carries some special\n\u003e risks in Bitcoin:\n\u003e \n\u003e 1. Inability to sell fork coins, also creating an inability to influence\n\u003e the price signals that help determine the outcome of chainsplits.\n\u003e \n\u003e 2. Possible inability to transition to new security mechanisms if\n\u003e a major weakness is discovered in ECC or a hash function.\n\u003e \n\u003e An alternative to timelocks might be coin age---the value of a UTXO\n\u003e multiplied by the time since that UTXO was confirmed. Coin age may be\n\u003e even harder for an attacker to acquire given that it is a measure of\n\u003e past patience rather than future sacrifice. It also doesn't require\n\u003e using any particular script and so is flexible no matter what policy the\n\u003e coin owner wants to use (especially if proof-of-funds signatures are\n\u003e generated using something like BIP322).\n\u003e \n\u003e Any full node (archival or pruned) can verify coin age using the UTXO\n\u003e set.[1] Unlike script-based timelock (CLTV or CSV), there is no current\n\u003e SPV-level secure way to prove to lite clients that an output is still\n\u003e unspent, however such verification may be possible within each lite\n\u003e client's own security model related to transaction withholding attacks:\n\u003e \n\u003e - Electrum-style clients can poll their server to see if a particular\n\u003e UTXO is unspent.\n\u003e \n\u003e - BIP158 users who have saved their past filters to disk can use them to\n\u003e determine which blocks subsequent to the one including the UTXO may\n\u003e contain a spend from it. However, since a UTXO can be spent in the\n\u003e same block, they'd always need to download the block containing the\n\u003e UTXO (alternatively, the script could contain a 1-block CSV delay\n\u003e ensuring any spend occurred in a later block). If BIP158 filters\n\u003e become committed at some point, this mechanism is upgraded to SPV-level\n\u003e security.\n\u003e \n\u003e\u003e Note that a long-term holder (or hodler) of bitcoins can buy time-locked\n\u003e\u003e fidelity bonds essentially for free, assuming they never intended to\n\u003e\u003e transact with their coins much anyway.\n\u003e \n\u003e This is the thing I most like about the proposal. I suspect most\n\u003e honest makers are likely to have only a small portion of their funds\n\u003e under JoinMarket control, with the rest sitting idle in a cold wallet.\n\u003e Giving makers a way to communicate that they fit that user template\n\u003e would indeed seem to provide significant sybil resistance.\n\u003e \n\u003e -Dave\n\u003e \n\u003e [1] See, bitcoin-cli help gettxout\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190728/4428e34b/attachment-0001.sig\u003e",
"sig": "5676911680b31456ffaf260e15428c114f2d4392dc94c98eb29907b54cdcc2e546075c894fead71797dcc2fb1176545c87b1ec9eec50f75f9f8a3bbbec6e80d3"
}