Tamas Blummer [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-27 to 2019-09-21
💬 Posted a total of 179 messages
📚 Participated in the following categories: Bitcoin-development, Libbitcoin, bitcoin-dev, patch, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8

Profile Code

nprofile1qqsvvv5yzejlendt7qsny2caj62nnjwplq5uamfcs3875f8g2y5k94cprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdpsf9t2

Publishing to

relay.noswhere.com

Author Public Key

npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8

Show more details

Last Notes

2023-06-09 12:53:39

- reply

📅 Original date posted:2018-12-28
📝 Original message:
Hi ZmnSCPxj,
You are right that an exchange can not simply embed the option into the offer price as there is no payment in case the offer is not taken, so nothing would pay for their hedging costs.
This however is not a unique situation, but people deal with it frequently. Every offer has a timespan within which the market maker can not back out, and in your language writes a free option.
That timespan might be very short on an electronic trading platform or rather long in trade finance. Bid-ask spreads of the offer reflect that and those making the offers manage or at least limit the market and liquidity risk of outstanding offers.
Just because there is no trustless automated solution in sight, we should not assume things will not exist. In contrary, this imperfection will invite people offering a service for profit.
Tamas Blummer
> On Dec 28, 2018, at 22:22, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hi ZmnSCPxj,
>
> Making an asset swap offer using HTLC ties up funds and the offer may be taken up-until the timelock expiry.
> Therefore making such an offer implies both opportunity cost and a premium for optional exercise.
>
> There is no mechanism in LN to require compensation for above costs, therefore you imply that no sane person would make such an offer.
>
> I think, that instead exchanges will still make such offers but with an exchange rate between the assets that compensate them for the cost they incure by making the offer.
> Exchanges will also limit the quantity of outstanding offers, so they can manage the risk of options written. This might lead to making offers only to known traders or to those,
> who pay for receiving an offer with a regular LN payment in-advance.
>
> Tamas Blummer
>
>
>
>> On Dec 28, 2018, at 04:34, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning Tamas,
>>
>>> Although there is no escape from above reasoning, a market maker could still be profitable as long as the option is worth less than the bid-ask spread.
>>> Therefore the issue does not mean that LN cross asset exchange is not feasible, but that there is lower bound on bid-ask spread, that of the option premium.
>>
>> The option premium cannot be charged in the not-exercised branch.
>> This is effectively a premium-free option.
>> This means that rational entities who know of this technique will create options "for free" until the exchange runs out of liquidity.
>> This is because, even if the exchange rate does not go beyond the bid-ask spread, the not-exercised branch is free of charge.
>>
>> Since all their liquidity is tied up in premium-free American Call Options, exchange nodes cannot usefully bridge between a BTC Lightning Network and any other asset.
>> Routing attempts will usually fail.
>> In a very practical sense, it would not be possible to create a multi-asset LN.
>>
>>
>> --
>>
>> I had long ago figured out that HTLCs can create American Call Options (more than a year ago).
>> The problem was that they tied up the assets involved into the contract, so I never bothered to publish this insight.
>> However, on LN, HTLCs are created "for free" with no payment, which is a significant advantage to the user of an American Call Option, who would be quite willing to tie up their funds in HTLCs since the not-exercised branch of the American Call Option formed was free of premium.
>> Their only cost is opportunity cost, and on the LN, with tiny tiny tiny fees, opportunity cost of having the funds free is very small.
>> One can say that the opportunity cost is the premium paid, but note that it is not paid to the exchange, since the exchange itself is also forced to tie up its other asset into another HTLC (meaning it also pays the opportunity cost).
>>
>> What I suspect will happen is that the LN on the weaker asset (i.e. less popular, fewer users, etc.) will find itself unable to be paid by the LN on the stronger asset.
>> This will weaken the weaker asset even further (users will leave it for the stronger asset).
>> This creates a shift in exchange rate, which is precisely what the American Call Options are waiting for.
>> These American Call Options drain funds from the exchange, until the exchange stops being profitable and stops operating as an exchange, again further weakening the weaker asset as it is now even harder to pay from the stronger asset network to the weaker asset network, and so on.
>>
>>
>> Regards,
>> ZmnSCPxj
>

2023-06-09 12:53:39

- reply

📅 Original date posted:2018-12-28
📝 Original message:
Hi ZmnSCPxj,
Making an asset swap offer using HTLC ties up funds and the offer may be taken up-until the timelock expiry.
Therefore making such an offer implies both opportunity cost and a premium for optional exercise.
There is no mechanism in LN to require compensation for above costs, therefore you imply that no sane person would make such an offer.
I think, that instead exchanges will still make such offers but with an exchange rate between the assets that compensate them for the cost they incure by making the offer.
Exchanges will also limit the quantity of outstanding offers, so they can manage the risk of options written. This might lead to making offers only to known traders or to those,
who pay for receiving an offer with a regular LN payment in-advance.
Tamas Blummer
> On Dec 28, 2018, at 04:34, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Tamas,
>
>> Although there is no escape from above reasoning, a market maker could still be profitable as long as the option is worth less than the bid-ask spread.
>> Therefore the issue does not mean that LN cross asset exchange is not feasible, but that there is lower bound on bid-ask spread, that of the option premium.
>
> The option premium cannot be charged in the not-exercised branch.
> This is effectively a premium-free option.
> This means that rational entities who know of this technique will create options "for free" until the exchange runs out of liquidity.
> This is because, even if the exchange rate does not go beyond the bid-ask spread, the not-exercised branch is free of charge.
>
> Since all their liquidity is tied up in premium-free American Call Options, exchange nodes cannot usefully bridge between a BTC Lightning Network and any other asset.
> Routing attempts will usually fail.
> In a very practical sense, it would not be possible to create a multi-asset LN.
>
>
> --
>
> I had long ago figured out that HTLCs can create American Call Options (more than a year ago).
> The problem was that they tied up the assets involved into the contract, so I never bothered to publish this insight.
> However, on LN, HTLCs are created "for free" with no payment, which is a significant advantage to the user of an American Call Option, who would be quite willing to tie up their funds in HTLCs since the not-exercised branch of the American Call Option formed was free of premium.
> Their only cost is opportunity cost, and on the LN, with tiny tiny tiny fees, opportunity cost of having the funds free is very small.
> One can say that the opportunity cost is the premium paid, but note that it is not paid to the exchange, since the exchange itself is also forced to tie up its other asset into another HTLC (meaning it also pays the opportunity cost).
>
> What I suspect will happen is that the LN on the weaker asset (i.e. less popular, fewer users, etc.) will find itself unable to be paid by the LN on the stronger asset.
> This will weaken the weaker asset even further (users will leave it for the stronger asset).
> This creates a shift in exchange rate, which is precisely what the American Call Options are waiting for.
> These American Call Options drain funds from the exchange, until the exchange stops being profitable and stops operating as an exchange, again further weakening the weaker asset as it is now even harder to pay from the stronger asset network to the weaker asset network, and so on.
>
>
> Regards,
> ZmnSCPxj
-------------- 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/lightning-dev/attachments/20181228/af759a5d/attachment.sig>

2023-06-09 12:53:37

- reply

📅 Original date posted:2018-12-27
📝 Original message:
ZmnSCPxj,
Brilliant reasoning. I sum it up to make it more accessible:
Failing to route on purpose can be used to opt out of a previously agreed exchange of two differents assets.
A rational actor will opt out if the exchange is no longer fair. Anyone who grants an option for free heads financial disaster.
This is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point.
Although there is no escape from above reasoning, a market maker could still be profitable as long as the option is worth less than the bid-ask spread.
Therefore the issue does not mean that LN cross asset exchange is not feasible, but that there is lower bound on bid-ask spread, that of the option premium.
Tamas Blummer
> On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network
>
> Introduction
> ============
>
> In theory, the Lightning Network could potentially perform "seamless" currency conversions, allowing a payer to spend one currency to pay a payee requesting for another currency.
> However, a significant technical barrier prevents implementation of such feature as of current designs (late 2018) for Lightning.
>
> The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments.
> HTLCs can be used across cryptocurrency systems to transfer value between them.
> From this point-of-view, every single Lightning Network channel is a cryptocurrency system whose custodians are two entities, who are the only entities who can use the system (the single Lightning Network channel).
> HTLCs allow cross-system trades to be performed, so that participation on any single Lightning Network channel can be leveraged to participation over the entire Lightning Network.
>
> However, HTLCs can also be used to construct American Call Options.
> Further, due to UX concerns, on the Lightning Network, there is no cost incurred in merely setting up HTLCs for routing.
> By using the low-level HTLCs provided as primitives by Lightning Network, one can set up American Call Options.
> These on-Lightning American Call Options, however, can be "purchased" for free (gratis), thus potentially earning money in a completely risk-free manner.
> Abusing this gratis ability means that any Lightning Network node advertising cross-asset on-Lightning exchange will find large amounts of its liquidity tied up in stalled forwarding payments (in reality, American Call Options) with a risk of monetary loss in case of large fluctuations in exchange rate.
>
> Hashlocked Timelocked Contracts as American Call Options
> ========================================================
>
> An American CallOption is a right (but not obligation) to purchase an asset at a specific price, on or before an expiration date.
> HTLCs allow building American Call Options.
>
> Suppose we have Bitcoin, and some other asset, and both are on blockchains that support the same hash function and can define HTLCs.
> It is unimportant if both are on the same blockchain, or on different blockchains, since HTLCs can work across cryptocurrency systems.
>
> An American Call Option has these properties:
>
> 1. `P` = the price at which the asset can be purchased.
> 2. `E` = the date at which the option expires.
>
> Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget (WJT) on the WJT blockchain.
> We would then do the below ritual:
>
> 1. You provide me a hash of some secret preimage that only you know.
> 2. You make an HTLC on the Bitcoin blockchain.
> The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.
> 3. I make an HTLC on the WJT blockchain.
> The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.
>
> On or before `E`, you can claim the WJT on the WJT blockchain by providing a transaction that reveals the preimage.
> Since the preimage is now revealed, I can then claim the Bitcoins of price `P` on the Bitcoin blockchain.
> Alternately, you can simply not exercise this right, and at time `E` I would then reclaim my WJT, and at time `E` + 1 day you would reclaim your bitcoins.
>
> Of course, I want to *sell* this contract to you, so you would have to pay me some bitcoins before we set up the above.
> A multi-stage construction of transactions that go through HTLC-like constructs can be done on both blockchains to ensure that the above contracts appear on both chains only if the payment for the actual contract (i.e. the "premium") is done, and to enforce that both contracts appear if the premium is paid, but that is beyond the scope of *this* writeup, which will focus on how Lightning Network HTLCs can form the above construction without any premium being paid.
>
> HTLCs For Routing
> =================
>
> HTLCs can be used to enforce trades across different cryptocurrency systems.
> This property is used to allow routing of payments across different channels.
> Each channel is its own cryptocurrency system.
>
> Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I wanted to sell you my service of facilitating payments on Lightning.
> Suppose you want to pay to somebody, who, for the sake of convenience, we shall randomly call YAIjbOJA.
> As it happens, I have a channel with you, and a channel with YAIjbOJa.
>
> You need to pay YAIjbOJA `P` bitcoins.
> We then perform the below ritual:
>
> 1. YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.
> 2. On your channel with me, you set up an HTLC.
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash you were given, and the timelock is 2 days from now.
> 3. On my channel with YAIjbOJA, I set up an HTLC.
> The value is `P`, the hash is the same hash as above, and the timelock is 1 day from now.
>
> (in reality, the timelocks are parameterized and selected by the payer (you), and LN nodes will impose some "reasonable" limits on the timelocks; but the first HTLCs set up must have longer timelocks than the later HTLCs)
>
> Afterward, YAIjbOJA may claim, or may not claim, the money in the HTLC by releasing (or not releasing) the hash to me.
> If YAIjbOJA claims the money, then I can take the hash and claim the money, plus fee, from you.
> If not, then this is a payment failure and I will then cancel the HTLC you offered using standard Lightning Network primitives.
>
> In general, we expect that YAIjbOJA wants to have the money because every randomly-generated imaginary entity likes money.
> Thus, in the case of payments, YAIjbOJA has a strong incentive to claim the money without waiting for the timelock to expire or nearly expire.
> We can see that in practice, on the current Lightning Network, HTLCs are often very transient and will be quickly claimed, despite having long timelocks.
>
> This speed may mislead us into thinking that such convenience may be possible across different assets.
>
> Cross-Asset Lightning Nodes Offer Premium-Free American Call Options
> ====================================================================
>
> Suppose that Lightning Network supports multiple assets.
> Each channel has a single asset.
> Some nodes will advertise themselves as providing exchange capability, taking one asset on one channel and exchanging it for another asset on a different channel.
>
> Suppose I advertise myself as such an exchange.
> Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on hand to pay YAIjbOJA, only bitcoins.
> As it happens, I have a bitcoin channel with you and a WJT channel with YAIjbOJA.
> I advertise myself as exchanging `P` bitcoins for 1 WJT as of the current time.
>
> Further suppose that in reality, YAIjbOJA is *you*, random Internet person reading my thoughts.
>
> You, your fake persona YAIjbOJA, and me, then perform the following ritual:
>
> 1. YAIjbOJA (really you) provides you with a hash whose preimage only YAIjbOJA (actually you) know. (i.e. you just make it up)
> 2. On the bitcoin channel with me, you set up an HTLC.
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash that "YAIjbOJA" gave you (i.e. you really just made it up), and the timelock is 2 days from now.
> 3. On the WJT channel with YAIjbOJA (really you), I set up an HTLC.
> The value is 1 WJT, the hash is the hash you gave me, and the timelock is 1 day from now.
>
> The above is now the same as the setup for an American Call Option with expiration of 1 day from now.
> Further, within certain limits, you can set up the expiration of the American Call Option to be longer or shorter.
> Thus, I have inadvertently given you an American Call Option, for *no premium* (completely gratis), when my only intent was to facilitate cross-currency Lightning Network payments.
>
> Suppose that the price of 1 WJT rises far above the price of `P`+1 bitcoins before the expiration (1 day from now).
> In such a case, "YAIjbOJA" (really you) will then release the hash and acquire the 1 WJT.
> You then close this channel and claim the WJT onchain, then sell it immediately to earn more than the `P`+1 bitcoins you paid.
> Alternatively, presumably I would have a new exchange rate I would be willing to exchange WJT for, and you can just send the WJT with the new exchange rate immediately over the Lightning Network.
>
> Suppose that the price of WJT does not rise.
> Since this is an option and *not* a future, "YAIjbOJA" (really you) will simply claim that the payment errored somewhere and cancel the HTLCs.
> Since even payment errors are not unwrappable and are onion-wrapped, I cannot determine whether the payment really errored, or you were just setting up an American Call Option that you have now decided not to exercise.
>
> Premium-free American Call Options Are Risk-free Earning Pumps
> ==============================================================
>
> Traditionally, options are analyzed assuming that the option itself has a price, the premium.
> This premium is the risk of the user of the option.
> If the user of the option does not exercise the option before the expiration, then the premium is a pure loss of the user.
>
> However, the above setup does not involve any payment when the option is not exercised.
> Payment failures are "free" (gratis) on the Lightning Network.
> However, payment failures are also the non-exercised branch of the American Call Option that can be set up on a cross-currency on-Lightning exchange.
>
> Because the American Call Option is premium-free, even if the expiration is very near, rational entities will still construct such options.
> Extreme volatility may occur in short time frames, especially in the realm of digital assets.
>
> Thus, it is strongly likely that, if cross-asset exchange nodes on Lightning Network exist, they will be exploited to create risk-free American Call Options.
> They will find that significant liquidity will be tied up in such American Call Options, and find that they will lose funds especially at times of volatility.
>
> We can try to mitigate this, but the solutions below all have significant drawbacks.
>
> 1. We could force that setting up the HTLCs requires payment.
> This forces the above American Call Options to have a premium.
> The effect, however, is that routing failure is not free.
> The current Lightning Network works despite not everyone publishing the balances of channels, precisely because routing failure is free.
> We only need to have one route succeed in order to actually successfully pay to the payee.
> With non-free routing failure, we cannot try many routes until one succeeds.
> * Suppose we limited this only to cross-asset exchanges.
> It would still require accurate knowledge of channel balances.
> This is because if a payment fails on a hop *after* the exchange, the payer still loses money from that attempt to the exchange node.
> 2. Exchange nodes could increase their fees.
> This would create a wider "spread" of buying and selling assets.
> This spread would increase friction in crossing assets.
> Also, this would only reduce risk; if the exchange rate is volatile enough, then the option could still be exercised for riskless earnings.
> Rational entities will still tie up most of the liquidity on the exchange on riskless American Call Options; even if the exchange rate is very stable, they lose nothing.
> 3. Exchange nodes could limit the timelock of cross-asset swaps.
> This would increase friction in crossing assets, since a timelock limit also imposes a limit to the route length.
> If one asset is much stronger than the other, then the weaker asset will find its part of the Lightning Network to be strongly centralized around the exchanges between the two assets.
> Payees of the weaker asset will strongly prefer to be at most one hop away from exchanges in order to viably receive payments from payers who are using the stronger asset.
> Again, rational entities will also still tie up most of the liquidity on the exchange on riskless American Call Options; again, even if the exchange rate is very stable in short time frames, they lose nothing anyway.
>
> Conclusion
> ==========
>
> HTLCs allow creation of American Call Options.
> The same HTLCs are used in Lightning Network to route across channels.
> If using a single asset, there is no issue related to time.
> Regardless of the value of bitcoin relative to any other asset, in the future, 1 BTC is 1 BTC.
>
> However, across assets, the ability of HTLCs to create American Call Options becomes troublesome.
> These can then be exploited to earn money from exercise of the option.
> Further, because Lightning UX would be degraded otherwise, payment failures are free (gratis), leading to the American Call Options also being free of premium.
> This means that creating such options would be riskless, allowing potential earnings upon any strong volatility of exchange rates.
>
> This implies that a multi-asset Lightning Network may not be economically viable.
> Instead, Lightning Network would strongly prefer having a single asset across the network.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-07 18:20:41

- reply

📅 Original date posted:2019-09-21
📝 Original message:Hi Aleksey,
Yes, BIP158 uses the block hash to seed the hash function, which makes distinct block filters non-aggregatable
for common values. Aggregate fiters on ranges of blocks would have to use some other seed and then
achive significant savings using the same design.
I think that the most likely use of filters is to decide if a newly announced block should be downloaded and
not scanning over the entire chain, where aggregate filters would help. I also suspect that whole chain
scans would be better served with plain sequential reads in map-reduce style.
Typical clients do not care of filters for blocks before the birth date of their wallet’s keys, so they skip over the
majority of history which is a bigger saving than any aggregate filter.
I wish we get a filter committed as commitment would unlock more utility than any marginal savings through
more elaborate design.
Tamas Blummer
> On Sep 19, 2019, at 19:20, admin--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> Here is a link for a draft of a BIP for compact probabilistic block filters alternative of BIP 158
>
> https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing <https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing>
>
> Summary:
>
> - BIP 158 false positive rate is low, we can achieve lower bandwidth with higher false positive rate filter while sync blockchain
>
> - BIP 158 not do not support filter batching by design of used parameters for siphash and Golomb coding optimal parameters
>
> - Alternative compression with delta coding and splitting data to 2 bit string sequences. First for data without prefixes, second one for information about bit length written to first sequence.
> Second sequence have a lot of duplicates, compressed with 2 round of Huffman algorithm. (Effectivity about 98% vs Golomb with optimal parameters)
>
> - Block filters batching reduce filter size significantly
>
> - Separation of filters by address type allows lite client not to download redundant information without compromising privacy.
>
> - Lite client filters download strategy: get biggest filter (smallest blocks/size rate) for blocks range, in case positive test -> get medium filters to reduce blocks range -> get block filters for affected range -> download affected blocks over TOR
>
> Implementation (python): https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172 <https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172>
>
> Exactly information from mainnet about size for separated filters by address types and batch size will be added within few days.
>
> Thanks for any feedback.
> Aleksey Karpov
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190921/ecea43cc/attachment.html>

2023-06-07 18:20:32

- reply

📅 Original date posted:2019-09-14
📝 Original message:I introduced you to the pattern of a side memory to bitcoin in [1] and
promised an implementation of it.
Here you are.
defiads is a side memory network to bitcoin, implemented in Rust, built
on top of rust-bitcoin, murmel, hammersbald, rust-bitcoinconsenus,
rust-wallet, all Rust open source free to grab at
https://github.com/defiads/defiads
defiads builds a peer-to-peer network to distribute textual ads, as
first suggested by ZmnSCPxj[4]. I hope that it will serve
decentralized finance applications with an infrastructure to distribute
ads, order books, coinjoin proposals etc.
Every defiads node maintains a copy of a network-wide shared 1GB memory
pool of current ads.
An ad is replicated to other nodes as long as there is some bitcoin
locked to it on the bitcoin network. Locking means someone transferred
some sats to an address that is associated with the ad using the
pay-to-contract protocol[2]. The address does not release the bitcoins
until a predefined time span that is the duration of the advertizement,
this is accomplished with OP_CSV. The ad will be evicted from the pool
as soon as the coins locked to it are spendable again.
defiads ranks advertizements by the ratio of used space divided by
bitcoins locked and will only replicate the top 1GB of this ranked list.
You may read the ads by starting a defiads process of your own and
the query the content through its JSON-RPC API.
You may place ads by performing the following steps, with its JSON-RPC API
1. deposit some bitcoins into your defiads node's wallet
2. prepare an ad, providing its category, abstract and content
3. fund the ad by locking some of the bitcoins to it for a limited term
of the advertizement
4. you may withdraw your coins from the defiads node's wallet after the
advertizement expires
defiads handles the association with ads, locking and unlocking coins.
Implementation notes
defiads connects to both the bitcoin and its own peer-to-peer network.
You do not need to run a bitcoin node as defiads only needs a small
fraction of the information on the bictoin blockchain and retrieves that
on its own, as an SPV node.
The defiads node's wallet is compatibe with that of TREZOR, Ledger,
Greenwallet and many other wallets that support BIP38, BIP44, BIP48,
BIP84 key generation and use standards.
defiads uses Invertible Bloom Lookup Tables[3] to synchronize the ads
pool with its peers.
Status
It seems to work, but you should not yet use with real bitcoins,
therefore by default it connects the bitcoin's test network.
There is no discovery for the network yet, so you will have to know some
peer in the network to see other than your own ads. Write me a direct
email if you'd like to connect to my node.
Future developent
Should the use become popular then 1GB pool become tight, then people
will have to compete for its use. Some might not have enough bitcoin's
to lock and might therefore pay others to lock theirs to fund an
advertizement. defiads network could match both sides and thereby give
rise to bitcoin's first truly risk less interest rate market.
defiads is currently downloading, but not storing,
the blocks after its birth date. This will no longer be needed once
BIP158 filters are served and committed by Bitcoin Core.
I hope that someone builds a nice UI on top of the JSON RPC as that is
not my area of expertise.
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017264.html
[2] https://arxiv.org/pdf/1212.3257.pdf
[3] https://arxiv.org/pdf/1101.2245.pdf
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html

2023-06-07 18:20:18

- reply

📅 Original date posted:2019-08-13
📝 Original message:It appears to me that there is a generic design pattern for peer to peer networks,
that we might call side memory.
The name is justified with some similarity to side chains. Side memory is however
not about a persistent store, but some transient memory of an other peer to peer network.
The UTXO set is the shared transient memory of the bitcoin network.
Just like we can link the bitcoin block chain with a side chain, we can link
the transient memory of an other network with the UTXO set of bitcoin.
The other network’s transient memory would hold an item until a uniquelly associated
a coin in the UTXO set is unspent. There are many ways to associate data with
an UTXO. How this is done is not a concern here. The method must however allow
the coin to be spent again, so the UTXO set can also trigger eviction of the associated
data from the other network’s memory.
The utility of such association is to impose control and the scarcity of bitcoin to
some other network’s transient memory.
Since the number of possible UTXOs is huge (21 million * 100million) an
associated peer to peer network will want to raise the bar for UTXOs eligible
to enter its store.
An obvious choice for raising the bar is requiring more satoshis to be committed.
The other network may dynamically tailor this requirement or let users compete
for a fixed capacity by committing higher amounts.
Observing the UTXO set is however not a cheap operation. Nodes of the other
network would have to also run a bitcoin node to be sure they do not miss
changes of the UTXO.
There is however a way to significantly simplify this task by using time locks and
SPV validation as follows:
The UTXO committing to associated data would have a relative timelock, such that
it can not be spent within n blocks after it entered the UTXO set. (with OP_CSV)
A network node that originally publishes the data would also send an SPV proof
of the inclusion of associated commitment into the bitcoin blockchain to its peers.
Other network nodes would therefore only need to observe the progress of
bitcoin’s header chain to validate the proof, which is the commitment transaction
and the path to merkle root, before accepting data into their transient store.
The commitment transaction also tells them how long the output can not be spent,
therefore they are relived the burden of watching for UTXO spends. Instead they
can evict the associated data from their transient store as soon as the header
chain they oberve is progressed past the relative locktime.
Nodes that publish new data would have to listen to all blocks after they
broadcast the commitment, until they see it confirmed and can extract the proof.
This could be further optimized if BIP158 filters were available and committed.
The network nodes could use IBLTs (Invertible Bloom Lookup Tables) to distribute
associated data.
Such an associated network would be lightweight since only observing and
storing bitcoin’s header chain and its own peer to peer network.
I will soon release the code of a network that implements this design pattern,
with the SPV optimization and IBLTs, and am looking for help to test it in a
limited deployment, before letting it out into the wild.
Please drop me a mail if you’d like to help there.
Prior art that I summed up as side memory:
The idea of linking names with UTXO goes back to the first fork of Bitcoin and
was significantly upgraded in the numerifides proposal[1] of tyzbit
ZmnSCPxj proposed an advertizement network in which the network's content
is controlled by associated UTXOs in [2].
I observed that time locked commitments would uncover to bitcoin’s internal
riskless interest rate [3].
The pattern is useful as sybill attack protection of coinjoin networks as time locked
commitments can act as fidelity bonds [4]
Regards,
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001207.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017169.html
-------------- 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/20190814/fc771022/attachment.sig>

2023-06-07 18:19:44

- reply

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

2023-06-07 18:19:44

- reply

📅 Original date posted:2019-07-28
📝 Original message:Hi David,
Aquiring coin age is hard not only for an attacker but for any user that
happened to move his funds lately.
Even if coin age is available, proofs of using it to fund a particular operation
are not sybill resistant. Only a centralized service would know for sure that
proof is only used once and such centralization would defeat the purpose.
In contrast time locking such that it is uniquely linked with the operation
is always possible as funds could also be rented to lock in a decentralized manner.
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/496e9d8c/attachment-0001.sig>

2023-06-07 18:19:42

- reply

📅 Original date posted:2019-07-26
📝 Original message:Hi Chris,
yes, fidelity bonds can impose cost to make sybill attacks more expensive therefore less likely.
I prefer the flavor with CHECKSEQUENCEVERIFY which imposes opportunity cost, just as effective
as burning, but is sustainable.
Imposing opportunity costs however requires larger time locked amounts than burning and the
user might not have sufficient funds to do so. This is however not a restriction but an opportunity
that can give rise to an additional market of locking UTXOs in exchange of a payment.
This would give rise to a transparent interest rate market for Bitcoin an additional huge benefit.
Regards,
Tamas Blummer
> On Jul 25, 2019, at 13:47, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
>
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
>
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
>
> ## Introduction
>
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin output.
>
> ### Sybil attacks
>
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
>
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
>
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
>
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
>
> ### Liquidity
>
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
>
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
>
> What is needed is a way to increase the cost of running in a maker in a
> way that retains the anonymity and is attractive to long-term holders of
> bitcoin. This can be done using time-locked addresses.
>
> ## Fidelity bonds
>
> In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is
> deliberately sacrificed to make a cryptographic identity expensive to
> obtain. The sacrifice is done in a way that can be proven to a third party.
>
> 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.
>
> Under this system, makers would sacrifice an amount of bitcoins and
> publish a proof along with their coinjoin offers. Takers would choose
> maker offers based on the sacrificed amount (as well as other factors),
> knowing that a sybil attacker would also have to sacrifice a certain
> amount of coins in order to unmix the taker's coinjoins. The sacrifice
> would be an objective measurement that can't be faked and which can be
> verified by anybody (just like, for example PoW mining)
>
> 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. A long-term holder probably won't
> want to attack a system like JoinMarket which makes his own investment
> coins more private and more fungible.
>
> ### Fidelity bonds in cold storage
>
> The private keys of fidelity bonds can be kept offline. Signatures
> potentially only need to be made when the timelock expires (every 6
> months for example), or only once in the case of OP_RETURN burned coins.
> This allows JoinMarket's sybil resistance to increase without the hot
> wallet risk.
>
> Burned coin signatures should still have a lifetime, in case the private
> key associated with the IRC nick (which is online) is stolen, so that
> the thief of that privkey can't impersonate the maker indefinitely. The
> signature linking the burned coins and IRC nick could expire after
> perhaps 6 months.
>
> ### Anonymity
>
> Under this scheme makers would need to publish the transactions of their
> fidelity bonds to the entire world. Those transactions could be subject
> to blockchain analysis. So before makers do this they should make sure
> their coins are anonymous (possibly by mixing with JoinMarket). Also if
> they ever want to use their coins for something else apart from fidelity
> bonds they should mix them.
>
> ### Value of a fidelity bond
>
> See the other document (Financial mathematics of joinmarket fidelity
> bonds)[4] for a formula expressing the value of a fidelity bond.
>
> The value of a fidelity bond made by sending V bitcoins to a burner
> address is:
>
> V^2
>
> The amount of bitcoins is squared to get the fidelity bond value. This
> has the effect that economic-rational makers have a strong incentive to
> lump up all their coin sacrifices together into one maker bot, not to
> split it up over several bots.
>
> The value of a fidelity bond made by locking up V bitcoins in a
> time-locked address for time period T is:
>
> V^2 (exp(rT) - 1)^2
>
> To get an idea of the numbers, if we burn 2 btc then the value of the
> fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a
> bitcoin interest rate r = 0.001 (0.1%) per year, then the value of that
> fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That
> is a relatively small valued bond. It can be increased by locking up
> more bitcoins for longer (up to and including permanant locking via a
> burner transaction).
>
> ## Taker algorithm for choosing makers
>
> I suggest the following taker peer choosing algorithm: obtain the list
> of offers and discard offers which the taker's user deems are too
> expensive. One of the remaining offers is randomly chosen with weighting
> determined by the fidelity bond value. Once an offer is chosen it is
> removed from the list, and another offer is again randomly chosen, this
> is repeated until the taker has chosen the desired number of
> fidelity-bonded maker's offers.
>
> Some people run makers not for profit but for their own privacy.
> Therefore not all makers should be required to have bonds, because such
> privacy-makers are useful to include in coinjoins too. We could have
> taker allow say, an eighth (12.5%), of their coinjoin peers to be makers
> without bonds. They can be chosen randomly from the orderbook without
> any weighting based on fidelity bond values. Of course these are easy to
> fake by an adversary so they dont contribute much to sybil resistance.
>
> ### Cost of sybil attacks
>
> See the other document (Cost of sybil attacks) for discussion and
> calculations on the sybil resistance given by the above maker-choosing
> algorithm.
>
> It can be calculated that the fidelity bond system dramatically
> increases the cost of a sybil attack. With real-world data and realistic
> assumptions we can calculate that a sybil attacker would need to lock up
> 30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner
> addresses to have a good chance of attacking the system by being all the
> counterparties in everyone's coinjoin.
>
> ## Effect of fidelity bonds on CoinJoin fees
>
> Someone might ask "why would anyone lock up coins for months or more,
> let alone burn coins forever, just to run a maker bot". The only way
> this would even happen is if makers can generate a higher income that
> justifies the fidelity bond sacrifice. That higher income can only come
> from taker's coinjoin fees (or possibly coinswap fees one day). We can
> expect that makers with higher valued fidelity bonds will demand higher
> coinjoin fees. So a big question is whether takers will accept paying
> higher coinjoin fees. I think they will, because right now coinjoin fees
> are only 10-1000 satoshi, and a far biggest cost of coinjoins is the
> miner fee not the coinjoin fee. I'm pretty sure takers will recognize
> that they get what they pay for, and that additional privacy is well
> worth the cost. Any other takers reading this should definitely let me
> know what they think.
>
> ## Technical ideas
>
> JoinMarket's wallet could also create time-locked addresses. Locktimes
> should be fixed to be midnight on the first day of each month, then each
> public key corresponds to 12 addresses per year (1200 addresses per
> century) which is very practical to all be monitored as watch-only
> addresses. These wallets can be created offline and could safely hold
> time-locked bitcoins.
>
> The timelocked addresses public key can be used to sign an IRC nickname
> proving that the nickname is the real owner of the TXO. OP_RETURN
> outputs used for burning coins can include a pubkey hash used for the
> same thing.
>
> We don't want the cold storage keypairs to be held online. We can design
> the system that the time-locked address keypair is held offline but it
> signs another key pair which is held online. Every time the IRC bot
> connects it can use this intermediate keypair to sign the IRC nickname
> proving ownership. The signature from the time-locked address to the
> intermediate keypair can be made to have an expiry date (for example 6
> months). This all means that the time-locked bitcoins can be held
> offline but still be used to prove ownership of an IRC nickname.
>
> The existance of the UTXO of a time-locked coin can be proved by
> revealing the TXID and vout, which full nodes can use to query the UTXO
> set to check that the coin exists. SPV clients would need a merkle proof
> as well. Burned coins and spent time-locked coins could have their
> existence proved by sharing the transaction which created them along
> with a block height and transaction position for an unpruned node, or a
> merkle proof for a pruned node or SPV client. Note that from the point
> of view of a pruned node, a merkle proof is a fully-verified proof of
> existance of a transaction. It is not a proof with just SPV-security.
>
> ## Links / References
> [1] https://github.com/JoinMarket-Org/joinmarket-clientserver
> [2] https://github.com/JoinMarket-Org/joinmarket/issues/693
> [3] https://en.bitcoin.it/wiki/Fidelity_bonds
> [4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
> [5]
> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks
> [6] First ever mention of fidelity bonds I found. The idea is basically
> invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
> [7] Old idea for combining fidelity bonds with mixers:
> https://bitcointalk.org/index.php?topic=172047.0
> [8] Suggestion that is very close to the fidelity bonds idea. He talks
> about requiring a deposit from makers, but nobody is able to come up
> with a way to make such a deposit decentralized and trustless:
> https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1
> _______________________________________________
> 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/20190726/1ca45f01/attachment-0001.sig>

2023-06-07 18:19:35

- reply

📅 Original date posted:2019-07-26
📝 Original message:Hi Justus,
It might be helpful to consult the Rust implementation of BIP158 here:
https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/bip158.rs
It has a cleaner structure than Core or Neutrino, includes server and client side
and passes Core's test vectors.
Regards,
Tamas Blummer
> On Jul 22, 2019, at 17:58, Justus Ranvier via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Signed PGP part
> On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
>> Finally, regarding alternatives, the filter-generation code for BIP
>> 157/158 has been in Bitcoin Core for some time, though the P2P serving
>> side of things appears to have lost any champions working on it. I
>> presume one of the Lightning folks will eventually, given they appear to
>> be requiring their users connect to a handful of their own servers right
>> now, but if you really need it, its likely not a ton of work to pipe
>> them through.
>
> If you want projects to adopt BIP-157/158, you'd do well to fix the
> numerous errors in the specification.
>
> As it stands right now it is impossible to implement the protocol using
> the specification because he code examples are broken to the point of
> appearing intentionally sabotaged.
>
>
>
-------------- 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/20190726/59fe71a1/attachment-0001.sig>

2023-06-07 18:19:14

- reply

📅 Original date posted:2019-07-06
📝 Original message:> On Jul 6, 2019, at 01:16, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Eric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil <eric at voskuil.org <mailto:eric at voskuil.org>> wrote:
>
>>> On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
>>> Good morning Eric,
>>>
>>>> As with Bitcoin mining, it is the consumed cost that matters in this scenario, (i.e., not the hash rate, or in this case the encumbered coin face value). Why would the advertiser not simply be required to burn .1 coin for the same privilege, just as miners burn energy? Why would it not make more sense to spend that coin in support of the secondary network (e.g. paying for confirmation security), just as with the burning of energy in Bitcoin mining?
>>
>> Good morning ZmnSCPxj,
>>
>>> Using the unspentness-time of a UTXO allows for someone advertising a service or producer to "close up shop" by simply spending the advertising UTXO.
>>> For instance, if the advertisement is for sale of a limited stock of goods, once the stock has been sold, the merchant (assuming the merchant used own funds) can simply recover the locked funds, with the potential to reinvest them elsewhere.
>>> This allows some time-based hedging for the merchant (they may be willing to wait indefinitely for the stock to be sold, but once the stock is sold, they can immediately reap the rewards of not having their funds locked anymore).
>>
>> This is a materially different concept than proposed by Tamas.
>>
>> “...he gives up his control of the coins until maturity, he can not use them elsewhere until then.”
>
> Possibly.
> In a way, this is giving up control of the coin, until he no longer needs the advertisement, i.e. dynamically select the maturity age needed.
>
My proposal would separate the owner of the funds from the one using the advertizement service. Yes, the owner lock up until maturity. But those using the UTXO for the advertizement service could transfer (sell) the UTXO to someone else as soon as they do not need it, so it is dynamic maturity for them The new owner could use them for an other advertizement or for an entirely different purpose.
Regarding burning: I think burning is unsustainable as usage of services is unlimited while coin suply is limited.
>>
>> And as I have shown above, nor can a “locked-up” coin be unlocked to do the same.
>
> You have shown no such thing, merely shown that you have not understood the proposal.
>
> Regards,
> ZmnSCPxj
I also struggle to communicate to Eric and likely many other reader the generic utility of temporary control of an UTXO. Let me try again:
Bitcoin offers a memory with remarkable properties:
- it can be read by anyone anywhere
- anyone anywhere who knows a key controlling an UTXO, and only them, can initiate an update to the memory
- global replicas guaranteed to apply updates of the memory within a short time period.
This is a utility that is sufficient to implement money.
Such a reliable shared memory could have however more uses than tracking money, It could keep track of, and thereby make scarce, arbitary other things.
We can unlock these uses by separating the money use of memory from other uses.
The covenant achives this separation temporarily. A UTXO with a covenant that guarantees that current owner re-gains control at a later time means,
that the current owner temporarily forgoes the UTXOs use as money and thereby allows its temporary use to keep track of something else.
UTXOs with different covenants or without covenant are not fungible.
Why use UTXOs of significant value to track something that is not money? Because the reason the registry is used is to create scarcity and scarcity can be tailored to more or
less severe by requiring more or less satoshis to track something.
The current owner of a regular UTXO will want to be paid for temporarily giving up control, and that payment represents interest. Riskless, since it is certain to re-gain control.
Regards,
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190706/14200f92/attachment-0001.html>
-------------- 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/20190706/14200f92/attachment-0001.sig>

2023-06-07 18:19:14

- reply

📅 Original date posted:2019-07-09
📝 Original message:Good morning ZmnSCPxj,
thank you very much for sharing your BCAN idea and thought process in detail.
I add some thoughs that very likely occured to you, but not formulated explicitelly:
1. The unique feature of such advertisement network is that it has no owner, just like the Bitcoin network.
If it had an owner, that owner could simply bill for use, but would also be forced to restrict access or apply some sort of censorship.
This is why usage costs is imposed through opportunity cost and not billed.
2. Since opportunity cost of one Bitcoin for a short time period is magnitudes less than its face value, one would need significant
Bitcoin amounts to impose meaningful costs so they have the chance to be included into BCANs purposedly limited bandwidth.
Those who would want to place an ad will often not have sufficient amount of Bitcoin holdings which lets them borrow UTXOs.
3. If borrowed Bitcoin is certain to be returned (as in your construction) then this offers riskless interest for HODLer.
4. Bitcoin’s most popular use is storing wealth whereby this use currently completely relies on the assumption that “the number goes up”.
A service that delivers interest on HODLed coins without exposing the HODLer to credit risk of the borrower is a huge game changer.
5.This scheme allows HODLer a concious decision whom or what project they fund.
For above reasons I think that this is a crucial design pattern to build censorship resistant networks which also give rise to riskless interest on Bitcoin.
My finance examples where abstract and less interesting for this audience but the BCAN should ring the bell for many.
As you said BCAN is possible with current Bitcoin, therefore we should no longer discuss it under the covenant topic.
The idea of debt covenant will likely resurface as soon as this design pattern proves to be useful in practice and one is looking for
a more flexible solution. I am confident we will get there, but not as fast as I initially thought.
Regards,
Tamas Blummer
> On Jul 9, 2019, at 12:31, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning all,
>
> I will attempt to restart my thinking from initial principles regarding my proposed "Bitcoin Classified Ads Network".
>
> Nodes behave this way:
>
> * Nodes in this network gossip advertisements.
> * These advertisements refer to a UTXO that must be unspent at the chain tip considered by each node, else they would be rejected.
> * The referred UTXO must contain a commitment to the text of the advertisement, else the advertisement is rejected.
> * Nodes have a maximum limit on the total size of all advertisements they retain and propagate to new nodes, or gossip to their peers.
> This is a deliberate design decision.
> * If nodes exceed the above limit, they will sort advertisements according to a value-rate, the value of the UTXO divided by the storage size of the advertisement, and prune advertisements with low value-rate until they are within the limit again.
> * Once the backing UTXO is spent, the advertisement is removed by nodes that follow that chaintip.
> * As the name ***Classified Ads*** suggests, each advertisement also indicates a "class" in which they belong to.
>
> Then, from the above, we derive how a seller might behave.
>
> * Sellers will attempt to put the minimum possible value into a UTXO committing to an advertisement, to reduce the opportunity cost of using the value elsewhere.
> * Thus the rent of the advertisement in this case is paid to joinmarket makers and LN forwarding nodes, as the value used in a UTXO backing an advertisement is not useable in joinmarket/LN.
> * Sellers remain in full control of their advertising UTXO, and can spend it at any time.
> * Sellers may spend part of the UTXO and put the remaining funds into a change address that is a new advertising UTXO, and re-transmit the advertisement, this time pointing to the new change UTXO.
> * However, if the remaining change becomes too low, then its value-rate may drop below the lowest value-rate that BCAN nodes will retain in their (deliberately limited) storage, thus also deleting their advertisement from the BCAN.
> * Presumably, the reason for advertising at all, is that the seller considers the cost of advertising to be less than the expected gain of actually selling their product.
> * Thus, even if the seller has the ability to spend the UTXO at any time, they run the risk of spending too much and thus removing their advertisement from the BCAN, and losing the expected gain of having the advertisement exist on the BCAN.
> * A utility-maximizing seller would therefore not spend a minimal-value UTXO backing the advertisement until it has gained the advantage of actually selling the product, even if it has the option to do so: it is a forced move.
> * The cost of keeping the minimal-value UTXO unspent is the opportunity cost in that the value may have been used in joinmarket or LN instead.
> * The minimum value will largely be dependent on how much the BCAN is used; more sellers advertising over BCAN will increase the minimum value.
> * If the minimum value that is viable to keep its advertisement alive goes higher, then the opportunity cost of the seller using the same value elsewhere might exceed the expected gain from selling the product.
> However, this is expected of *any* advertising scheme: if the gains from selling is too small to justify the advertisement price, advertising does not happen; this is expected utility-maximizing behavior.
> * If competitors of the seller exist and the BCAN node storage is already filled, competitors can increase the minimum value of a UTXO that can keep an advertisement alive on BCAN by simply adding more of their advertisements to BCAN.
> * Thus we expect that, once the BCAN node storage is at or near the maximum value, the minimum value of a UTXO that can back an advertisement will approach the expected gain from selling the product.
>
> Thus the system of simply committing UTXOs to particular advertisement texts seems sufficient to extract value from a seller wishing to advertise.
> The purpose of this extraction of value is to ensure that spam does not overload the BCAN.
>
> Let us now consider some kind of specialization, where a HODLer specializes in owning UTXOs, while an advertiser specializes in trading products that need advertising of some kind.
>
> * We assume that the specialization means that the HODLer cannot feasibly make and sell products on its own, while the advertiser cannot own and control UTXOs of the minimum value needed to keep their advertisement alive on the BCAN.
> * We assume that the specialization means that the advertiser can make and sell products for cheaper than the HODLer can, while the HODLer can own and control (and secure) UTXOs of the minimum value needed for advertisements to be kept alive, for cheaper than the advertiser can.
>
> Then:
>
> * A HODLer may offer to provide a UTXO locked by a 2-of-2 with a commitment to an advertisement of the advertiser's choosing, in exchange for rent of the value, plus an unbreakable promise to return the rented UTXO value back to the HODLer (represented by a `nLockTime` pre-signed transaction that returns the 2-of-2 back to the HODLer control).
> * The HODLer is effectively lending the UTXO out to the advertiser, for the time frame agreed upon by the advertiser.
> * The rent at which the HODLer lends out the UTXO must be between the opportunity cost of instead securely utilizing the UTXO in LN or joinmarket, and the expected gain the advertiser expects from having its product advertised.
> * The HODLer is assumed to have the ability to secure the UTXO and retain all data it needs to recover the UTXO; this is part of the assumption that the HODLer specializes in such.
> * The advertiser is assumed to have positive gains from creating, advertising, and selling its product; this is part of the assumption that the advertiser specializes in such.
> * The HODLer and advertiser can agree to refund part of the rent, if the advertiser signs a transaction that immediately returns control of the value to the HODLer, before the agreed `nLockTime`.
> * The above constructions can be done in current Bitcoin.
> * However, the same constructions could be done with a covenant as proposed by Tamas, possibly with reduced communication/coordination costs between the advertiser and HODLer.
>
> Now, there remains the question as to whether users will actually patronize the BCAN instead of existing advertising systems.
>
> * We assume that privacy is valuable to users.
> * We assume that users of BCAN will run BCAN nodes.
> This leaks them as users of BCAN, a small loss of privacy.
>
> Then:
>
> * Users can look for advertisements of specific classes by simply querying their own BCAN node.
> This does not leak privacy ata all as long as the communication channel of the user with their own BCAN node is private.
> * Compare this to alternatives, which involve some entity observing the behavior of users and thus invading their privacy.
> * Advertisers that misclassify their advertisements will be unable to reach their target audience.
> * Utility-maximizing advertisers will correctly indicate the class of their advertisements, as otherwise they would be paying the advertising cost without gaining the benefit of the advertisement.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20190709/f0e7588d/attachment-0001.sig>

2023-06-07 18:19:13

- reply

📅 Original date posted:2019-07-07
📝 Original message:Hi Eric,
Your cryproeconomic theories may describe correctly Bitcoin as money, but fall short of describing a Bitcoin that would also offer reliable memory for other uses.
In consequence you miss, that:
1. If the reliable memory that enables money would have more uses then even temporary use of the memory would have utility, therefore value. Bitcoin as is, does not have consensus rules to enable reliable alternate uses.
2. Finite supply of coins implies a finite memory capacity of Bitcoin. Alternate use of the memory requires that units at least temporarily become un-fungible, enforced by consensus. Alternate uses would then have to compete for units of memory, which would give rise to a price paid to those enabling alternate use, even if temoprarily.
3. If giving up control temorarily has a positive price (through 2) and return of control is certain (enforced by consenus) then the price paid is riskless interest for those giving up temporary control.
4. If a use requires more units of memory then it imposes higher cost to use and it since memory units are finite it imposes more severe scarcity.
Further certainly subjective remarks:
Although burning and loss is unavoidable and therefore Bitcoin (as is) is unsustainable we should design systems that they sustain it as long as possible (as is). Therefore a requirement to burn for any of unlimited number of uses should be avoided.
We currently perceive borrowed money just as good as (fungible with) any other money. This is a consequence that money actually comes into existence through someone borrowing it. Money on your account is a loan you gave the bank and even paper cash is a loan you gave the central bank.
Bitcoin is different as it just is, it is not borrowed into existence. Therefore it is not fungible with borrowed version of itself. This however does not imply that its borrowed version is worthless as it might be worth something if there is a use for it.
Tamas Blummer
> On Jul 7, 2019, at 03:30, Eric Voskuil <eric at voskuil.org> wrote:
>
> I have published a summary here:
>
> https://github.com/libbitcoin/libbitcoin-system/wiki/Risk-Free-Return-Fallacy <https://github.com/libbitcoin/libbitcoin-system/wiki/Risk-Free-Return-Fallacy>
>
> Barring any new consequential inputs I’ll refrain from further comment.
>
> e
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190707/861a3d6f/attachment.html>
-------------- 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/20190707/861a3d6f/attachment.sig>

2023-06-07 18:19:12

- reply

📅 Original date posted:2019-07-06
📝 Original message:Hi Eric,
> On Jul 6, 2019, at 03:28, Eric Voskuil <eric at voskuil.org> wrote:
>
>
>
>> On Jul 5, 2019, at 17:17, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning Eric,
>>
>>> But it’s worth noting that early recovery of the UTXO entirely eliminates the value of the time lock cost to the ad market. The most obvious example is one encumbering the coin to himself, then releasing it with his own two signatures whenever he wants. In other words, there is no encumbrance at all, just a bunch of pointless obscurantion.
>>
>> You still do not understand.
>> I strongly suggest actually reading the post instead of skimming it.
>
> I am responding to the cryptoeconomic principles, not the implementation details. Based on your comments here I am not misrepresenting those principles.
>
> For example, I have shown that the multisig unlock implementation reduces the presumably-encumbered UTXO to simply a UTXO. You have not disputed that. In fact below you have accepted it (more below).
>
>> The advertisement is broadcast to new nodes on the ad network if and only if its backing UTXO remains unspent.
>> Once the UTXO is spent, then the advertisement is considered no longer valid and will be outright deleted by existing nodes, and new nodes will not learn of them (and would consider it spam if it is forced to them when the UTXO is already spent, possibly banning the node that pushes the advertisement at them).
>>
>> Thus the locked-ness of the UTXO is the lifetime of the advertisement.
>
> The term “locked” here is misused. A unspent output that can be spent at any time is just an unspent output. The fact that you can “unencumber” your own coins should make this exceedingly obvious:
>
>> Once you disencumber the coins (whether your own, or rented) then your advertisement is gone; forever.
>
> As I have shown, there is no *actual* encumbrance.
>
If you have to forgo using your money while using a service that encumbers you. You incur opportunity cost proportional to time you use the service and the amount you waived to use elsewhere.
No crypto is needed to understand this.
>> Your advertisement exists only as long as the UTXO is unspent.
>
> Exactly, which implies *any* UTXO is sufficient. All that the ad network requires is proof of ownership of any UTXO.
>
Not any, but one with significant value, so a service with limited bandwith can prioritize by that.
> Best,
> Eric
>
>> Regards.
>> ZmnSCPxj
Best,
Tamas Blummer
-------------- 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/20190706/59b2f7b8/attachment.sig>

2023-06-07 18:19:08

- reply

📅 Original date posted:2019-07-04
📝 Original message:Hi Eric,
there are some other ways to impose cost on use without direct billing, e.g.:
- Burn Bitcoins to use the service, as you mentioned. This could work and would benefit remaining Bitcoin owner, but is unsustainable.
- Pay high fees in self dealing transactions. This could work and would benefit miner.
- Time lock own Bitcoins. This is forgoing control of an UTXO for a time period, which implies opportunity cost. This could be done with CLTV (OP_HODL). It damages the current owner but benefits no one. The problem is one might not have substantial UTXO to imply high enough opportunity cost.
- Pay someone else to time lock. This is paying someone to lock an UTXO for a time span. Payment and time lock could be combined in the same transaction.
- Transferable borrowed Bitcoin. This needs the covenant. This benefits those who consciously give up control for a time span. Its advantage is that since transferable it can be sold if no longer needed, thereby shortening the term of the original arrangement. It coul be re-rented for a shorter time period.
Tamas Blummer
> On Jul 4, 2019, at 18:43, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi ZmnSCPxj,
>
> Generalizing a bit this appears to be the same with one exception. The amount of encumbered coin is relevant to an external observer. Of course the effective dust limit is the maximum necessary encumbrance otherwise.
>
> In the case of simple tracking, the market value of the coin is not relevant, all that is required is a valid output. Hence the devolution to 1 sat tracking. In your scenario the objective is to establish a meaningful cost for the output.
>
> A community of people using this as a sort of hashcash spam protection can raise the amount of encumbered coin (i.e. advertising threshold price) required in that context. The cost of this encumberance includes not only at least one tx fee but market cost of the coin rental.
>
> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 encumbered coin, the same is achieved by burning .1 coin. In other words the renter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coin for one year.
>
> As with Bitcoin mining, it is the consumed cost that matters in this scenario, (i.e., not the hash rate, or in this case the encumbered coin face value). Why would the advertiser not simply be required to burn .1 coin for the same privilege, just as miners burn energy? Why would it not make more sense to spend that coin in support of the secondary network (e.g. paying for confirmation security), just as with the burning of energy in Bitcoin mining?
>
> e
>
>> On Jul 3, 2019, at 23:57, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning Eric,
>>
>>
>>>> and thanks to you and ZmnSCPxj we now have two additional uses cases for UTXOs that are only temporarily accessible to their current owner.
>>>
>>> Actually you have a single potentially-valid use case, the one I have presented. The others I have shown to be invalid (apart from scamming) and no additional information to demonstrate errors in my conclusions have been offered.
>>
>> I presented another use case, that of the "Bitcoin Classified Ads Network".
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
>>
>> Advertisements are "backed" by an unspent TXO.
>> In order to limit their local resource consumption, nodes of this network will preferentially keep advertisements that are backed by higher UTXO values divided by advertisement size, and drop those with too low UTXO value divided by advertisement size.
>>
>> Thus, spammers will either need to rent larger UTXO values for their spam, paying for the higher rent involved, or fall back to pre-Bitcoin spamming methods.
>> Thus I think I have presented a use-case that is viable for this and does not simply devolve to "just burn a 1-satoshi output".
>>
>> I still do not quite support generalized covenants as the use-case is already possible on current Bitcoin (and given that with just a little more transaction introspection this enables Turing-completeness), but the basic concept of "renting a UTXO of substantial value" appears sound to me.
>>
>>
>> Regards,
>> ZmnSCPxj
-------------- 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/20190704/b4487436/attachment.sig>

2023-06-07 18:19:06

- reply

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,
> On Jul 2, 2019, at 12:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, July 2, 2019 5:30 PM, Tamas Blummer <tamas.blummer at gmail.com <mailto:tamas.blummer at gmail.com>> wrote:
>
>> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
>
> No it would not :)
You are right. I noticed after sending my reply and then I sent two other. I apologize for being noisy.
Let me consolidate my thinking, here.
If there is a use for UTXOs with temporary control, then those who want that use will pay for it.
A user of a service that requires temporary control UTXOs would need to cover:
1. fees required by the service
2. the opportunity cost of temporary ownership paid to the original holder who gave up control.
If the service is operated by an entity billing user then it can use UTXOs of minimal value for its operation and practically ignore opportunity interest.
This is the case with theater tickets just and other simple colored coin like use of Bitcoin. Also in case of the unchained advertizement, if the service bills its user
for its internal re-allocation of an UTXO, then why would it need to use significant value temorary control UTXOs? Actually why not use plain UTXOs, to start with?
If however the service is a common good, a network without owner and therefore not billing on behalf of someone, but wants to protect itself from spam, then it is could require temporary access to significant value UTXOs and thereby induce opportunity cost to user. Alternatively it could require burning ordinary UTXOs. Burning indirectly benefits all HODLer, temporary control benefits those who consciously gave up control. I dislike burning as it is unsustainable.
If the implementation of temporary use is enforced by consenus such that it is transitive, then temporary use could be re-rented or sold to recover opportunity cost for no longer needed temporary access, making it useable for an other service.
Temporary access UTXOs with covenants allows us to build spam limited public services that are not owned by an operator and financially benefit HODLer offering them riskless interest.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/3b7b41ad/attachment-0001.html>
-------------- 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/20190702/3b7b41ad/attachment-0001.sig>

2023-06-07 18:19:06

- reply

📅 Original date posted:2019-07-02
📝 Original message:> On Jul 1, 2019, at 20:52, Eric Voskuil <eric at voskuil.org> wrote:
>
> I said that I would make no further comment given the belief that no new ideas were surfacing. However, after giving it some more thought on my own, I believe I have found the one case in which a person could value such encumbered coins.
>
> In the case of tracking an asset that becomes worthless at a specific time, one could value a record of ownership, and the ability to trade ownership of the asset during the period. Consider colored coin type tracking of a theater ticket for a specific show, where the ticket is worthless by the end of the show.
>
In other words you now see the utility of a register offered by UTXOs that are only temporary availability to current owner. If there is a utility there is also a value in it for them.
I am glad we are on the same side on this utility and thanks to you and ZmnSCPxj we now have two additional uses cases for UTXOs that are only temporarily accessible to their current owner.
Since ZmnSCPxj also raised the question if covenants are needed at all, let me continue my thoughts on this in reply to his mail.
Tamas Blummer
>
>
>> On Jun 30, 2019, at 13:26, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>> My argument does not need the comparison with ICOs.
>>
>> They were just an example that people pay for the utility of register even though others think the tokens they keep track of are worthless.
>>
>> Tamas Blummer
>>
>>
>>> On Jun 30, 2019, at 22:13, Eric Voskuil <eric at voskuil.org> wrote:
>>>
>>> ICO tokens can be traded (indefinitely) for other things of value, so the comparison isn’t valid. I think we’ve both made our points clearly, so I’ll leave it at that.
>>>
>>> Best,
>>> Eric
>>>
>>>> On Jun 30, 2019, at 12:55, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>
>>>>
>>>>> On Jun 30, 2019, at 20:54, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>
>>>>> Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins?
>>>>
>>>> I guess we agree that some way of keeping track of ownership is prerequisite for something to aquire value.
>>>> We likely also agree that the security of that ownership register has great influence to the value.
>>>>
>>>> The question remains if a register as utility in itself gives value to the thing needed to use that register.
>>>> I think it does, if people are interested in what it keeps track of, for whatever reason, even for reasons you find bogus.
>>>>
>>>> It was not intentional, but I think I just explained why Ethereum aquired higher market value by being register of ICO tokens.
>>>>
>>>> Now back to the coins encumbered with the debt covenant:
>>>> Transactions moving them constitute a register of covered debt and you need them to update that register.
>>>> Should some people find such a register useful then those coins needed to update this register will aquire value.
>>>> Does not matter if you think the concept of covered debt is just as bogus as ICOs.
>>>>
>>>> Here some good news: If they aquire value then they offer a way to generate income for hodler by temporarily giving up control.
>>>>
>>>> Tamas Blummer
>>>>
>>>>>
>>>>> The meaning in terms of Bitcoin is clear - the “owner” of outputs that represent value (i.e. in the ability to trade them for something else) is recorded publicly and, given Bitcoin security assumptions, cannot be faked. What is not clear is the utility of a record of outputs that cannot be traded for something else. You seem to imply that a record is valuable simply because it’s a record.
>>>>>
>>>>> e
>>>>>
>>>>>> On Jun 30, 2019, at 11:35, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jun 30, 2019, at 19:41, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Jun 30, 2019, at 03:56, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Eric,
>>>>>>>>
>>>>>>>>> On Jun 29, 2019, at 23:21, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>>>>>
>>>>>>>>> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>>>>>>>>
>>>>>>>> Coins encumbered with the described covenant represent temporary control of a scarce resource.
>>>>>>>>
>>>>>>>> Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
>>>>>>>
>>>>>>> For something to become property (and therefore have marketable value) requires that it be both scarce and useful. Bitcoin is useful only to the extent that it can be traded for something else that is useful. Above you are only dealing with scarcity, ignoring utility.
>>>>>>
>>>>>> There is a deeper utility of Bitcoin than it can be traded for something else. That utility is to use its unforgeable register.
>>>>>> We have only one kind of units in this register and by having covenants we would create other kinds that are while encumbered not fungible with the common ones.
>>>>>>
>>>>>> Units are certainly less desirable if encumbered with a debt covenant. You say no one would assign them any value.
>>>>>>
>>>>>> I am not that sure as they still offer the utility of using the unforgeable register, in this case a register of debt covered by reserves.
>>>>>> You also doubt forcing debt to be covered by reserves is a good idea, I got that, but suppose we do not discuss this here.
>>>>>> If there are people who think it is a good idea, then they would find having an unforgeable register of it useful and therefore units needed to maintain that register valuable to some extent.
>>>>>>
>>>>>>>
>>>>>>>> I think you do not show the neccesary respect of the market.
>>>>>>>
>>>>>>> I’m not sure what is meant here by respect, or how much of it is necessary. I am merely explaining the market.
>>>>>>
>>>>>> You are not explaining an existing market but claim that market that is not yet there will follow your arguments.
>>>>>>
>>>>>>>> Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
>>>>>>>
>>>>>>> It seems to me you have reversed the meaning of temporary and final. Bitcoin is useful because of the presumption that there is no finality of control. One presumes an ability to trade control of it for something else. This is temporary control. Final control would be the case in which, at some point, it can no longer be traded, making it worthless at that point. If this is known to be the case it implies that it it worthless at all prior points as well.
>>>>>>>
>>>>>>> These are distinct scenarios. The fact that temporary (in my usage) control implies the possibility of value does not imply that finality of control does as well. The fact that (renowned or otherwise) people have made errors does not imply that I am making an error. These are both non-sequiturs.
>>>>>>>
>>>>>>>> I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
>>>>>>>
>>>>>>> The analogy to rental of a consumable good does not apply to the case of a non-consumable good. If it cannot be traded and cannot be consumed it cannot obtain marketable value. To this point it matters not whether it exists.
>>>>>>
>>>>>> I meant with control the control of entries in the register which I think is the deeper utility of Bitcoin. Final control is meant to be the opposite of temporary which is the time limited control with some expiry.
>>>>>>
>>>>>> Thank you for your thoughts as they help to sharpen my arguments.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Tamas Blummer
>>>>>>
>>>>>>> Best,
>>>>>>> Eric
>>>>>>>
>>>>>>>> Tamas Blummer
>>
-------------- 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/20190702/bea61729/attachment-0001.sig>

2023-06-07 18:19:05

- reply

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,
I share your goal to move everything possible off-chain.
The discussion of covenant is not an on/off-chain discussion, but if covenant is needed to solve problems we currently can not and which unlock significant innovation.
Consensus support of the covenant is only needed if an unchained setup using it is closed uncooperatively, otherwise there is not even a reason to disclose on-chain that a covenant was used.
Regards,
Tamas Blummer
> On Jul 2, 2019, at 11:30, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hello ZmnSCPxj,
>
>> On Jul 2, 2019, at 10:12, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> As a counterargument, I observe that committing to the advertisement on the UTXO is similar to committing to a SCRIPT on a UTXO.
>> And I observe the Graftroot idea, wherein we commit to a public key on the UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that unlocks the UTXO for spending.
>>
>> By analogy, in my "advertising" scheme, instead of committing the advertisement on the UTXO, I can instead commit a public key (for example, the hash of the "advertiser pubkey" is used to tweak the onchain public key).
>> Then we use this advertiser pubkey to admit advertisements on the advertising network.
>>
>> This advertiser pubkey is used to sign an "advertisement chain", which is a merklized singly-linked list whose contents are the actual advertisements, each node being signed using the advertiser pubkey.
>> To ensure that the advertiser does not sign multiple versions of this chain, we can have the signing nonce be derived from the height of the advertchain, such that signing the same height multiple times leads to private key revelation.
>
> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
> This is not the trustless separation the covenant achives.
>
> Regards,
>
> Tamas Blummer
>
-------------- 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/20190702/c60a6c10/attachment-0001.sig>

2023-06-07 18:19:05

- reply

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,
To be more precise, the value of the UTXO is severaly damaged that it is governed by rules of a de-facto side chain with different rules.
Therefore its value to those renting it from the advertizer is just that of the advertizement, which is not neccesarily following the opportunity cost.
The covenant supported temporary access is transitive, therefore anyone who is in temporary control of an UTXO can recover its cost by sub-renting.
The opportunity (riskless) interest provides a baseline of value on top of which you may have utility that is the advertizement.
Regards,
Tamas Blummer
> On Jul 2, 2019, at 11:30, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hello ZmnSCPxj,
>
>> On Jul 2, 2019, at 10:12, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> As a counterargument, I observe that committing to the advertisement on the UTXO is similar to committing to a SCRIPT on a UTXO.
>> And I observe the Graftroot idea, wherein we commit to a public key on the UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that unlocks the UTXO for spending.
>>
>> By analogy, in my "advertising" scheme, instead of committing the advertisement on the UTXO, I can instead commit a public key (for example, the hash of the "advertiser pubkey" is used to tweak the onchain public key).
>> Then we use this advertiser pubkey to admit advertisements on the advertising network.
>>
>> This advertiser pubkey is used to sign an "advertisement chain", which is a merklized singly-linked list whose contents are the actual advertisements, each node being signed using the advertiser pubkey.
>> To ensure that the advertiser does not sign multiple versions of this chain, we can have the signing nonce be derived from the height of the advertchain, such that signing the same height multiple times leads to private key revelation.
>
> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
> This is not the trustless separation the covenant achives.
>
> Regards,
>
> Tamas Blummer
>
-------------- 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/20190702/46768c00/attachment.sig>

2023-06-07 18:19:04

- reply

📅 Original date posted:2019-07-02
📝 Original message:Good morning Eric and ZmnSCPxj,
> On Jul 2, 2019, at 05:45, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Eric, and Tamas,
>
>> In the case of tracking an asset that becomes worthless at a specific time, one could value a record of ownership, and the ability to trade ownership of the asset during the period. Consider colored coin type tracking of a theater ticket for a specific show, where the ticket is worthless by the end of the show.
>
> As it happens, I was playing around with another idea I am developing.
> And it involves something very much similar, but distinct.
>
> In particular, currencies are worthless unless exchanged for things of value to existent beings.
> And the discovery of things of value is enabled by advertising.
> The idea I am developing, is that of a "Bitcoin Classified Ads Network", wherein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a commitment to an advertisement.
> A secondary network of nodes (separate from the Bitcoin network) transmits the actual advertisements, as well as the UTXOs being used to commit to them.
> This secondary network would then reject/purge advertisements once the UTXO is spent on the Bitcoin blockchain.
> This makes advertising costly (for the opportunity cost of locking some money in a UTXO until one has acquired actual paying custom) while reducing impact on Bitcoin blockchain space (commitment to the advertisment is in the same space as the ownership of the coin).
> Changing the advertisement one makes is possible, at the cost of paying for a transaction in the Bitcoin blockchain to spend the old UTXO and publish a new UTXO now committing to the new advertisement.
>
> Of note is that I also derived that it would be beneficial, for some HODLers to offer their funds for the purpose of making these advertisements.
All above aligns with my intuition that: on one side giving up temporary control of UTXOs represent opportunity cost and on the receiver side having temporary control can unlock utility they would pay for.
If the techical setup is trustless and return of control to those who gave it up temporarilty is certain, then this in combination means that HODLer are able to earn riskless interest by giving up control of their UTXOs temporarily.
> Some service or product provider would agree with an advertiser to lock some coins of the advertiser for a limited amount of time, in exchange for payment upfront, with the coin address committing to the indicate advertisement of the service or product provider.
> This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) public key, with the service/product provider embedding a commitment to its advertisement to its own key, and a pre-signed `nLockTime` transaction that lets the advertiser recover the money.
>
> This is in fact a similar use to the "theater ticket" case you mentioned, yet distinct.
> In the case of the Bitcoin Classified Ads Network, it is the intermediate addresses used before reclamation by the advertiser that is valuable, as they also serve as commitments to advertisements, attesting to the (probable) validity of the advertisement and making spam have a cost.
> Given that nodes of the Bitcoin Classified Ads Network will have memory limits, advertisements whose "lockup-rate" (i.e. the amount of value of the backing UTXO, divided by the size of the advertisement) are low could be evicted from memory before advertisements with high lockup-rate, and thus be less likely to propagate across the network.
> Thus service/product providers would want to increase their "marketing budget" to be less likely to be evicted from nodes of the Bitcoin Classified Ads Network, which is beneficial as it increases the minimum practical lockup-rate needed to spam the network, thus making spam costly.
>
> My current plan is that the provider can contact the advertiser in order to effect changes to their advertisement.
> Then the provider and the advertiser sign a new timelocked reclamation transaction, then sign a transaction moving from the old advertisement to the new advertisement (presumably there is some protocol for ensuring the advertiser gets paid for this, such as an HTLC that can be triggered by an onchain payment or by an LN payment; I have the details in my processing space but require some time to serialize to human-readabe format).
>
> Arguably, this example seems to show that generalized covenants are not needed in fact, if transfers of coin require paying to the issuer/lender of the coin.
> Generalized covenants allows the provider (or ticket-holder in your example) to effect transfers from one advertisement to another (or one ticket-holder to another in your example) without cooperation with the advertiser (or ticket-issuer in your example).
> This would be otherwise needed if we lock using a 2-of-2 address that has a timelocked transaction to reclaim the funds.
Yes, your example does not need the covenant as the one who gave up temporary control is still involved in any motion of the UTXO, therefore able to enforce own interest that reclaiming the UTXOs remains possible.
A covenant is needed only if it is against the interest of all parties involved in transfers of the UTXO, in which case consensus must enforce that it is carried forward.
The added strength of the covenant is that the one who gives up temporary control does not have to be involved in using the UTXO until it is given back.
Note that the advertizing service provider would need temporary access to UTXOs of signficant value, so opportunity cost and thereby cost of advertizing becomes significant.
Covenants would allow the separation of the advertizing service from HODLer funding it with significant UTXOs.
HODLer could give temporary control to the service and the service could broker those to others, but the original HODLer was sure to receive the UTXOs back and the HODLer would not be bothered with the operation of the service.
The covenant I proposed would add an alternate taproot validation path stacked onto previously existing ones.
This means that one could give others temporary access for a shorter time period than one’s own temporary access.
One could however not override the delayed access secured for the HODLer.
Does this remind you of something? Yes, the service provider would act like a bank, matching depositor, the HODLer, with those who need temporary control of UTXO for advertizing purposes.
This shows why temporary control with covenant can be understood as loan in a full reserve banking, which started my exploration of this topic.
Current technical means do not allow trustless and hands-off coordination of provider of UTXOs (that is capital) with provider of arbitary services that monetize the use of Bitcoin’s unforgable registry.
In other words we need covenants to enable Bitcoin applications to trustlessly and flexibly deal with foreign capital.
One other thing the consensus would have to ensure is that inputs with covenants are merged only into outputs with same covenant.
Which makes UTXOs with a particular covenants obey rules earlier known for colored coins and transactions moving it form a distinct embedded chain.
Adding same covenant establishes fungible coinbases of same embedded chain and dropping the covenant makes them again fungible with common UTXOs.
I could not be more excited of what boost this could give to the Bitcoin economy, unlocking the use of its unforgeable registry to track any asset with the same security guarantees it offers for its own cash token.
Best to you,
Tamas Blummer
>
> Regards,
> ZmnSCPxj
-------------- 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/20190702/4f51afba/attachment.sig>

2023-06-07 18:19:04

- reply

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,
> On Jul 2, 2019, at 10:12, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> As a counterargument, I observe that committing to the advertisement on the UTXO is similar to committing to a SCRIPT on a UTXO.
> And I observe the Graftroot idea, wherein we commit to a public key on the UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that unlocks the UTXO for spending.
>
> By analogy, in my "advertising" scheme, instead of committing the advertisement on the UTXO, I can instead commit a public key (for example, the hash of the "advertiser pubkey" is used to tweak the onchain public key).
> Then we use this advertiser pubkey to admit advertisements on the advertising network.
>
> This advertiser pubkey is used to sign an "advertisement chain", which is a merklized singly-linked list whose contents are the actual advertisements, each node being signed using the advertiser pubkey.
> To ensure that the advertiser does not sign multiple versions of this chain, we can have the signing nonce be derived from the height of the advertchain, such that signing the same height multiple times leads to private key revelation.
The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
This is not the trustless separation the covenant achives.
Regards,
Tamas Blummer
-------------- 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/20190702/8a8984f5/attachment-0001.sig>

2023-06-07 18:19:02

- reply

📅 Original date posted:2019-06-30
📝 Original message:Any meaningful covenant must be one that is reducing control by the current owner.
I can think of countless predicates reducing control, but try to explore the least invasive first,
and see if they unlock a new use.
Offering alternate control paths is what taproot was designed for, therefore a covenant
that requires that a control path is inherited seems a fit. That is all the
debt covenant needs.
There are other predicates with exciting use, such as one on total work performed by miner
which I tried to explore earlier. Pieter Wuille said it could be a candidate for the annex.
Tamas Blummer
> On Jun 30, 2019, at 19:50, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> I made an error proposing the new covenant. It should be unchanged as in the original example:
>
> ‘covenant or(and(_, pk(Transfer)) covenant transitive, and(pk(Exit), _) covenant drop)’
>
> since the placeholder stays for the control of the rightful owner without transfer signature on or off chain.
>
> The exit could be alternatively automatic allowing to exit a stalling unchained platform:
>
> ‘covenant or(and(_, pk(Transfer)) covenant transitive, and(delay(100), _) covenant drop)’
>
> There remains the question why the rightful owner is not enforcing the covenant instead of having it enforced by on-chain consensus.
>
> I do not yet have a good answer for that as in contrast to the debt example, here it is aligned with the interest of the current owner to have the covenant.
>
> Tamas Blummer
>
>> On Jun 30, 2019, at 18:57, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>> Hello ZmnSCPxj,
>>
>> Yes, representation of debt is more interesting here as it requires the covenant, wheras this example, as you point out, was less convincing given alternatives.
>> I created this example to avoid discussion of topics not approriate on this list.
>>
>> Thank you for the suggestion of unchained execution of transfers with cut-through exit transaction as this made the example much stronger:
>>
>> The most important question for someone who trusts his coins to some unchained platform is probably the question of how exit is guaranteed if one is unhappy with what one gets.
>>
>> With the exit covenant exit conditions are set in stone, since validated on-chain. If the exit key is owned by a trusted arbiter other than the federation governing the unchained platform
>> then one at least have the option to cut losses at some point by presenting the arbiter a chain of valid transactions and asking to sign the exit.
>>
>> Participants in the unchained platform would also be interested to regularly snapshot the economic effect of offchain transactions with cut-through transactions as such cut-through shortens the chain of transactions
>> they would need to get on chain if chosing the exit without consent of the federation governing the transfers.
>>
>> So the convenant needed is: 'covenant or(_ covenant transitive, and(pkExit, _) covenant drop)' which gives unrestricted flexibility to the unchained platform with the exception that it has to maintain the exit option.
>>
>>
>> Tamas Blummer
>>
>>
>>> On Jun 29, 2019, at 22:25, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>>
>>> Good morning Tamas,
>>>
>>> While I think covenants for some kind of debt tool is mildly interesting and an appropriate solution, I wonder about this particular use-case.
>>>
>>> It seems to me that, as either the `Transfer` signers or `Exit` signers are always involved, that the `Transfer` signers can be constrained so as to ensure that the rules are followed correctly, without requiring that covenants be used on the Bitcoin layer.
>>> After all, the outputs of each transaction signed by the `Transfer` signers are part of the transaction that is being signed; surely the `Transfer` signers can validate that the output matches the contract expected, without requiring that fullnodes also validate this?
>>>
>>> In particular, it seems to me that covenants are only useful if there exist some alternative that does not involve some kind of fixed `Transfer` signer set, but still requires a covenant.
>>> Otherwise, the `Transfer` signer set could simply impose the rules by themselves.
>>>
>>>
>>> Another thing is that, if my understanding is correct, the "sidechain" here is not in fact a sidechain; the "sidechain" transaction graph is published on the Bitcoin blockchain.
>>> Instead, the `Transfer` signers simply validate some smart contract, most likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public keys, and ensure that the smart contract is correctly executed.
>>> In that case, it may be useful to consider Smart Contracts Unchained instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>>>
>>> It would be possible, under Smart Contracts Unchained, to keep the `Transfer`-signed transactions offchain, until `Exit`-signing.
>>> Then, when this chain of transaction spends is presented to the participants, the participants can be convinced to sign a "cut-through" transaction that cuts through the offchain transactions, with the resulting cut-through being the one confirmed onchain, and signed only the participants, without the `Transfer` or `Exit` federation signatures appearing onchain.
>>> This hides not only the smart contract being executed, but also the fact that a Smart Contracts Unchained technique was at all used.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I introduced you to gerneralized covenants[1] earlier, but in a domain specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
>>>>
>>>> A covenant
>>>>
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>>
>>>> would put a coin under the alternative control of a Transfer and Exit keys together with the script in control of the current owner.
>>>> Additional transaction level validations of transactions spending input with covenants apply as in [1]
>>>>
>>>> Owner of such coins would be able to transfer them to others provided an addtional Transfer signature, in which case the coin remains encumbered with the same covenant.
>>>> If Exit and owner signs the covenant is dropped on the output, it becomes a plain Bitcoin again.
>>>>
>>>> The Thransfer and Exit signatures could be threshold signatures of a federation, whereby member decide if the proposed transfer transaction complies with whatever unique rules they impose.
>>>>
>>>> The result is a federated side chain embedded into the Bitcoin block chain.
>>>>
>>>> Bob could purchase some asset guarded by the federation with a transaction:
>>>>
>>>> Inputs
>>>> 100.0001 pk(Bob)
>>>>
>>>> Outputs
>>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 99.9 pk(Transfer)
>>>>
>>>> Transfer to Alice with consent of the transfer validators:
>>>>
>>>> Inputs
>>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 100.001 pk(Alice)
>>>>
>>>> Outputs
>>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 100 pk(Bob)
>>>>
>>>> Alice might be approved to exit with the exit signature of the federation:
>>>>
>>>> Inputs
>>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 99.9 pk(Transfer)
>>>>
>>>> Outputs
>>>> 99.9999 pk(Alice)
>>>>
>>>> Tamas Blummer
>>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
>>>
>>>
>>
>
-------------- 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/20190701/783d02da/attachment.sig>

2023-06-07 18:19:01

- reply

📅 Original date posted:2019-06-30
📝 Original message:I made an error proposing the new covenant. It should be unchanged as in the original example:
‘covenant or(and(_, pk(Transfer)) covenant transitive, and(pk(Exit), _) covenant drop)’
since the placeholder stays for the control of the rightful owner without transfer signature on or off chain.
The exit could be alternatively automatic allowing to exit a stalling unchained platform:
‘covenant or(and(_, pk(Transfer)) covenant transitive, and(delay(100), _) covenant drop)’
There remains the question why the rightful owner is not enforcing the covenant instead of having it enforced by on-chain consensus.
I do not yet have a good answer for that as in contrast to the debt example, here it is aligned with the interest of the current owner to have the covenant.
Tamas Blummer
> On Jun 30, 2019, at 18:57, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hello ZmnSCPxj,
>
> Yes, representation of debt is more interesting here as it requires the covenant, wheras this example, as you point out, was less convincing given alternatives.
> I created this example to avoid discussion of topics not approriate on this list.
>
> Thank you for the suggestion of unchained execution of transfers with cut-through exit transaction as this made the example much stronger:
>
> The most important question for someone who trusts his coins to some unchained platform is probably the question of how exit is guaranteed if one is unhappy with what one gets.
>
> With the exit covenant exit conditions are set in stone, since validated on-chain. If the exit key is owned by a trusted arbiter other than the federation governing the unchained platform
> then one at least have the option to cut losses at some point by presenting the arbiter a chain of valid transactions and asking to sign the exit.
>
> Participants in the unchained platform would also be interested to regularly snapshot the economic effect of offchain transactions with cut-through transactions as such cut-through shortens the chain of transactions
> they would need to get on chain if chosing the exit without consent of the federation governing the transfers.
>
> So the convenant needed is: 'covenant or(_ covenant transitive, and(pkExit, _) covenant drop)' which gives unrestricted flexibility to the unchained platform with the exception that it has to maintain the exit option.
>
>
> Tamas Blummer
>
>
>> On Jun 29, 2019, at 22:25, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning Tamas,
>>
>> While I think covenants for some kind of debt tool is mildly interesting and an appropriate solution, I wonder about this particular use-case.
>>
>> It seems to me that, as either the `Transfer` signers or `Exit` signers are always involved, that the `Transfer` signers can be constrained so as to ensure that the rules are followed correctly, without requiring that covenants be used on the Bitcoin layer.
>> After all, the outputs of each transaction signed by the `Transfer` signers are part of the transaction that is being signed; surely the `Transfer` signers can validate that the output matches the contract expected, without requiring that fullnodes also validate this?
>>
>> In particular, it seems to me that covenants are only useful if there exist some alternative that does not involve some kind of fixed `Transfer` signer set, but still requires a covenant.
>> Otherwise, the `Transfer` signer set could simply impose the rules by themselves.
>>
>>
>> Another thing is that, if my understanding is correct, the "sidechain" here is not in fact a sidechain; the "sidechain" transaction graph is published on the Bitcoin blockchain.
>> Instead, the `Transfer` signers simply validate some smart contract, most likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public keys, and ensure that the smart contract is correctly executed.
>> In that case, it may be useful to consider Smart Contracts Unchained instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>>
>> It would be possible, under Smart Contracts Unchained, to keep the `Transfer`-signed transactions offchain, until `Exit`-signing.
>> Then, when this chain of transaction spends is presented to the participants, the participants can be convinced to sign a "cut-through" transaction that cuts through the offchain transactions, with the resulting cut-through being the one confirmed onchain, and signed only the participants, without the `Transfer` or `Exit` federation signatures appearing onchain.
>> This hides not only the smart contract being executed, but also the fact that a Smart Contracts Unchained technique was at all used.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I introduced you to gerneralized covenants[1] earlier, but in a domain specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
>>>
>>> A covenant
>>>
>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>
>>> would put a coin under the alternative control of a Transfer and Exit keys together with the script in control of the current owner.
>>> Additional transaction level validations of transactions spending input with covenants apply as in [1]
>>>
>>> Owner of such coins would be able to transfer them to others provided an addtional Transfer signature, in which case the coin remains encumbered with the same covenant.
>>> If Exit and owner signs the covenant is dropped on the output, it becomes a plain Bitcoin again.
>>>
>>> The Thransfer and Exit signatures could be threshold signatures of a federation, whereby member decide if the proposed transfer transaction complies with whatever unique rules they impose.
>>>
>>> The result is a federated side chain embedded into the Bitcoin block chain.
>>>
>>> Bob could purchase some asset guarded by the federation with a transaction:
>>>
>>> Inputs
>>> 100.0001 pk(Bob)
>>>
>>> Outputs
>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>> 99.9 pk(Transfer)
>>>
>>> Transfer to Alice with consent of the transfer validators:
>>>
>>> Inputs
>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>> 100.001 pk(Alice)
>>>
>>> Outputs
>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>> 100 pk(Bob)
>>>
>>> Alice might be approved to exit with the exit signature of the federation:
>>>
>>> Inputs
>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>> 99.9 pk(Transfer)
>>>
>>> Outputs
>>> 99.9999 pk(Alice)
>>>
>>> Tamas Blummer
>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
>>
>>
>
-------------- 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/20190630/25c90620/attachment-0001.sig>

2023-06-07 18:19:01

- reply

📅 Original date posted:2019-06-30
📝 Original message:Hello ZmnSCPxj,
Yes, representation of debt is more interesting here as it requires the covenant, wheras this example, as you point out, was less convincing given alternatives.
I created this example to avoid discussion of topics not approriate on this list.
Thank you for the suggestion of unchained execution of transfers with cut-through exit transaction as this made the example much stronger:
The most important question for someone who trusts his coins to some unchained platform is probably the question of how exit is guaranteed if one is unhappy with what one gets.
With the exit covenant exit conditions are set in stone, since validated on-chain. If the exit key is owned by a trusted arbiter other than the federation governing the unchained platform
then one at least have the option to cut losses at some point by presenting the arbiter a chain of valid transactions and asking to sign the exit.
Participants in the unchained platform would also be interested to regularly snapshot the economic effect of offchain transactions with cut-through transactions as such cut-through shortens the chain of transactions
they would need to get on chain if chosing the exit without consent of the federation governing the transfers.
So the convenant needed is: 'covenant or(_ covenant transitive, and(pkExit, _) covenant drop)' which gives unrestricted flexibility to the unchained platform with the exception that it has to maintain the exit option.
Tamas Blummer
> On Jun 29, 2019, at 22:25, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Tamas,
>
> While I think covenants for some kind of debt tool is mildly interesting and an appropriate solution, I wonder about this particular use-case.
>
> It seems to me that, as either the `Transfer` signers or `Exit` signers are always involved, that the `Transfer` signers can be constrained so as to ensure that the rules are followed correctly, without requiring that covenants be used on the Bitcoin layer.
> After all, the outputs of each transaction signed by the `Transfer` signers are part of the transaction that is being signed; surely the `Transfer` signers can validate that the output matches the contract expected, without requiring that fullnodes also validate this?
>
> In particular, it seems to me that covenants are only useful if there exist some alternative that does not involve some kind of fixed `Transfer` signer set, but still requires a covenant.
> Otherwise, the `Transfer` signer set could simply impose the rules by themselves.
>
>
> Another thing is that, if my understanding is correct, the "sidechain" here is not in fact a sidechain; the "sidechain" transaction graph is published on the Bitcoin blockchain.
> Instead, the `Transfer` signers simply validate some smart contract, most likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public keys, and ensure that the smart contract is correctly executed.
> In that case, it may be useful to consider Smart Contracts Unchained instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>
> It would be possible, under Smart Contracts Unchained, to keep the `Transfer`-signed transactions offchain, until `Exit`-signing.
> Then, when this chain of transaction spends is presented to the participants, the participants can be convinced to sign a "cut-through" transaction that cuts through the offchain transactions, with the resulting cut-through being the one confirmed onchain, and signed only the participants, without the `Transfer` or `Exit` federation signatures appearing onchain.
> This hides not only the smart contract being executed, but also the fact that a Smart Contracts Unchained technique was at all used.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I introduced you to gerneralized covenants[1] earlier, but in a domain specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
>>
>> A covenant
>>
>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>
>> would put a coin under the alternative control of a Transfer and Exit keys together with the script in control of the current owner.
>> Additional transaction level validations of transactions spending input with covenants apply as in [1]
>>
>> Owner of such coins would be able to transfer them to others provided an addtional Transfer signature, in which case the coin remains encumbered with the same covenant.
>> If Exit and owner signs the covenant is dropped on the output, it becomes a plain Bitcoin again.
>>
>> The Thransfer and Exit signatures could be threshold signatures of a federation, whereby member decide if the proposed transfer transaction complies with whatever unique rules they impose.
>>
>> The result is a federated side chain embedded into the Bitcoin block chain.
>>
>> Bob could purchase some asset guarded by the federation with a transaction:
>>
>> Inputs
>> 100.0001 pk(Bob)
>>
>> Outputs
>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>> 99.9 pk(Transfer)
>>
>> Transfer to Alice with consent of the transfer validators:
>>
>> Inputs
>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>> 100.001 pk(Alice)
>>
>> Outputs
>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>> 100 pk(Bob)
>>
>> Alice might be approved to exit with the exit signature of the federation:
>>
>> Inputs
>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>> 99.9 pk(Transfer)
>>
>> Outputs
>> 99.9999 pk(Alice)
>>
>> Tamas Blummer
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
>
>
-------------- 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/20190630/513968e9/attachment.sig>

2023-06-07 18:19:00

- reply

📅 Original date posted:2019-06-29
📝 Original message:I introduced you to gerneralized covenants[1] earlier, but in a domain specific context that de-routed us from technical discussion. Let me demonstrate the concept in a more generic use:
A covenant
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
would put a coin under the alternative control of a Transfer and Exit keys together with the script in control of the current owner.
Additional transaction level validations of transactions spending input with covenants apply as in [1]
Owner of such coins would be able to transfer them to others provided an addtional Transfer signature, in which case the coin remains encumbered with the same covenant.
If Exit and owner signs the covenant is dropped on the output, it becomes a plain Bitcoin again.
The Thransfer and Exit signatures could be threshold signatures of a federation, whereby member decide if the proposed transfer transaction complies with whatever unique rules they impose.
The result is a federated side chain embedded into the Bitcoin block chain.
Bob could purchase some asset guarded by the federation with a transaction:
Inputs
100.0001 pk(Bob)
Outputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)
Transfer to Alice with consent of the transfer validators:
Inputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100.001 pk(Alice)
Outputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100 pk(Bob)
Alice might be approved to exit with the exit signature of the federation:
Inputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)
Outputs
99.9999 pk(Alice)
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/090fe907/attachment.html>
-------------- 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/20190629/090fe907/attachment.sig>

2023-06-07 18:18:59

- reply

📅 Original date posted:2019-06-30
📝 Original message:My argument does not need the comparison with ICOs.
They were just an example that people pay for the utility of register even though others think the tokens they keep track of are worthless.
Tamas Blummer
> On Jun 30, 2019, at 22:13, Eric Voskuil <eric at voskuil.org> wrote:
>
> ICO tokens can be traded (indefinitely) for other things of value, so the comparison isn’t valid. I think we’ve both made our points clearly, so I’ll leave it at that.
>
> Best,
> Eric
>
>> On Jun 30, 2019, at 12:55, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>>
>>> On Jun 30, 2019, at 20:54, Eric Voskuil <eric at voskuil.org> wrote:
>>>
>>> Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins?
>>
>> I guess we agree that some way of keeping track of ownership is prerequisite for something to aquire value.
>> We likely also agree that the security of that ownership register has great influence to the value.
>>
>> The question remains if a register as utility in itself gives value to the thing needed to use that register.
>> I think it does, if people are interested in what it keeps track of, for whatever reason, even for reasons you find bogus.
>>
>> It was not intentional, but I think I just explained why Ethereum aquired higher market value by being register of ICO tokens.
>>
>> Now back to the coins encumbered with the debt covenant:
>> Transactions moving them constitute a register of covered debt and you need them to update that register.
>> Should some people find such a register useful then those coins needed to update this register will aquire value.
>> Does not matter if you think the concept of covered debt is just as bogus as ICOs.
>>
>> Here some good news: If they aquire value then they offer a way to generate income for hodler by temporarily giving up control.
>>
>> Tamas Blummer
>>
>>>
>>> The meaning in terms of Bitcoin is clear - the “owner” of outputs that represent value (i.e. in the ability to trade them for something else) is recorded publicly and, given Bitcoin security assumptions, cannot be faked. What is not clear is the utility of a record of outputs that cannot be traded for something else. You seem to imply that a record is valuable simply because it’s a record.
>>>
>>> e
>>>
>>>> On Jun 30, 2019, at 11:35, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>
>>>>
>>>>> On Jun 30, 2019, at 19:41, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>
>>>>>
>>>>>> On Jun 30, 2019, at 03:56, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>>> On Jun 29, 2019, at 23:21, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>>>
>>>>>>> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>>>>>>>
>>>>>>
>>>>>> Coins encumbered with the described covenant represent temporary control of a scarce resource.
>>>>>>
>>>>>> Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
>>>>>
>>>>> For something to become property (and therefore have marketable value) requires that it be both scarce and useful. Bitcoin is useful only to the extent that it can be traded for something else that is useful. Above you are only dealing with scarcity, ignoring utility.
>>>>
>>>> There is a deeper utility of Bitcoin than it can be traded for something else. That utility is to use its unforgeable register.
>>>> We have only one kind of units in this register and by having covenants we would create other kinds that are while encumbered not fungible with the common ones.
>>>>
>>>> Units are certainly less desirable if encumbered with a debt covenant. You say no one would assign them any value.
>>>>
>>>> I am not that sure as they still offer the utility of using the unforgeable register, in this case a register of debt covered by reserves.
>>>> You also doubt forcing debt to be covered by reserves is a good idea, I got that, but suppose we do not discuss this here.
>>>> If there are people who think it is a good idea, then they would find having an unforgeable register of it useful and therefore units needed to maintain that register valuable to some extent.
>>>>
>>>>>
>>>>>> I think you do not show the neccesary respect of the market.
>>>>>
>>>>> I’m not sure what is meant here by respect, or how much of it is necessary. I am merely explaining the market.
>>>>>
>>>>
>>>> You are not explaining an existing market but claim that market that is not yet there will follow your arguments.
>>>>
>>>>>> Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
>>>>>
>>>>> It seems to me you have reversed the meaning of temporary and final. Bitcoin is useful because of the presumption that there is no finality of control. One presumes an ability to trade control of it for something else. This is temporary control. Final control would be the case in which, at some point, it can no longer be traded, making it worthless at that point. If this is known to be the case it implies that it it worthless at all prior points as well.
>>>>>
>>>>> These are distinct scenarios. The fact that temporary (in my usage) control implies the possibility of value does not imply that finality of control does as well. The fact that (renowned or otherwise) people have made errors does not imply that I am making an error. These are both non-sequiturs.
>>>>>
>>>>>> I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
>>>>>
>>>>> The analogy to rental of a consumable good does not apply to the case of a non-consumable good. If it cannot be traded and cannot be consumed it cannot obtain marketable value. To this point it matters not whether it exists.
>>>>>
>>>>
>>>> I meant with control the control of entries in the register which I think is the deeper utility of Bitcoin. Final control is meant to be the opposite of temporary which is the time limited control with some expiry.
>>>>
>>>> Thank you for your thoughts as they help to sharpen my arguments.
>>>>
>>>> Best,
>>>>
>>>> Tamas Blummer
>>>>
>>>>> Best,
>>>>> Eric
>>>>>
>>>>>> Tamas Blummer
>>>>>>
>>>>>>
>>>>
>>
-------------- 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/20190630/b632dbbf/attachment.sig>

2023-06-07 18:18:58

- reply

📅 Original date posted:2019-06-30
📝 Original message:> On Jun 30, 2019, at 20:54, Eric Voskuil <eric at voskuil.org> wrote:
>
> Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins?
I guess we agree that some way of keeping track of ownership is prerequisite for something to aquire value.
We likely also agree that the security of that ownership register has great influence to the value.
The question remains if a register as utility in itself gives value to the thing needed to use that register.
I think it does, if people are interested in what it keeps track of, for whatever reason, even for reasons you find bogus.
It was not intentional, but I think I just explained why Ethereum aquired higher market value by being register of ICO tokens.
Now back to the coins encumbered with the debt covenant:
Transactions moving them constitute a register of covered debt and you need them to update that register.
Should some people find such a register useful then those coins needed to update this register will aquire value.
Does not matter if you think the concept of covered debt is just as bogus as ICOs.
Here some good news: If they aquire value then they offer a way to generate income for hodler by temporarily giving up control.
Tamas Blummer
>
> The meaning in terms of Bitcoin is clear - the “owner” of outputs that represent value (i.e. in the ability to trade them for something else) is recorded publicly and, given Bitcoin security assumptions, cannot be faked. What is not clear is the utility of a record of outputs that cannot be traded for something else. You seem to imply that a record is valuable simply because it’s a record.
>
> e
>
>> On Jun 30, 2019, at 11:35, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>>
>>> On Jun 30, 2019, at 19:41, Eric Voskuil <eric at voskuil.org> wrote:
>>>
>>>
>>>> On Jun 30, 2019, at 03:56, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>>>
>>>> Hi Eric,
>>>>
>>>>> On Jun 29, 2019, at 23:21, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>
>>>>> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>>>>>
>>>>
>>>> Coins encumbered with the described covenant represent temporary control of a scarce resource.
>>>>
>>>> Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
>>>
>>> For something to become property (and therefore have marketable value) requires that it be both scarce and useful. Bitcoin is useful only to the extent that it can be traded for something else that is useful. Above you are only dealing with scarcity, ignoring utility.
>>
>> There is a deeper utility of Bitcoin than it can be traded for something else. That utility is to use its unforgeable register.
>> We have only one kind of units in this register and by having covenants we would create other kinds that are while encumbered not fungible with the common ones.
>>
>> Units are certainly less desirable if encumbered with a debt covenant. You say no one would assign them any value.
>>
>> I am not that sure as they still offer the utility of using the unforgeable register, in this case a register of debt covered by reserves.
>> You also doubt forcing debt to be covered by reserves is a good idea, I got that, but suppose we do not discuss this here.
>> If there are people who think it is a good idea, then they would find having an unforgeable register of it useful and therefore units needed to maintain that register valuable to some extent.
>>
>>>
>>>> I think you do not show the neccesary respect of the market.
>>>
>>> I’m not sure what is meant here by respect, or how much of it is necessary. I am merely explaining the market.
>>>
>>
>> You are not explaining an existing market but claim that market that is not yet there will follow your arguments.
>>
>>>> Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
>>>
>>> It seems to me you have reversed the meaning of temporary and final. Bitcoin is useful because of the presumption that there is no finality of control. One presumes an ability to trade control of it for something else. This is temporary control. Final control would be the case in which, at some point, it can no longer be traded, making it worthless at that point. If this is known to be the case it implies that it it worthless at all prior points as well.
>>>
>>> These are distinct scenarios. The fact that temporary (in my usage) control implies the possibility of value does not imply that finality of control does as well. The fact that (renowned or otherwise) people have made errors does not imply that I am making an error. These are both non-sequiturs.
>>>
>>>> I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
>>>
>>> The analogy to rental of a consumable good does not apply to the case of a non-consumable good. If it cannot be traded and cannot be consumed it cannot obtain marketable value. To this point it matters not whether it exists.
>>>
>>
>> I meant with control the control of entries in the register which I think is the deeper utility of Bitcoin. Final control is meant to be the opposite of temporary which is the time limited control with some expiry.
>>
>> Thank you for your thoughts as they help to sharpen my arguments.
>>
>> Best,
>>
>> Tamas Blummer
>>
>>> Best,
>>> Eric
>>>
>>>> Tamas Blummer
>>>>
>>>>
>>
-------------- 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/20190630/cdfe49a4/attachment-0001.sig>

2023-06-07 18:18:57

- reply

📅 Original date posted:2019-06-30
📝 Original message:> On Jun 30, 2019, at 19:41, Eric Voskuil <eric at voskuil.org> wrote:
>
>
>> On Jun 30, 2019, at 03:56, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>> Hi Eric,
>>
>>> On Jun 29, 2019, at 23:21, Eric Voskuil <eric at voskuil.org> wrote:
>>>
>>> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>>>
>>
>> Coins encumbered with the described covenant represent temporary control of a scarce resource.
>>
>> Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
>
> For something to become property (and therefore have marketable value) requires that it be both scarce and useful. Bitcoin is useful only to the extent that it can be traded for something else that is useful. Above you are only dealing with scarcity, ignoring utility.
There is a deeper utility of Bitcoin than it can be traded for something else. That utility is to use its unforgeable register.
We have only one kind of units in this register and by having covenants we would create other kinds that are while encumbered not fungible with the common ones.
Units are certainly less desirable if encumbered with a debt covenant. You say no one would assign them any value.
I am not that sure as they still offer the utility of using the unforgeable register, in this case a register of debt covered by reserves.
You also doubt forcing debt to be covered by reserves is a good idea, I got that, but suppose we do not discuss this here.
If there are people who think it is a good idea, then they would find having an unforgeable register of it useful and therefore units needed to maintain that register valuable to some extent.
>
>> I think you do not show the neccesary respect of the market.
>
> I’m not sure what is meant here by respect, or how much of it is necessary. I am merely explaining the market.
>
You are not explaining an existing market but claim that market that is not yet there will follow your arguments.
>> Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
>
> It seems to me you have reversed the meaning of temporary and final. Bitcoin is useful because of the presumption that there is no finality of control. One presumes an ability to trade control of it for something else. This is temporary control. Final control would be the case in which, at some point, it can no longer be traded, making it worthless at that point. If this is known to be the case it implies that it it worthless at all prior points as well.
>
> These are distinct scenarios. The fact that temporary (in my usage) control implies the possibility of value does not imply that finality of control does as well. The fact that (renowned or otherwise) people have made errors does not imply that I am making an error. These are both non-sequiturs.
>
>> I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
>
> The analogy to rental of a consumable good does not apply to the case of a non-consumable good. If it cannot be traded and cannot be consumed it cannot obtain marketable value. To this point it matters not whether it exists.
>
I meant with control the control of entries in the register which I think is the deeper utility of Bitcoin. Final control is meant to be the opposite of temporary which is the time limited control with some expiry.
Thank you for your thoughts as they help to sharpen my arguments.
Best,
Tamas Blummer
> Best,
> Eric
>
>> Tamas Blummer
>>
>>
-------------- 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/20190630/cf9f6ebc/attachment.sig>

2023-06-07 18:18:56

- reply

📅 Original date posted:2019-06-30
📝 Original message:Hi Eric,
> On Jun 29, 2019, at 23:21, Eric Voskuil <eric at voskuil.org> wrote:
>
> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>
Coins encumbered with the described covenant represent temporary control of a scarce resource.
Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
An example where final control is not available are areas and jurisdictions where land can not be bought only long time rents are offered.
People pay high prices there to step in place of the renter in an existing long term rent contract and they figured out the contracts that work under these restrictions.
Bitcoin’s predominant use is already store of value. Many assume not only wealth preservation but that it would allow to purchase of more goods in the future than now.
This leads to unwillingnes to give up final control, which can resolve in two ways:
- Increasing fiat prices for final control. We see this, and is actually further reinforcing unwillingnes to give up final control.
- dealing with temporary control. We do not yet have the technical means of even representing this. Developing them is my goal.
I think you do not show the neccesary respect of the market.
Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
Tamas Blummer
-------------- 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/20190630/936be150/attachment.sig>

2023-06-07 18:18:55

- reply

📅 Original date posted:2019-06-28
📝 Original message:Hi Eric,
Thank you for your questions as they show what concepts need further explanation, so you understand the potential of this proposal and how it is helpful to the ecosystem.
Riskless zero bond is in fact the most basic concept of financial engineering. Yes, there are engineers of finance, those who create and price financial derivatives (e.g. options, swaps) and structure products such as e.g. ABS, CDO etc.
I used to be one of them.
A zero bond formalizes the observation that 1 unit of currency in the future has different value than 1 unit available now. It is called riskless if it is certain to receive the payment in the future.
If we put this difference of vaue in relation to the amount then we get the “risk freee rate of return”, that you heard of.
E.g if one is willing to exchange 1 BTC unconditionally available now for 1.1 BTC certainly available in a year but not earlier, then the implied “risk free rate of return” is apparently 10% pa. for Bitcoins.
The transaction I construct in the first example achives exactly this, because:
Bob forgoes his ability to use his unconditionally available coins by giving them to Alice with a covenant that ensures that Bob will receive them back later.
Bob does this because Alice pays for this in advance.
Alice can further transfer the coins encumbered by the covenant, but they will unconditionally return to Bob in the future.
The utility of these encumbered coins is that they prove that the loan is fully covered by reserves.
How valuable this utility is will be decided by the market and that value will be interest received by those who temporarily give up control. I am guess the value will be low but positive.
Lending does not mandate fractional or full reserves. These are choices the market or regulators enforce. Full reserve banking is not a fiction but is how things worked before introduction of gold receipts. A bank could only lend gold coins it possesed. Perils of fractional reserve were felt repeatedly by the Bitcoin ecnomy e.g. in the collaps of MtGox.
The idea to return to full reserve banking is not unique to gold bugs or Bitcoin but recently a popular vote was initiated in Switzerland to force Swiss banks to full reserves with respect to lending. This popular vote achived 24% support [1] which is quite remarkable if considered that the topic is not trivial as also our exchange shows.
I published today a writing in medium, that explains the concept of fractional vs. full reserve banking in conjunction with this proposal. Please read: https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479 <https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479>
I would welcome feedback on the generalized covenant construct or its implementation, as I think it can open up much more uses than the few examples I gave.
Tamas Blummer
[1] Vollgeld Initiative: https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html <https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html>
> On Jun 28, 2019, at 19:25, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi Tamas,
>
> There are a number of economic assumptions contained herein. While I understand you would like to focus on implementation, the worst bugs are requirements bugs. IMO these should be addressed first. I’ve addressed some possible issues inline.
>
>> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> I start with a formalisation of loans as common in finance:
>>
>> A zero bond is a contract between two parties Alice and Bob whereby Alice receives an amount less than P and has to pay back P at a later time point called maturity.
>> The difference between the amount received and P is the interest implied by the contract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=P) in a year is the same as getting a loan with 10% p.a. interest.
>>
>> The inherent risk in the contract is that Alice may not honor the agreement or be bankrupt by then.
>>
>> If we could programmatically guarantee that Alice honors the contract then we would be able to create a riskless zero bond, the fundation of financial engineering.
>
> I’m not aware of the basis of this statement. While people use the term “risk free rate of return” there has never actually been such a thing. It’s not clear to me how a unicorn has been the foundation of “financial engineering”, but I’m not also clear and what is intended by “engineering” in this sense. Generally engineering is the implementation of higher level concepts. It is those concepts that constitute requirements here.
>
> At a minimum, interest cannot be guaranteed by this proposal, which implies that at best it guarantees, setting aside changes in purchasing power, a return of principle minus economic interest on that principle (ie opportunity cost). Given that purchasing power changes over time, risk increases with the term of the loan. As such this is not riskless - both volatility and opportunity cost remain as risks.
>
>> A systemic problem with loans is that the lender might operate on fractional reserve, that is lending more than his capital.
>
> This is not a systemic problem, this is the very nature of lending. Fractional reserve is simply a state banking term used to describe the fact that people invest (lend) a fraction of their savings and hoard the rest. It matters not that banks or individuals do this, credit expansion is inherent in economy. Without it there is no investment and therefore no production whatsoever.
>
>> Unchecked inflation of money supply through fractional reserve is creating a mess in the world we live in. Bitcoin could overcome this mess implementing this proposal!
>
> You seem to be conflating state banking with the effects of investing. Taxpayer support for bank investment creates both a moral hazard (and the resulting misallocation of capital to state-favored projects, creating the famed economic “business cycle”) and is a manifestation of persistent monetary inflation (ie seigniorage is a source taxation. Investment implies credit expansion, and the level of this expansion is controlled by time preference alone.
>
>> I stop here with finance speak as the purpose of this mail is not to dive into finance, but to show how loans with full reserve check could be implemented in Bitcoin.
>>
>> 1. Receiving the loan is a payment from Bob to Alice, but we need a restriction how Alice can use the funds, so Bob can get them back unconditionally at maturity, so lending is riskless to him.
>> 2. Bob wants to receive interest, since he gives up his control of the coins until maturity, he can not use them elsewhere until then. That interest could be paid in advance, this can be solved with Bitcoin as is.
>
> Interest cannot be paid in advance. This implies nothing more than a smaller amount of principle.
>
>> How do we allow Alice to use the coins, that is: split/merge and transfer them to others, but still ensure Bob can claim them back at maturity?
>>
>> We ensure that Alice can only send the coins to outputs that inherit a taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity
>>
>> This requires a generalization of the Bitcoin Covenants Idea[1] such that it nicely fits with taproot as follows:
>>
>> 1. A covenant in the form of '_ covenant C’ on output means that it can be spent to an output that maches the covenant pattern with placeholder _ and the output(s) will be assigned 'covenant C'.
>> 2. A covenant that mandates an output script with alternate validation paths can also assign alternate covernants to be inherited by the output(s) depending on which path was used to spend the input eg. 'covenant or(c covenant C, d covernant D)’
>> 3. The resulting covenant of outputs should be reduced following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
>> 4. express transitivity with 'covenant transitive’ which means the output will have the same covenant as the input
>> 5. allow to omit covenant on the output with 'covenant drop'
>>
>> The covenant Bob would assign to the loan output sent to Alice is: 'covenant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
>> - Alice can send to an output script where she is free to chose the embedded script at the placeholder _ and that output will again have the same covenant as the input.
>> - After maturity Bob can claim any coin that is transitively rooted in the loan (more on this later) and the covenant will no longer be assigned to his new output(s).
>>
>> Assuming Alice wants to send some of the borrowed coins to Charlie:
>>
>> for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the script that gives Bob control after maturity.
>>
>> Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) covenant transitive)
>> Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) covenant transitive) is a promissory note issued by Alice to Charlie, here is why:
>>
>> If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he trusts, that Alice will offer a regular payment in exchange for it before maturity, since that output is worthless to Charlie after maturity as Bob can just take it.
>>
>> It seems at the first sight that there is no value in these outputs for Charlie, since he still has to ensure Alice replaces them before maturity.
>>
>> The value of these outputs to Charlie is the proof that he has exclusive control of the coins until maturity.
>
> At a minimum, money that predictably depreciates (to zero in this case) must be discounted accordingly. How much is money worth today that is worth zero tomorrow? This can be observed with both inflation and demurrage money. This also implies that each encumbered coin is not fungible with any other of a distinct discount schedule.
>
> What is the economic consequence of lending discounted money? Lower interest rates. How much lower? The rate of depreciation. This can also be observed with inflation and demurrage, but observation isn’t required. This is a necessary outcome.
>
> So when one lends 1 demurrage coin for a term one cannot earn interest on 1 coin, one is earning interest on a fraction of a coin. That fraction creates credit expansion and reduces return in direct proportion to the risk that has been offset. In other words, the risk cost has been converted to opportunity cost. The discounted fraction earns no interest.
>
> So credit expansion and risk remain, in the same proportions as without such a system. However lack of fungibility introduces an additional overhead cost.
>
> e
>
>> Alice can not issue promissory notes in excess of own capital or capital that she was able to borrow. No coin inflation or fractional reserve here, which also reduces the credit risk Charlie takes.
>>
>> Due to the transitive covenant Charlie could pass on the coins to an other temporary owner until maturity when Bob would re-collect them unconditionally.
>>
>> Should Charlie no longer be comfortable with Alice’s promise or need final coins (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo) agreement with him.
>>
>> Charlie would receive final coins from Dan in exchange for the temporarily controled coins and Charlie's promise to replace them with final coins before maturity.
>> Dan would thereby charge high interest through a discount since as he has to bear the credit risk of Charlie. This is not a riskless but a plain zero bond.
>>
>> Why would Dan want to take temporary control of the coins at all? Again, to ensure Charlie is not doing yet another repo with Frank on the same coins, the sum of Charlie's repo deals are not in excess of his claims against others.
>> This again avoids lending in excess of coin supply and reduces the credit risk Dan takes.
>>
>> Here are the sketches for the transacions for above alternate actions:
>>
>> lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)’
>>
>> the transactions offer a fee of 0.0001
>>
>> Bob gives a riskless credit to Alice:
>>
>> Input Output
>> 1 pk(Bob) 1 or(b,pk(Alice) covenant c)
>> 0.1 pk(Alice) 0.9999 pk(Bob)
>>
>> Alice could send a 0.5 promissory note to Charlie:
>>
>> Input Output
>> 1 or(pk(Alice) covenant c) 0.5 or(b,pk(Charlie) covenant c)
>> 1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
>> 0.9999 pk(Alice)
>>
>> Alice could make good of the note before maturity, pay some interest and get back temporary control of the coins with:
>> Input Output
>> 0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Alice) covenant c)
>> 0.5101 pk(Alice) 0.51 pk(Charlie)
>>
>> alternatively Charlie borrows from Dan at high interest:
>>
>> Input Output
>> 0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Dan) covenant c)
>> 0.3001 pk(Dan) 0.3 pk(Charlie)
>>
>> and Charlie re-purchases the temporary coins before maturity, making good of the repo with Dan:
>>
>> Input Output
>> 0.5 or(b,pk(Dan) covenant c) 0.5 or(b,pk(Charlie) covenant c)
>> 0.5001 pk(Charlie) 0.5 pk(Dan)
>>
>> We need to define further transaction level validations for transactions spending inputs with covenants as follows:
>>
>> 1. If there are inputs without covenant before the input with covenant than inputs without covenant must be spent exactly with outputs preceeding the outputs with covenants.
>> 2. A transaction can have inputs with different covenants, their allocation to outputs should follow input order.
>> 3. For output(s) that share input(s) with covenant, the sum of covenant outputs must exactly add up to the input(s). This allows merging and splitting them.
>>
>> Bob would re-collect his coins at maturity unconditionally. Who followed through promises or defaulted down the transitive chain is irrelevant to him.
>> Remark: we might also need a covenant attribute defining the minimum size of output, so Bob is not forced to collect dust, which would be expensive or even impossible. I am not yet happy with this solution, looking for better.
>>
>> I am very excited about the possibilities this proposal would unlock and ask you verify usefulness of this scheme and join working out the details and how covenants would be integrated with taproot.
>>
>> Tamas Blummer
>>
>> [1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/b6aef1d2/attachment-0001.html>
-------------- 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/20190628/b6aef1d2/attachment-0001.sig>

2023-06-07 18:18:54

- reply

📅 Original date posted:2019-06-28
📝 Original message:I start with a formalisation of loans as common in finance:
A zero bond is a contract between two parties Alice and Bob whereby Alice receives an amount less than P and has to pay back P at a later time point called maturity.
The difference between the amount received and P is the interest implied by the contract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=P) in a year is the same as getting a loan with 10% p.a. interest.
The inherent risk in the contract is that Alice may not honor the agreement or be bankrupt by then.
If we could programmatically guarantee that Alice honors the contract then we would be able to create a riskless zero bond, the fundation of financial engineering.
A systemic problem with loans is that the lender might operate on fractional reserve, that is lending more than his capital.
Unchecked inflation of money supply through fractional reserve is creating a mess in the world we live in. Bitcoin could overcome this mess implementing this proposal!
I stop here with finance speak as the purpose of this mail is not to dive into finance, but to show how loans with full reserve check could be implemented in Bitcoin.
1. Receiving the loan is a payment from Bob to Alice, but we need a restriction how Alice can use the funds, so Bob can get them back unconditionally at maturity, so lending is riskless to him.
2. Bob wants to receive interest, since he gives up his control of the coins until maturity, he can not use them elsewhere until then. That interest could be paid in advance, this can be solved with Bitcoin as is.
How do we allow Alice to use the coins, that is: split/merge and transfer them to others, but still ensure Bob can claim them back at maturity?
We ensure that Alice can only send the coins to outputs that inherit a taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity
This requires a generalization of the Bitcoin Covenants Idea[1] such that it nicely fits with taproot as follows:
1. A covenant in the form of '_ covenant C’ on output means that it can be spent to an output that maches the covenant pattern with placeholder _ and the output(s) will be assigned 'covenant C'.
2. A covenant that mandates an output script with alternate validation paths can also assign alternate covernants to be inherited by the output(s) depending on which path was used to spend the input eg. 'covenant or(c covenant C, d covernant D)’
3. The resulting covenant of outputs should be reduced following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive’ which means the output will have the same covenant as the input
5. allow to omit covenant on the output with 'covenant drop'
The covenant Bob would assign to the loan output sent to Alice is: 'covenant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
- Alice can send to an output script where she is free to chose the embedded script at the placeholder _ and that output will again have the same covenant as the input.
- After maturity Bob can claim any coin that is transitively rooted in the loan (more on this later) and the covenant will no longer be assigned to his new output(s).
Assuming Alice wants to send some of the borrowed coins to Charlie:
for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the script that gives Bob control after maturity.
Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) covenant transitive)
Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) covenant transitive) is a promissory note issued by Alice to Charlie, here is why:
If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he trusts, that Alice will offer a regular payment in exchange for it before maturity, since that output is worthless to Charlie after maturity as Bob can just take it.
It seems at the first sight that there is no value in these outputs for Charlie, since he still has to ensure Alice replaces them before maturity.
The value of these outputs to Charlie is the proof that he has exclusive control of the coins until maturity.
Alice can not issue promissory notes in excess of own capital or capital that she was able to borrow. No coin inflation or fractional reserve here, which also reduces the credit risk Charlie takes.
Due to the transitive covenant Charlie could pass on the coins to an other temporary owner until maturity when Bob would re-collect them unconditionally.
Should Charlie no longer be comfortable with Alice’s promise or need final coins (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo) agreement with him.
Charlie would receive final coins from Dan in exchange for the temporarily controled coins and Charlie's promise to replace them with final coins before maturity.
Dan would thereby charge high interest through a discount since as he has to bear the credit risk of Charlie. This is not a riskless but a plain zero bond.
Why would Dan want to take temporary control of the coins at all? Again, to ensure Charlie is not doing yet another repo with Frank on the same coins, the sum of Charlie's repo deals are not in excess of his claims against others.
This again avoids lending in excess of coin supply and reduces the credit risk Dan takes.
Here are the sketches for the transacions for above alternate actions:
lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)’
the transactions offer a fee of 0.0001
Bob gives a riskless credit to Alice:
Input Output
1 pk(Bob) 1 or(b,pk(Alice) covenant c)
0.1 pk(Alice) 0.9999 pk(Bob)
Alice could send a 0.5 promissory note to Charlie:
Input Output
1 or(pk(Alice) covenant c) 0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
0.9999 pk(Alice)
Alice could make good of the note before maturity, pay some interest and get back temporary control of the coins with:
Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Alice) covenant c)
0.5101 pk(Alice) 0.51 pk(Charlie)
alternatively Charlie borrows from Dan at high interest:
Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Dan) covenant c)
0.3001 pk(Dan) 0.3 pk(Charlie)
and Charlie re-purchases the temporary coins before maturity, making good of the repo with Dan:
Input Output
0.5 or(b,pk(Dan) covenant c) 0.5 or(b,pk(Charlie) covenant c)
0.5001 pk(Charlie) 0.5 pk(Dan)
We need to define further transaction level validations for transactions spending inputs with covenants as follows:
1. If there are inputs without covenant before the input with covenant than inputs without covenant must be spent exactly with outputs preceeding the outputs with covenants.
2. A transaction can have inputs with different covenants, their allocation to outputs should follow input order.
3. For output(s) that share input(s) with covenant, the sum of covenant outputs must exactly add up to the input(s). This allows merging and splitting them.
Bob would re-collect his coins at maturity unconditionally. Who followed through promises or defaulted down the transitive chain is irrelevant to him.
Remark: we might also need a covenant attribute defining the minimum size of output, so Bob is not forced to collect dust, which would be expensive or even impossible. I am not yet happy with this solution, looking for better.
I am very excited about the possibilities this proposal would unlock and ask you verify usefulness of this scheme and join working out the details and how covenants would be integrated with taproot.
Tamas Blummer
[1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
-------------- 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/20190628/25fe4569/attachment-0001.sig>

2023-06-07 18:18:42

- reply

📅 Original date posted:2019-06-13
📝 Original message:ZmnSCPxj already observed in [1] that these ops would enable introspection of any field of the transactions and make both `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVERIFY` superfluous.
There is much more to this as enumerated in generic terms by Russel O’Connor below and I would like to add a concrete example.
We could implement oracle less difficulty contracts without the need the of a CISC type OP_WORKVERIFY but instead through resurrection/extension of OP_CAT, OP_GREATERTHANOREQUAL and introduction of a new RISC opcode OP_CHECKBLOCKATHEIGHT[3] suggested by Luke Dashjr. Thanks for the pointer to Nathan Cook [4]
Technically we could resurrect and add them without burning more than one OP_NOP by redefining it as a prefix (OP_EXTENSION), such as:
OP_EXTENSION OP_CAT would become a two byte opcode pointing to a resurrected implementation of OP_CAT.
This could be soft forked in.
A concrete oracle less difficulty contract could look like:
It is an european digital call option on target difficulty after maturity and 10 blocks notice period. I gave you reasons while having these would increase bitcoin's security in [2]
IF
<maturity as block height + 10> CHECKLOCKTIMEVERIFY DROP
<speculator’s key> CHECKSIGVERIFY
ELSE
OP_DUP <maturity as block height - 1> OP_CHECKBLOCKATHEIGHT OP_LESSTHANEQUAL OP_VERIFY
OP_SWAP OP_CAT OP_CAT OP_HASH256 <contracted target> OP_LESSTHANEQUAL OP_VERIFY
<miner’s key> CHECKSIGVERIFY
ENDIF
insurance premium could be collected by the seller of the insurance after maturity + 10 blocks if target difficulty was not reached
<speculator’s signature>
miner would get back its insurance premium plus collateral of the seller if target difficulty was not reached at maturity. Miner has 10 blocks time after maturity to claim with:
<maturity block header after prevhash> <maturity block version> <prevhash>
The stack would be in second case processed as:
1: after pushes
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
2: after OP_DUP:
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
3: after push
<maturity as block height - 1>
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
4: after OP_CHECKBLOCKATHEIGHT OP_VERIFY is successful proving that prevhash is the block at maturity block height - 1
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
5: after OP_SWAP
<block version>
<maturity block prevhash>
<block header after prevhash>
6: after OP_CAT
<maturity block version concatenated with maturity prevhash>
<maturity block block header after maturity prevhash>
7: after OP_CAT
<complete block header>
8: after OP_HASH256
<block hash computed for header>
9: after push
<contracted target>
<block hash computed for header>
10: after OP_GREATERTHANOREQUAL OP_VERIFY proves that contracted target was reached
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html>
[3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki <https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html>
[5] https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h <https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h>
> On May 22, 2019, at 23:01, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations. However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language features.
>
> Bitcoin Script appears designed to be a flexible programmable system that provides generic features to be composed to achieve various purposes. Thus, when we design new language features for Script, we should be striving, as much as possible, to similarly build general purpose tools which can in turn be used for a variety of purposes.
>
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design goals. They are both are designed with very narrow applications in mind, while also going out of their way to extend the semantic domain of the interpretation of Bitcoin operations in new ways that complicate their specification. In the case of SIGHASH_ANYPREVOUT, the semantic domain is extended by adding new counters to track the use of various v0 and v2 signature types. In the case of OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that peeks at the value of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. OP_CAT pops two byte arrays off the stack and pushes their concatenation back onto the stack. OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the stack and performs a bip-schnorr verification on the SHA256 hash of the message.
>
> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + <> Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the nature of the construction.
> + <> Decide if a transaction has exactly one input or not. (etc.)
> + Weak covenants, which can verify output scripts to see if they are among a set of predefined values or verify the output hash.
>
> and presumably more applications as well.
>
> For better or for worse, without an OP_PUBKEYTWEEK operation available, the more interesting recursive-covenants remain largely out of reach, with the exception of a recursive covenant that is only able to send back to its own address, possibly abusing its own TXO value as a state variable.
>
> All this is accomplished by two straightforward opcodes whose semantics are pure computational operations on stack values. The only semantic side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the existing 'sigops_passed' count. Moreover, I feel that adding these operations does not preclude adding more specialized opcodes in the future as an optimization for whatever popular constructions come up, once we know what those are.
>
> I feel that this style of generic building blocks truly embodies what is meant by "programmable money".
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190613/4583e8b3/attachment-0001.html>
-------------- 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/20190613/4583e8b3/attachment-0001.sig>

2023-06-07 18:18:40

- reply

📅 Original date posted:2019-06-08
📝 Original message:In an earlier post [1] I suggested an approach to create native Bitcoin contracts that reduce mining's income volatility and received very helpful comments on implementation from Pieter Wuille [2] and Natanael [3]
After processing those comments I instead suggest the following restricted interpretation of nSequence and a new opcode WORKVERIFY that in combination is easier to implement and reason about as it follows the implementation pattern of CHECKSEQUENCEVERIFY[5]
Accumulated work on the blockchain is strictly increasing, therefore transaction eligibility rule with a >= condition on it would need no re-evaluation for descendant blocks, in mempool or at re-org, since additional blocks or re-org can only increase the accumulated work. Accumulated work is just like time, it is actually an alternate measure of time through computation[6], therefore analogous to MTP based restriction implemented with BIP68 [4].
=== (the implementation proposal) ===
(needs soft fork for two reasons, activation logic tbd.)
I. Stricter interpretation of nSequence to optionally refer accumulated work:
Only if bit 31 AND bit 30 is set in nSequence can the transaction be included into any block. This is a restricting a rule of BIP68 [4] that only required bit 31 to be set for unrestricted inclusion into blocks. Otherwise nSequence refers to accumulated work (see encoding later) and it is only viable to include the transaction into a block if the block has >= work accumulated. This would define the meaning of one additional bit in nSequence, but leave all other freedom of later improvement left by BIP68.
II. New WORKVERIFY opcode redefining a NOPx in transaction script as:
Terminate script with false for any reason described in BIP112 or if bit 31 is set but bit 30 is not set and 256 bit unsigned integer on stack is higher than (nSequence &0xffff)>> 6 * 2^((nSequence & 0x3f) + 84)
=== (end proposal) ===
Notes on the work encoding:
Total accumulated work as of now is > 2^90 and if we assume that mining capacity keeps increasing with Moore’s law (double every year) for the next 50 years, then it could sum up to 2^140. We have much less bits available in nSequence therefore we have to encode accumulated work in a floating point number with sufficient precision.
The work accumulated during the current difficulty adjustment cycle is > 2016 * 2^74 which is > 2^84. It is rather unlikely that accumulated work in a difficulty adjustment period drops below 2^80 ever again in future which means we need not be more precise than 2^80/2^90 or 2^-10 to allow for contracts that reference increment until the next adjustment. Therefore a mantissa of 10 bits should be sufficient. Using 6 bits of exponent and an offset of 2^84 we can express the range of [2^84, 2^148) that should be sufficient now and for foreseeable future. Please let me know if the approach is not optimal or future proof in your opinion.
Why, should we build this into Bitcoin ?
The most influential risk factor in miners' investment decision is the anticipated change of difficulty over the time horizon of the mining equipment's expected lifetime. Their investments secure the network. The ability to create contracts that reduce income volatility would lead to additional investment into mining.
A native Bitcoin contract is far superior to alternatives that could be offered on traditional markets as:
a native Bitcoin contract would be:
- uncensorable: It requires only the agreement to terms between those financially involved
- fully collaterized: no counterparty risk which means Miner could buy hedging contracts from any unkown and un-trusted actor that is able to commit collateral
- no oracle is needed
- no disagreement on the settlement
- publicly observable: allow to observe market opinion on future difficulty
- the length of the contract could match miner's investment horizon extending over several difficulty adjustments.
Why not on a side-chain ?
Work is fundamental and intrinsic to the base layer. A contract that reduces earnings volatility helps to attract more capital for mining and therefore increase security on the base layer.
How would this be used?
Miner and Speculator sign a transaction that has an nLockTime of S in the future. This gives both parties the option to alternatively spend committed output in case the other would not follow through and publish committing the collateral until S.
Speculators contribution to collateral is higher than that of the Miner. Miner’s collateral is the premium for the insurance provided by Speculator.
The single output of the transaction has following script:
IF
<maturity> CHECKLOCKTIMEVERIFY DROP
<speculator’s key> CHECKSIGVERIFY
ELSE
<sufficient work> WORKVERIFY DROP
<miner’s key> CHECKSIGVERIFY
ENDIF
This allows the speculator to take back its collateral plus the option premium after the maturity time point, which would however only be possible if it was not taken earlier by Miner as sufficient work was reached.
The contract in finance terms is an american digital call option with maturity and sufficient work as strike. The Miner profits of the contract if work accumulated is more than contracted in which case he would also have lower mining income, hence the contract would reduce earnings shortcome. The Speculator would earn the option premium if the contracted work was not required until maturity. In this case higher mining income through higher market share compensates Miner for the loss of option premium. In both cases Miner’s income volatility is reduced. The Speculator may find it attractive to enter the contract if the probability weighted option premium represents an attractive interest on the capital committed.
Contracted work would reflect the consenus of expected difficulty increase over future time horizons. Observing above contracts on the blockchain would allow calculation of market implied forward curve of mining difficulty and its implied volatility which again would help evaluating investment proposals into mining.
An alternate more flexible setup would be a Lightning Network like re-allocation of total collateral. Which would allo parties to mark the option to market (observed work and volatility) as time passes and allow for cooperative unwind.
Tamas Blummer
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016952.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016969.html
[4] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[5] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
[6] https://medium.com/@tamas.blummer/measuring-time-with-chain-of-blocks-893a38cc06bb
-------------- 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/20190608/fae077b6/attachment.sig>

2023-06-07 18:18:15

- reply

📅 Original date posted:2019-05-24
📝 Original message:yes, log2work is already computed and would be a strictly increasing value, like time. Thank you for this suggestion. I think attempting an implementation will give further clues it this more suitable to express the same.
Tamas Blummer
> On May 24, 2019, at 10:36, Natanael <natanael.l at gmail.com> wrote:
>
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
>
> To deal with potentially wildly varying difficulty, could the value exposed be the sum of accumulated PoW, or in other words the sum of each block's difficulty value in the entire chain? This should be a value that will only rise unless a reorg happens after a difficulty drop happens (only likely to be the result of users manually blacklisting an otherwise valid block that is several blocks back in the chain).
>
> This mimics the effect of the block number which only grows. So if you're starting at time A with difficulty X, then you'd estimate what you think the accumulated PoW ought to be at time B with expected difficulty Y (as compared to the current value at time A), and put that value into the script.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/5d92fa56/attachment.html>
-------------- 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/20190524/5d92fa56/attachment.sig>

2023-06-07 18:18:14

- reply

📅 Original date posted:2019-05-23
📝 Original message:> On May 23, 2019, at 21:45, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who entered the bet.
>> The winner would broadcast.
>
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
>
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
>
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.
Thanks for these suggestions I will follow up while preparing the BIP.
>
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
>
This is the best reception I could have hoped for :)
> Cheers,
>
> --
> Pieter
-------------- 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/20190523/9b03f58a/attachment.sig>

2023-06-07 18:18:13

- reply

📅 Original date posted:2019-05-23
📝 Original message:Block hash can suggest much higher difficulty than what is in effect, so OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level of the bet.
> On May 23, 2019, at 21:45, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> I see. The uncompressing needs to be done either to compare. How are chances for that BIP?
>
> This BIP would be explicitly offering risk managment of miners biggest risk.
> Doing so without relying on external markets or oracle, self cointained would be an impressive and adequate feature.
>
> Tamas Blummer
>
>> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook at gmail.com> wrote:
>>
>> It's true that it fetches the block hash; the idea is to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN.
>>
>> Nathan Cook
>>
>>
>> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>> That opcode would not help as it fetches block hash and not the content of the header.
>>
>>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook at gmail.com> wrote:
>>>
>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and the ensuing thread.
>>>
>>> Nathan Cook
>>>
>>>
>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
>>> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>>>
>>> I think we could do much better than them natively within Bitcoin.
>>>
>>> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
>>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
>>> The output script may then decide comparing that value with a strike which key can spend it.
>>> The input of the transaction would be a multi-sig escrow of those who entered the bet.
>>> The winner would broadcast.
>>>
>>> Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
>>>
>>> I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
>>>
>>> Do you see a fault in this proposal or want to contribute?
>>>
>>> Tamas Blummer
>>>
>>> _______________________________________________
>>> 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/20190523/7a642174/attachment.sig>

2023-06-07 18:18:13

- reply

📅 Original date posted:2019-05-23
📝 Original message:I see. The uncompressing needs to be done either to compare. How are chances for that BIP?
This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would be an impressive and adequate feature.
Tamas Blummer
> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook at gmail.com> wrote:
>
> It's true that it fetches the block hash; the idea is to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
> That opcode would not help as it fetches block hash and not the content of the header.
>
>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook at gmail.com> wrote:
>>
>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and the ensuing thread.
>>
>> Nathan Cook
>>
>>
>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> 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/20190523/ac6e377c/attachment.sig>

2023-06-07 18:18:12

- reply

📅 Original date posted:2019-05-23
📝 Original message:That opcode would not help as it fetches block hash and not the content of the header.
> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook at gmail.com> wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki <https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html> and the ensuing thread.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
> The output script may then decide comparing that value with a strike which key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190523/e41fcfc1/attachment.html>
-------------- 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/20190523/e41fcfc1/attachment.sig>

2023-06-07 18:18:11

- reply

📅 Original date posted:2019-05-23
📝 Original message:The parameter used is property of the block just like the block height is a property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.
The transaction itself was not invalid in a re-org but evtl. others spending it if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.
Tamas Blummer
> On May 23, 2019, at 21:03, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
>
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> 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/20190523/c2fb6e5b/attachment.sig>

2023-06-07 18:18:11

- reply

📅 Original date posted:2019-05-23
📝 Original message:Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
I think we could do much better than them natively within Bitcoin.
A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
The output script may then decide comparing that value with a strike which key can spend it.
The input of the transaction would be a multi-sig escrow of those who entered the bet.
The winner would broadcast.
Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.
I plan to draft a BIP for this as I think this opcode would serve significant economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not to introduce 3rd party to do so.
Do you see a fault in this proposal or want to contribute?
Tamas Blummer

2023-06-07 18:17:33

- reply

📅 Original date posted:2019-04-03
📝 Original message:Hi ZmnSCPxj,
Thought provoking, thank you!
Something I dislike in the scheme, that one could not tell which party colluded with the escrow agent.
Tamas Blummer
> On Apr 4, 2019, at 03:55, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain. Often this means creating a new blockchain, or at least a sidechain to an existing blockchain. This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:54

- reply

📅 Original date posted:2019-03-07
📝 Original message:It is highly unikely that non-engineers will adopt scientific notation or mili/nano/pico prefixes for money.
All common currencies either have no change or one that is 1/100 of the base unit.
This is the convention that practically all existing finance software and non-Bitcoin related UI that deals with money assumes.
Ignoring evident cultural preference and all pre-existenting finance related software is blatant Bitcoin engineering blindness.
We already had a BIP for bits, which I support for above reasons. https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki
Tamas Blummer
> On Mar 7, 2019, at 00:35, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The idea has been floated around to switch to satoshi as a base unit.
>
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
>
>> The lightning network uses satoshis as a base unit.
>
> It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
> btc), which is significantly smaller.
>
>> Pleas let me know if it would be appropriate to write a BIP for it.
>
> Please don't.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:25

- reply

📅 Original date posted:2019-02-06
📝 Original message:I do not think this ad hominem attack of you on me was justified.
I wrote code, gathered and shared data now and back in 2018. I showed
understanding of non technical issues. Is there an actual action that
defies my observation that a commitment is not yet in sight?
Is there anything technically wrong in what I wrote?
If not you should stop.
Tamas Blummer
On Wed, 6 Feb 2019, 18:17 Gregory Maxwell <greg at xiph.org wrote:
> On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer <tamas.blummer at gmail.com>
> wrote:
> > I am skeptical that commitment of any filter will come into Core soon.
> [...] A committed filter makes light clients much more reliable and
> attractive, for some taste too much more.
>
> You keep repeating this smear. Please stop.
>
> If you would actually bother reading the threads where this was
> discussed previously you will see that there was significant interest
> from bitcoin developers to eventually commit an output filter, and a
> significant investment of effort in improving the proposal to that
> end. It is really disheartening to see you continue to repeat your
> negative assumptions about other people's wishes when you haven't even
> invested the time required to read their words.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190206/8a032707/attachment-0001.html>

2023-06-07 18:16:25

- reply

📅 Original date posted:2019-02-06
📝 Original message:The attack was in your implication that I would assume ill intent of those
contributed to the proposal. That is not my position. I explained why, I
think, rolling out a commitment could face opposition. This foreseable
opposition, that must not come from you makes me prefer a provable
uncommitted filter for now.
I am myself concerned of the implications if many nodes would blindly
follow POW.
I did restart the discussion which I read and participated in at its first
instance because implementing the current proposal taught me how
problematic as is until not committed and because I have not seen a sign to
assume commitment was imminent.
This is not just missing code. AFAIK we do not even have a consensus on how
any future soft fork would be activated.
While trying to build a useful software I have to make assumtions on the
timeline of dependencies and in my personal evaluation commitment is not
yet to build on.
I and others learned in this new discussion new arguments such as that of
atomic swaps by Laolu. If nothing else, this was worth of learning.
It appears me that it is rather you assuming ill intent on my side, which
hurts given that I do contribute to the ecosystem since many years and have
not ever been caught of hurting the project.
Tamas Blummer
On Wed, 6 Feb 2019, 20:16 Gregory Maxwell <gmaxwell at gmail.com wrote:
> On Wed, Feb 6, 2019 at 7:48 PM Tamas Blummer <tamas.blummer at gmail.com>
> wrote:
> > I do not think this ad hominem attack of you on me was justified.
>
> I apologize if I have offended you, but I am at a loss to find in my
> words you found to be an attack. Can you help me out?
>
> On reread the only thing I'm saying is that you hadn't even read the
> prior discussion. Am I mistaken? If so, why did you simply propose
> reverting prior improvements without addressing the arguments given
> the first time around or even acknowledging that you were rehashing an
> old discussion?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190206/2f3af794/attachment-0001.html>

2023-06-07 18:16:24

- reply

📅 Original date posted:2019-02-06
📝 Original message:Hi Laolu,
space savings come with the rather serious current disadvantage, that a light client is not
in the position to check the filter. Also the advanced uses you mention are subject to this, for now.
Building more on a shaky fundament does not make it look better.
Now that we have seen advantages of both filters, what keeps us from offering both by Core?
Computing the addional spent-outpoint output-script filter is cheaper than the current one as
it can be done with the block as only context, it does not need UTXO nor undo blocks no journals or
whatever else. I do not see how my statement regarding this was incorrect.
There is a political issue though, why I favor better provable uncommitted filter:
I am skeptical that commitment of any filter will come into Core soon.
The reason of my skepticism is political, not technical.
A committed filter makes light clients much more reliable and attractive, for some taste too much more.
Clients that follow PoW are not significant on the current network. Core nodes enforce many more rules,
some as important as miners' reward. A committed filter would strengthen light clients
significantly, such that perhabs too many were compelled using them instead of a Core node.
Would the remaining Core nodes be sufficient to enforce checks not covered? I see how this is a dilemma.
Is this a dilemma because we think black-white? Light(er) clients might implement checks that are more
than blind PoW trust even if less than all Core checks. Has the time come to allow for this?
Tamas Blummer
> On Feb 6, 2019, at 01:17, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Tamas,
>
> > The only advantage I see in the current design choice is filter size, but
> > even that is less impressive in recent history and going forward, as address
> > re-use is much less frequent nowadays than it was Bitcoin’s early days.
>
> Gains aren't only had with address re-use, it's also the case that if an
> input is spent in the same block as it was created, then only a single items
> is inserted into the filter. Filters spanning across several blocks would
> also see savings due to the usage of input scripts.
>
> Another advantage of using input scripts is that it allows rescans where all
> keys are known ahead of time to proceed in parallel, which can serve to
> greatly speed up rescans in bitcoind. Additionally, it allows light clients
> to participate in protocols like atomic swaps using the input scripts as
> triggers for state transitions. If outpoints were used, then the party that
> initiated the swap would need to send the cooperating party all possible
> txid's that may be generated due to fee bumps (RBF or sighash single
> tricks). Using the script, the light client simply waits for it to be
> revealed in a block (P2WSH) and then it can carry on the protocol.
>
> > Clear advantages of moving to spent outpoint + output script filter:
>
> > 1. Filter correctness can be proven by downloading the block in question only.
>
> Yep, as is they can verify half the filter. With auxiliary data, they can
> verify the entire thing. Once committed, they don't need to verify at all.
> We're repeating a discussion that played out 7 months ago with no new
> information or context.
>
> > 2. Calculation of the filter on server side does not need UTXO.
>
> This is incorrect. Filter calculation can use the spentness journal (or undo
> blocks) that many full node implementations utilize.
>
> > This certainly improves with a commitment, but that is not even on the
> > roadmap yet, or is it?
>
> I don't really know of any sort of roadmaps in Bitcoin development. However,
> I think there's relatively strong support to adding a commitment, once the
> current protocol gets more usage in the wild, which it already is today on
> mainnet.
>
> > Should a filter be committed that contains spent outpoints, then such
> > filter would be even more useful
>
> Indeed, this can be added as a new filter type, optionally adding created
> outpoints as you referenced in your prior email.
>
> > Since Bitcoin Core is not yet serving any filters, I do not think this
> > discussion is too late.
>
> See my reply to Matt on the current state of deployment. It's also the case
> that bitcoind isn't the only full node implementation used in the wild.
> Further changes would also serve to delay inclusion into bitcoind. The
> individuals proposing these PRs to bitcoind has participated in this
> discussion 7 months ago (along with many of the contributors to this
> project). Based in this conversation 7 months ago, it's my understanding
> that all parties are aware of the options and tradeoffs to be had.
>
> -- Laolu
>
>
> On Tue, Feb 5, 2019 at 12:10 PM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> Hi Laolu,
>
> The only advantage I see in the current design choice is filter size, but even that is less
> impressive in recent history and going forward, as address re-use is much less frequent nowadays
> than it was Bitcoin’s early days.
>
> I calculated total filter sizes since block 500,000:
>
> input script + output script (current BIP): 1.09 GB
> spent outpoint + output script: 1.26 GB
>
> Both filters are equally useful for a wallet to discover relevant transactions, but the current design
> choice seriously limits, practically disables a light client, to prove that the filter is correct.
>
> Clear advantages of moving to spent outpoint + output script filter:
>
> 1. Filter correctness can be proven by downloading the block in question only.
> 2. Calculation of the filter on server side does not need UTXO.
> 3. Spent outpoints in the filter enable light clients to do further probabilistic checks and even more if committed.
>
> The current design choice offers lower security than now attainable. This certainly improves with
> a commitment, but that is not even on the roadmap yet, or is it?
>
> Should a filter be committed that contains spent outpoints, then such filter would be even more useful:
> A client could decide on availability of spent coins of a transaction without maintaining the UTXO set, by
> checking the filters if the coin was spent after its origin proven in an SPV manner, evtl. eliminating false positives
> with a block download. This would be slower than having UTXO but require only immutable store, no unwinds and
> only download of a few blocks.
>
> Since Bitcoin Core is not yet serving any filters, I do not think this discussion is too late.
>
> Tamas Blummer
>
>
> > On Feb 5, 2019, at 02:42, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> >
> > Hi Tamas,
> >
> > This is how the filter worked before the switch over to optimize for a
> > filter containing the minimal items needed for a regular wallet to function.
> > When this was proposed, I had already implemented the entire proposal from
> > wallet to full-node. At that point, we all more or less decided that the
> > space savings (along with intra-block compression) were worthwhile, we
> > weren't cutting off any anticipated application level use cases (at that
> > point we had already comprehensively integrated both filters into lnd), and
> > that once committed the security loss would disappear.
> >
> > I think it's too late into the current deployment of the BIPs to change
> > things around yet again. Instead, the BIP already has measures in place for
> > adding _new_ filter types in the future. This along with a few other filter
> > types may be worthwhile additions as new filter types.
> >
> > -- Laolu
> >
> > On Mon, Feb 4, 2019 at 12:59 PM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> > I participated in that discussion in 2018, but have not had the insight gathered by now though writing both client and server implementation of BIP157/158
> >
> > Pieter Wuille considered the design choice I am now suggesting here as alternative (a) in: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html
> > In his evaluation he recognized that a filter having spent output and output scripts would allow decision on filter correctness by knowing the block only.
> > He did not evaluate the usefulness in the context of checkpoints, which I think are an important shortcut here.
> >
> > Yes, a filter that is collecting input and output scripts is shorter if script re-use is frequent, but I showed back in 2018 in the same thread that this saving is not that significant in recent history as address reuse is no longer that frequent.
> >
> > A filter on spent outpoint is just as useful for wallets as is one on spent script, since they naturally scan the blockchain forward and thereby learn about their coins by the output script before they need to check spends of those outpoints.
> >
> > It seems to me that implementing an interrogation by evtl. downloading blocks at checkpoints is much simpler than following multiple possible filter paths.
> >
> > A spent outpoint filter allows us to decide on coin availability based on immutable store, without updated and eventually rolled back UTXO store. The availability could be decided by following the filter path to current tip to genesis and
> > check is the outpoint was spent earlier. False positives can be sorted out with a block download. Murmel implements this if running in server mode, where blocks are already there.
> >
> > Therefore I ask for a BIP change based on better insight gained through implementation.
> >
> > Tamas Blummer
> >
> >> On Feb 4, 2019, at 21:18, Jim Posen <jim.posen at gmail.com> wrote:
> >>
> >> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 regarding the decision to remove outpoints from the filter [1].
> >>
> >> Thanks for bringing this up though, because more discussion is needed on the client protocol given that clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner (due to the inclusion of input scripts).
> >>
> >> I see three possibilities:
> >> 1) Introduce a new P2P message to retrieve all prev-outputs for a given block (essentially the undo data in Core), and verify the scripts against the block by executing them. While this permits some forms of input script malleability (and thus cannot discriminate between all valid and invalid filters), it restricts what an attacker can do. This was proposed by Laolu AFAIK, and I believe this is how btcd is proceeding.
> >> 2) Clients track multiple possible filter header chains and essentially consider the union of their matches. So if any filter received for a particular block header matches, the client downloads the block. The client can ban a peer if they 1) ever return a filter omitting some data that is observed in the downloaded block, 2) repeatedly serve filters that trigger false positive block downloads where such a number of false positives is statistically unlikely, or 3) repeatedly serves filters that are significantly larger than the expected size (essentially padding the actual filters with garbage to waste bandwidth). I have not done the analysis yet, but we should be able to come up with some fairly simple banning heuristics using Chernoff bounds. The main downside is that the client logic to track multiple possible filter chains and filters per block is more complex and bandwidth increases if connected to a malicious server. I first heard about this idea from David Harding.
> >> 3) Rush straight to committing the filters into the chain (via witness reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 157 P2P mode.
> >>
> >> I'm in favor of option #2 despite the downsides since it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written. (Though the recommended client protocol in the BIP needs to be updated to account for this). Another benefit of it is that it removes some synchronicity assumptions where a peer with the correct filters keeps timing out and is assumed to be dishonest, while the dishonest peer is assumed to be OK because it is responsive.
> >>
> >> If anyone has other ideas, I'd love to hear them.
> >>
> >> -jimpo
> >>
> >> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
> >>
> >>
> >>
> >> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> TLDR: a change to BIP158 would allow decision on which filter chain is correct at lower bandwith use
> >>
> >> Assume there is a BIP157 client that learned a filter header chain earlier and is now offered an alternate reality by a newly connected BIP157 server.
> >>
> >> The client notices the alternate reality by routinely asking for filter chain checkpoints after connecting to a new BIP157 server. A divergence at a checkpoint means that the server disagrees the client's history at or before the first diverging checkpoint. The client would then request the filter headers between the last matching and first divergent checkpoint, and quickly figure which block’s filter is the first that does not match previous assumption, and request that filter from the server.
> >>
> >> The client downloads the corresponding block, checks that its header fits the PoW secured best header chain, re-calculates merkle root of its transaction list to know that it is complete and queries the filter to see if every output script of every transaction is contained in there, if not the server is lying, the case is closed, the server disconnected.
> >>
> >> Having all output scripts in the filter does not however guarantee that the filter is correct since it might omit input scripts. Inputs scripts are not part of the downloaded block, but are in some blocks before that. Checking those are out of reach for lightweight client with tools given by the current BIP.
> >>
> >> A remedy here would be an other filter chain on created and spent outpoints as is implemented currently by Murmel. The outpoint filter chain must offer a match for every spent output of the block with the divergent filter, otherwise the interrogated server is lying since a PoW secured block can not spend coins out of nowhere. Doing this check would already force the client to download the outpoint filter history up-to the point of divergence. Then the client would have to download and PoW check every block that shows a match in outpoints until it figures that one of the spent outputs has a script that was not in the server’s filter, in which case the server is lying. If everything checks out then the previous assumption on filter history was incorrect and should be replaced by the history offered by the interrogated server.
> >>
> >> As you see the interrogation works with this added filter but is highly ineffective. A really light client should not be forced to download lots of blocks just to uncover a lying filter server. This would actually be an easy DoS on light BIP157 clients.
> >>
> >> A better solution is a change to BIP158 such that the only filter contains created scripts and spent outpoints. It appears to me that this would serve well both wallets and interrogation of filter servers well:
> >>
> >> Wallets would recognize payments to their addresses by the filter as output scripts are included, spends from the wallet would be recognized as a wallet already knows outpoints of its previously received coins, so it can query the filters for them.
> >>
> >> Interrogation of a filter server also simplifies, since the filter of the block can be checked entirely against the contents of the same block. The decision on filter correctness does not require more bandwith then download of a block at the mismatching checkpoint. The client could only be forced at max. to download 1/1000 th of the blockchain in addition to the filter header history.
> >>
> >> Therefore I suggest to change BIP158 to have a base filter, defined as:
> >>
> >> A basic filter MUST contain exactly the following items for each transaction in a block:
> >> • Spent outpoints
> >> • The scriptPubKey of each output, aside from all OP_RETURN output scripts.
> >>
> >> Tamas Blummer
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

2023-06-07 18:16:22

- reply

📅 Original date posted:2019-02-05
📝 Original message:Hi Laolu,
The only advantage I see in the current design choice is filter size, but even that is less
impressive in recent history and going forward, as address re-use is much less frequent nowadays
than it was Bitcoin’s early days.
I calculated total filter sizes since block 500,000:
input script + output script (current BIP): 1.09 GB
spent outpoint + output script: 1.26 GB
Both filters are equally useful for a wallet to discover relevant transactions, but the current design
choice seriously limits, practically disables a light client, to prove that the filter is correct.
Clear advantages of moving to spent outpoint + output script filter:
1. Filter correctness can be proven by downloading the block in question only.
2. Calculation of the filter on server side does not need UTXO.
3. Spent outpoints in the filter enable light clients to do further probabilistic checks and even more if committed.
The current design choice offers lower security than now attainable. This certainly improves with
a commitment, but that is not even on the roadmap yet, or is it?
Should a filter be committed that contains spent outpoints, then such filter would be even more useful:
A client could decide on availability of spent coins of a transaction without maintaining the UTXO set, by
checking the filters if the coin was spent after its origin proven in an SPV manner, evtl. eliminating false positives
with a block download. This would be slower than having UTXO but require only immutable store, no unwinds and
only download of a few blocks.
Since Bitcoin Core is not yet serving any filters, I do not think this discussion is too late.
Tamas Blummer
> On Feb 5, 2019, at 02:42, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Tamas,
>
> This is how the filter worked before the switch over to optimize for a
> filter containing the minimal items needed for a regular wallet to function.
> When this was proposed, I had already implemented the entire proposal from
> wallet to full-node. At that point, we all more or less decided that the
> space savings (along with intra-block compression) were worthwhile, we
> weren't cutting off any anticipated application level use cases (at that
> point we had already comprehensively integrated both filters into lnd), and
> that once committed the security loss would disappear.
>
> I think it's too late into the current deployment of the BIPs to change
> things around yet again. Instead, the BIP already has measures in place for
> adding _new_ filter types in the future. This along with a few other filter
> types may be worthwhile additions as new filter types.
>
> -- Laolu
>
> On Mon, Feb 4, 2019 at 12:59 PM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> I participated in that discussion in 2018, but have not had the insight gathered by now though writing both client and server implementation of BIP157/158
>
> Pieter Wuille considered the design choice I am now suggesting here as alternative (a) in: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html
> In his evaluation he recognized that a filter having spent output and output scripts would allow decision on filter correctness by knowing the block only.
> He did not evaluate the usefulness in the context of checkpoints, which I think are an important shortcut here.
>
> Yes, a filter that is collecting input and output scripts is shorter if script re-use is frequent, but I showed back in 2018 in the same thread that this saving is not that significant in recent history as address reuse is no longer that frequent.
>
> A filter on spent outpoint is just as useful for wallets as is one on spent script, since they naturally scan the blockchain forward and thereby learn about their coins by the output script before they need to check spends of those outpoints.
>
> It seems to me that implementing an interrogation by evtl. downloading blocks at checkpoints is much simpler than following multiple possible filter paths.
>
> A spent outpoint filter allows us to decide on coin availability based on immutable store, without updated and eventually rolled back UTXO store. The availability could be decided by following the filter path to current tip to genesis and
> check is the outpoint was spent earlier. False positives can be sorted out with a block download. Murmel implements this if running in server mode, where blocks are already there.
>
> Therefore I ask for a BIP change based on better insight gained through implementation.
>
> Tamas Blummer
>
>> On Feb 4, 2019, at 21:18, Jim Posen <jim.posen at gmail.com> wrote:
>>
>> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 regarding the decision to remove outpoints from the filter [1].
>>
>> Thanks for bringing this up though, because more discussion is needed on the client protocol given that clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner (due to the inclusion of input scripts).
>>
>> I see three possibilities:
>> 1) Introduce a new P2P message to retrieve all prev-outputs for a given block (essentially the undo data in Core), and verify the scripts against the block by executing them. While this permits some forms of input script malleability (and thus cannot discriminate between all valid and invalid filters), it restricts what an attacker can do. This was proposed by Laolu AFAIK, and I believe this is how btcd is proceeding.
>> 2) Clients track multiple possible filter header chains and essentially consider the union of their matches. So if any filter received for a particular block header matches, the client downloads the block. The client can ban a peer if they 1) ever return a filter omitting some data that is observed in the downloaded block, 2) repeatedly serve filters that trigger false positive block downloads where such a number of false positives is statistically unlikely, or 3) repeatedly serves filters that are significantly larger than the expected size (essentially padding the actual filters with garbage to waste bandwidth). I have not done the analysis yet, but we should be able to come up with some fairly simple banning heuristics using Chernoff bounds. The main downside is that the client logic to track multiple possible filter chains and filters per block is more complex and bandwidth increases if connected to a malicious server. I first heard about this idea from David Harding.
>> 3) Rush straight to committing the filters into the chain (via witness reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 157 P2P mode.
>>
>> I'm in favor of option #2 despite the downsides since it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written. (Though the recommended client protocol in the BIP needs to be updated to account for this). Another benefit of it is that it removes some synchronicity assumptions where a peer with the correct filters keeps timing out and is assumed to be dishonest, while the dishonest peer is assumed to be OK because it is responsive.
>>
>> If anyone has other ideas, I'd love to hear them.
>>
>> -jimpo
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
>>
>>
>>
>> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> TLDR: a change to BIP158 would allow decision on which filter chain is correct at lower bandwith use
>>
>> Assume there is a BIP157 client that learned a filter header chain earlier and is now offered an alternate reality by a newly connected BIP157 server.
>>
>> The client notices the alternate reality by routinely asking for filter chain checkpoints after connecting to a new BIP157 server. A divergence at a checkpoint means that the server disagrees the client's history at or before the first diverging checkpoint. The client would then request the filter headers between the last matching and first divergent checkpoint, and quickly figure which block’s filter is the first that does not match previous assumption, and request that filter from the server.
>>
>> The client downloads the corresponding block, checks that its header fits the PoW secured best header chain, re-calculates merkle root of its transaction list to know that it is complete and queries the filter to see if every output script of every transaction is contained in there, if not the server is lying, the case is closed, the server disconnected.
>>
>> Having all output scripts in the filter does not however guarantee that the filter is correct since it might omit input scripts. Inputs scripts are not part of the downloaded block, but are in some blocks before that. Checking those are out of reach for lightweight client with tools given by the current BIP.
>>
>> A remedy here would be an other filter chain on created and spent outpoints as is implemented currently by Murmel. The outpoint filter chain must offer a match for every spent output of the block with the divergent filter, otherwise the interrogated server is lying since a PoW secured block can not spend coins out of nowhere. Doing this check would already force the client to download the outpoint filter history up-to the point of divergence. Then the client would have to download and PoW check every block that shows a match in outpoints until it figures that one of the spent outputs has a script that was not in the server’s filter, in which case the server is lying. If everything checks out then the previous assumption on filter history was incorrect and should be replaced by the history offered by the interrogated server.
>>
>> As you see the interrogation works with this added filter but is highly ineffective. A really light client should not be forced to download lots of blocks just to uncover a lying filter server. This would actually be an easy DoS on light BIP157 clients.
>>
>> A better solution is a change to BIP158 such that the only filter contains created scripts and spent outpoints. It appears to me that this would serve well both wallets and interrogation of filter servers well:
>>
>> Wallets would recognize payments to their addresses by the filter as output scripts are included, spends from the wallet would be recognized as a wallet already knows outpoints of its previously received coins, so it can query the filters for them.
>>
>> Interrogation of a filter server also simplifies, since the filter of the block can be checked entirely against the contents of the same block. The decision on filter correctness does not require more bandwith then download of a block at the mismatching checkpoint. The client could only be forced at max. to download 1/1000 th of the blockchain in addition to the filter header history.
>>
>> Therefore I suggest to change BIP158 to have a base filter, defined as:
>>
>> A basic filter MUST contain exactly the following items for each transaction in a block:
>> • Spent outpoints
>> • The scriptPubKey of each output, aside from all OP_RETURN output scripts.
>>
>> Tamas Blummer
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:16:21

- reply

📅 Original date posted:2019-02-04
📝 Original message:I participated in that discussion in 2018, but have not had the insight gathered by now though writing both client and server implementation of BIP157/158
Pieter Wuille considered the design choice I am now suggesting here as alternative (a) in: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html>
In his evaluation he recognized that a filter having spent output and output scripts would allow decision on filter correctness by knowing the block only.
He did not evaluate the usefulness in the context of checkpoints, which I think are an important shortcut here.
Yes, a filter that is collecting input and output scripts is shorter if script re-use is frequent, but I showed back in 2018 in the same thread that this saving is not that significant in recent history as address reuse is no longer that frequent.
A filter on spent outpoint is just as useful for wallets as is one on spent script, since they naturally scan the blockchain forward and thereby learn about their coins by the output script before they need to check spends of those outpoints.
It seems to me that implementing an interrogation by evtl. downloading blocks at checkpoints is much simpler than following multiple possible filter paths.
A spent outpoint filter allows us to decide on coin availability based on immutable store, without updated and eventually rolled back UTXO store. The availability could be decided by following the filter path to current tip to genesis and
check is the outpoint was spent earlier. False positives can be sorted out with a block download. Murmel implements this if running in server mode, where blocks are already there.
Therefore I ask for a BIP change based on better insight gained through implementation.
Tamas Blummer
> On Feb 4, 2019, at 21:18, Jim Posen <jim.posen at gmail.com> wrote:
>
> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 regarding the decision to remove outpoints from the filter [1].
>
> Thanks for bringing this up though, because more discussion is needed on the client protocol given that clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner (due to the inclusion of input scripts).
>
> I see three possibilities:
> 1) Introduce a new P2P message to retrieve all prev-outputs for a given block (essentially the undo data in Core), and verify the scripts against the block by executing them. While this permits some forms of input script malleability (and thus cannot discriminate between all valid and invalid filters), it restricts what an attacker can do. This was proposed by Laolu AFAIK, and I believe this is how btcd is proceeding.
> 2) Clients track multiple possible filter header chains and essentially consider the union of their matches. So if any filter received for a particular block header matches, the client downloads the block. The client can ban a peer if they 1) ever return a filter omitting some data that is observed in the downloaded block, 2) repeatedly serve filters that trigger false positive block downloads where such a number of false positives is statistically unlikely, or 3) repeatedly serves filters that are significantly larger than the expected size (essentially padding the actual filters with garbage to waste bandwidth). I have not done the analysis yet, but we should be able to come up with some fairly simple banning heuristics using Chernoff bounds. The main downside is that the client logic to track multiple possible filter chains and filters per block is more complex and bandwidth increases if connected to a malicious server. I first heard about this idea from David Harding.
> 3) Rush straight to committing the filters into the chain (via witness reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 157 P2P mode.
>
> I'm in favor of option #2 despite the downsides since it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written. (Though the recommended client protocol in the BIP needs to be updated to account for this). Another benefit of it is that it removes some synchronicity assumptions where a peer with the correct filters keeps timing out and is assumed to be dishonest, while the dishonest peer is assumed to be OK because it is responsive.
>
> If anyone has other ideas, I'd love to hear them.
>
> -jimpo
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html>
>
>
>
> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> TLDR: a change to BIP158 would allow decision on which filter chain is correct at lower bandwith use
>
> Assume there is a BIP157 client that learned a filter header chain earlier and is now offered an alternate reality by a newly connected BIP157 server.
>
> The client notices the alternate reality by routinely asking for filter chain checkpoints after connecting to a new BIP157 server. A divergence at a checkpoint means that the server disagrees the client's history at or before the first diverging checkpoint. The client would then request the filter headers between the last matching and first divergent checkpoint, and quickly figure which block’s filter is the first that does not match previous assumption, and request that filter from the server.
>
> The client downloads the corresponding block, checks that its header fits the PoW secured best header chain, re-calculates merkle root of its transaction list to know that it is complete and queries the filter to see if every output script of every transaction is contained in there, if not the server is lying, the case is closed, the server disconnected.
>
> Having all output scripts in the filter does not however guarantee that the filter is correct since it might omit input scripts. Inputs scripts are not part of the downloaded block, but are in some blocks before that. Checking those are out of reach for lightweight client with tools given by the current BIP.
>
> A remedy here would be an other filter chain on created and spent outpoints as is implemented currently by Murmel. The outpoint filter chain must offer a match for every spent output of the block with the divergent filter, otherwise the interrogated server is lying since a PoW secured block can not spend coins out of nowhere. Doing this check would already force the client to download the outpoint filter history up-to the point of divergence. Then the client would have to download and PoW check every block that shows a match in outpoints until it figures that one of the spent outputs has a script that was not in the server’s filter, in which case the server is lying. If everything checks out then the previous assumption on filter history was incorrect and should be replaced by the history offered by the interrogated server.
>
> As you see the interrogation works with this added filter but is highly ineffective. A really light client should not be forced to download lots of blocks just to uncover a lying filter server. This would actually be an easy DoS on light BIP157 clients.
>
> A better solution is a change to BIP158 such that the only filter contains created scripts and spent outpoints. It appears to me that this would serve well both wallets and interrogation of filter servers well:
>
> Wallets would recognize payments to their addresses by the filter as output scripts are included, spends from the wallet would be recognized as a wallet already knows outpoints of its previously received coins, so it can query the filters for them.
>
> Interrogation of a filter server also simplifies, since the filter of the block can be checked entirely against the contents of the same block. The decision on filter correctness does not require more bandwith then download of a block at the mismatching checkpoint. The client could only be forced at max. to download 1/1000 th of the blockchain in addition to the filter header history.
>
> Therefore I suggest to change BIP158 to have a base filter, defined as:
>
> A basic filter MUST contain exactly the following items for each transaction in a block:
> • Spent outpoints
> • The scriptPubKey of each output, aside from all OP_RETURN output scripts.
>
> Tamas Blummer
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/4d87cc77/attachment-0001.html>
-------------- 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/20190204/4d87cc77/attachment-0001.sig>

2023-06-07 18:16:20

- reply

📅 Original date posted:2019-02-04
📝 Original message:TLDR: a change to BIP158 would allow decision on which filter chain is correct at lower bandwith use
Assume there is a BIP157 client that learned a filter header chain earlier and is now offered an alternate reality by a newly connected BIP157 server.
The client notices the alternate reality by routinely asking for filter chain checkpoints after connecting to a new BIP157 server. A divergence at a checkpoint means that the server disagrees the client's history at or before the first diverging checkpoint. The client would then request the filter headers between the last matching and first divergent checkpoint, and quickly figure which block’s filter is the first that does not match previous assumption, and request that filter from the server.
The client downloads the corresponding block, checks that its header fits the PoW secured best header chain, re-calculates merkle root of its transaction list to know that it is complete and queries the filter to see if every output script of every transaction is contained in there, if not the server is lying, the case is closed, the server disconnected.
Having all output scripts in the filter does not however guarantee that the filter is correct since it might omit input scripts. Inputs scripts are not part of the downloaded block, but are in some blocks before that. Checking those are out of reach for lightweight client with tools given by the current BIP.
A remedy here would be an other filter chain on created and spent outpoints as is implemented currently by Murmel. The outpoint filter chain must offer a match for every spent output of the block with the divergent filter, otherwise the interrogated server is lying since a PoW secured block can not spend coins out of nowhere. Doing this check would already force the client to download the outpoint filter history up-to the point of divergence. Then the client would have to download and PoW check every block that shows a match in outpoints until it figures that one of the spent outputs has a script that was not in the server’s filter, in which case the server is lying. If everything checks out then the previous assumption on filter history was incorrect and should be replaced by the history offered by the interrogated server.
As you see the interrogation works with this added filter but is highly ineffective. A really light client should not be forced to download lots of blocks just to uncover a lying filter server. This would actually be an easy DoS on light BIP157 clients.
A better solution is a change to BIP158 such that the only filter contains created scripts and spent outpoints. It appears to me that this would serve well both wallets and interrogation of filter servers well:
Wallets would recognize payments to their addresses by the filter as output scripts are included, spends from the wallet would be recognized as a wallet already knows outpoints of its previously received coins, so it can query the filters for them.
Interrogation of a filter server also simplifies, since the filter of the block can be checked entirely against the contents of the same block. The decision on filter correctness does not require more bandwith then download of a block at the mismatching checkpoint. The client could only be forced at max. to download 1/1000 th of the blockchain in addition to the filter header history.
Therefore I suggest to change BIP158 to have a base filter, defined as:
A basic filter MUST contain exactly the following items for each transaction in a block:
• Spent outpoints
• The scriptPubKey of each output, aside from all OP_RETURN output scripts.
Tamas Blummer

2023-06-07 18:16:19

- reply

📅 Original date posted:2019-02-03
📝 Original message:TLDR: I suggest to add outpoint filter to BIP158 as it proved to be useful while developing a filter server and allows further checks in filter client.
Murmel is my project within the rust-bitcoin community. https://github.com/rust-bitcoin/murmel
Its goal is to provide a lightweight, at least SPV security, settlement layer for the Lightning Network implementation in Rust. https://github.com/rust-bitcoin/rust-lightning
Murmel relies on BIP157 (Client Side Block Filtering). Since Bitcoin Core does not yet support this protocol extension, I also added filter and block server functionality to Murmel and this might be useful for
development purposes any other BIP157 client project.
You may compile and run a Murmel filter server to support your client development. It bootstraps within a few hours. Follow the instructions at: https://github.com/rust-bitcoin/murmel
While implementing both client and server side I made an observation that should be considered for BIP158:
BIP158 specifies base filter containing all scripts spent or created by a block (except those with OP_RETURN). I found it useful to also compute a filter on spent and created outpoints.
The Murmel filter server consults these outpoint filters to find the transactions with the spent scripts while computing the base script filter. Since outpoints usually getting spent shortly after created, this approach works well enough to
keep up with the blockchain, although far too slow to rely on it while bootstrapping. An advantage of this approach of looking up UTXO is that there is nothing to be recomputed at re-org, filters are consulted following
the path from current tip back to genesis. This fits well with Murmel’s storage, that is my other project Hammersbald https://github.com/rust-bitcoin/hammersbald, a highly efficient truly append only blockchain store in Rust.
Filter matching is also nicely parallelizable looking up subsets of spent outputs in parallel.
A lightweight client can use outpoint filters to efficiently validate spent coins or miner reward, which goes beyond SPV guarantees. This is probabilistically possible now, and definitely once filters are committed.
For above reasons I suggest to also add outpoint filter to BIP158, so filter servers may support it, as does Murmel. Murmel is moving quickly; I tagged the version as of this mail with DEVLIST for later reference.
Tamas Blummer

2023-06-07 18:12:43

- reply

📅 Original date posted:2018-06-03
📝 Original message:Correction:
- Output script + spent script filters (Wuille’s (b)) have sizes of ca. 2% of block size.
Tamas Blummer
> On Jun 3, 2018, at 18:44, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> I processed bitcoin history assuming filters using with P=19 M=784931.
>
> Findings:
> - Output script + spent script filters (Wuille’s (b)) have sizes of ca. 0.2% of block size.
> - Output script + spent script filters (Wuille’s (b)) are ca. 10% smaller than output script + spent outpoint filters (Wuille's (a)). Savings here however trend lower since years.
>
> Graphs attached.
>
> Tamas Blummer
>
> <scriptfilter.png><scriptssaving.png>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/99540bb3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/99540bb3/attachment-0001.sig>

2023-06-07 18:12:39

- reply

📅 Original date posted:2018-06-03
📝 Original message:Lighter but SPV secure nodes (filter committed) would help the network (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.
On longer term most users' security will be determined by either trusted hubs or POW.
I do not know which is worse, but we should at least offer the choice to the user, therefore commit filters.
Tamas Blummer
> On Jun 3, 2018, at 02:28, Gregory Maxwell <greg at xiph.org> wrote:
>
> pretty much us that all these filter things are a total waste of time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/0f5d908f/attachment.sig>

2023-06-07 18:12:39

- reply

📅 Original date posted:2018-06-03
📝 Original message:I processed bitcoin history assuming filters using with P=19 M=784931.
Findings:
- Output script + spent script filters (Wuille’s (b)) have sizes of ca. 0.2% of block size.
- Output script + spent script filters (Wuille’s (b)) are ca. 10% smaller than output script + spent outpoint filters (Wuille's (a)). Savings here however trend lower since years.
Graphs attached.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptfilter.png
Type: image/png
Size: 55464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptssaving.png
Type: image/png
Size: 59097 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0001.sig>

2023-06-07 18:12:38

- reply

📅 Original date posted:2018-06-02
📝 Original message:Without block commitment mobiles would have to use trusted filter provider or implement a complex data hungry algorithm and still remain as insecure as with BIP 37.
Years of experience implementing wallets with BIP 37 taught us that an outpoint + output script filter is useful. Committing such a filter to the block can not be an error.
We could roll this out on P2P prior to a soft fork adding the commitment, but I would not expect its use to pick up before that.
Therafter BIP 37 could be rightfully decommissioned, herby offering both security and privacy enhancement at modest data cost.
Tamas Blummer
> On Jun 2, 2018, at 14:41, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:
>> Without the ability to verify filter validity, a client would have to stop
>> syncing altogether in the presence of just one malicious peer, which is
>> unacceptable.
>
> I'm confused about why this would be the case. If Alice's node
> generates filters accurately and Mallory's node generates filters
> inaccurately, and they both send their filters to Bob, won't Bob be able
> to download any blocks either filter indicates are relevant to his
> wallet?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/6623601b/attachment.sig>

2023-06-07 18:12:18

- reply

📅 Original date posted:2018-05-31
📝 Original message:I processed the historic blockchain to create a single filter populated with spent input scripts and output scripts. The Golomb parameter was P=2^20
The resulting chart shows a volatile history of same-block address re-use with a notable drops in relative filter size during the early history and in the time window where SatoshiDICE was popular, since then trending higher.
The history of only the last half year suggests a current filter size of between 2.0% - 2.5% of block sizes.
Since most outputs are spent within a short time period, but apparently not that often in same blocks, I think it was worth considering filter series that match over a windows of 2^n blocks (n=(0…10)). Applications could then bracket the
range of interest and then narrow down requesting finer filters or blocks.
Then I created 1600 random (P2SH) scripts and totaled the false positive block download data size if observing 100, 200, 400, 800, 1600 of them.
The result suggests that even for 1600 the false positive overhead is less than 0.1% of blockchain data size.
I agree with Greg that we should optimize the parameters for a small observed set as those will be running on mobile devices.
As of Pieter’s findings the simulation parameters were optimal for ca. 1000 observed scripts which is maybe to many for a “small” application.
On the other hand we do not know the needs of future popular mobile applications.
With parameters of the simulation the current minimal data burden on a mobile wallet would be ca. 0.1 GB / Month.
Simulations with other parameters could be executed using this patch branch: https://github.com/tamasblummer/rust-bitcoin-spv/tree/blockfilterstats A run takes a few hours on a fast machine with release build and local bitcoind.
The calculation can not be reduced to the recent history as the process builds in-memory utxo from genesis.
The result of executing the binary is a CSV file containing:
blocknumber, blocksize, utxo size, filter size, false positive data size for 100, false positive data size for 100, … false positive data size for 100
e.g:
524994,1112181,57166825,21556,0,0,0,0,1112181
Tamas Blummer
> On May 29, 2018, at 06:01, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > The additional benefit of the input script/outpoint filter is to watch for
> > unexpected spends (coins getting stolen or spent from another wallet) or
> > transactions without a unique change or output address. I think this is a
> > reasonable implementation, and it would be nice to be able to download that
> > filter without any input elements.
>
> As someone who's implemented a complete integration of the filtering
> technique into an existing wallet, and a higher application I disagree.
> There's not much gain to be had in splitting up the filters: it'll result in
> additional round trips (to fetch these distinct filter) during normal
> operation, complicate routine seed rescanning logic, and also is detrimental
> to privacy if one is fetching blocks from the same peer as they've
> downloaded the filters from.
>
> However, I'm now convinced that the savings had by including the prev output
> script (addr re-use and outputs spent in the same block as they're created)
> outweigh the additional booking keeping required in an implementation (when
> extracting the precise tx that matched) compared to using regular outpoint
> as we do currently. Combined with the recently proposed re-parametrization
> of the gcs parameters[1], the filter size should shrink by quite a bit!
>
> I'm very happy with the review the BIPs has been receiving as of late. It
> would've been nice to have this 1+ year ago when the draft was initially
> proposed, but better late that never!
>
> Based on this thread, [1], and discussions on various IRC channels, I plan
> to make the following modifications to the BIP:
>
> 1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the
> filter instance, so future filter types may use distinct parameters
> 2. use the prev output script rather than the prev input script in the
> regular filter
> 3. remove the txid from the regular filter(as with some extra book-keeping
> the output script is enough)
> 4. do away with the extended filter all together, as our original use case
> for it has been nerfed as the filter size grew too large when doing
> recursive parsing. instead we watch for the outpoint being spent and
> extract the pre-image from it if it matches now
>
> The resulting changes should slash the size of the filters, yet still ensure
> that they're useful enough for our target use case.
>
> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html
>
> -- Laolu
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filtersize.png
Type: image/png
Size: 58848 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lasthalfyear.png
Type: image/png
Size: 50431 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: falsepositive.png
Type: image/png
Size: 82663 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0005.png>

2023-06-07 18:12:17

- reply

📅 Original date posted:2018-05-28
📝 Original message:Forgot to mention: The link I sent is to a branch that is patched to produce the filter stats.
This is the main project and the BIP158 implementation: https://github.com/rust-bitcoin/rust-bitcoin-spv/blob/master/src/blockfilter.rs
Tamas Blummer
> On May 28, 2018, at 20:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hi Jim,
>
> A “basic” combined filter would mean up to 0.5 GB filter data per month (with 100% segwith use). Considering that 1 GB is the usual data quota for an entry level mobile phone contract, this could be a too high barrier for adoption.
>
> I repeated your calculations and produced a slightly different graph that shows the fraction of cummulative filter size to cummulative blockchain size. This is less noisy but otherwise confirms your measurement.
>
> I think that the data supports separation of filters as a combined filter does not seem to come with significant savings. (basic size ~= txid + input points + output scripts sizes)
>
> My calculations are repeatable with:
>
> https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs
>
> that is using a Rust implementation of an SPV client built on top of other libraries we work on in the rust-bitcoin GitHub community (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the project hoping to attract more developer.
>
> Tamas Blummer
>
>
> <filters.png>
>
>> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Greg, I've attached a graph including the input scripts.
>>
>> In the top graph, we can see how the input script filter compares to the input outpoint filter. It is definitely smaller as a result of address reuse. The bottom graph shows the ratio over time of combining the input prev script and output script filters vs keeping them separate. In more recent blocks, it appears that there are decreasing savings.
>>
>

2023-06-07 18:12:16

- reply

📅 Original date posted:2018-05-28
📝 Original message:Hi Jim,
A “basic” combined filter would mean up to 0.5 GB filter data per month (with 100% segwith use). Considering that 1 GB is the usual data quota for an entry level mobile phone contract, this could be a too high barrier for adoption.
I repeated your calculations and produced a slightly different graph that shows the fraction of cummulative filter size to cummulative blockchain size. This is less noisy but otherwise confirms your measurement.
I think that the data supports separation of filters as a combined filter does not seem to come with significant savings. (basic size ~= txid + input points + output scripts sizes)
My calculations are repeatable with:
https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs
that is using a Rust implementation of an SPV client built on top of other libraries we work on in the rust-bitcoin GitHub community (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the project hoping to attract more developer.
Tamas Blummer
> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Greg, I've attached a graph including the input scripts.
>
> In the top graph, we can see how the input script filter compares to the input outpoint filter. It is definitely smaller as a result of address reuse. The bottom graph shows the ratio over time of combining the input prev script and output script filters vs keeping them separate. In more recent blocks, it appears that there are decreasing savings.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/98939f0d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filters.png
Type: image/png
Size: 69944 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/98939f0d/attachment-0001.png>

2023-06-07 18:08:45

- reply

📅 Original date posted:2017-12-24
📝 Original message:I see further arguments supporting the “bit" denomination:
huge benefit:
- amounts denominated in bits fit nicely into legacy database structures and UIs with two decimal places for currency. This change to the usual currrency precision is a huge benefit for integration into existing financial software.
nice to have:
- while fraction prefixes m for 1/1000 and u for 1/1000000 are obvious to engineers and geeks, they are a foreign concept to many. Chances confusing magnitudes would be high if alternative scales were offered.
- bit assigns an easy to comprehend meaning to the second part of the Bitcoin name: I think the term “(a whole) coin" would quickly catch on as a synonym for a million bits.
Tamas Blummer

2023-06-07 17:46:09

- reply

📅 Original date posted:2015-12-10
📝 Original message:Note that the unused space in coin base input script allows us to soft-fork an additional SW Merkle tree root into the design,
therefore please make sure the new SW data structure also has a new slot for future extension.
Tamas Blummer

2023-06-07 17:45:04

- reply

📅 Original date posted:2015-11-17
📝 Original message:Hi Eric,
Would you please enumerate, or point to, arguments that discourage the use of a key both for signing and for derivation of a deeper level of the hierarchy ?
Tamas Blummer
> On Nov 17, 2015, at 12:40, Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've submitted a BIP proposal that solves the issue of needing to predefine HD wallet structures and not being able to arbitrarily nest deeper levels. Comments appreciated.
>
> https://github.com/bitcoin/bips/pull/242
>
>
> - Eric
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:44:55

- reply

📅 Original date posted:2015-11-17
📝 Original message:Isolating storage from the rest of consensus code is technically desirable, but implementations using different storage will be unlikely bug-for-bug compatible,
hence able to split the network.
Such split was disastrous on the network level if partitions were of comparable magnitude - as was the case in the March 2013 fork between versions of Bitcoin Core.
This means high level implementation diversity was great, provided we would get there without blowing up the network on the way from monoculture to true decentralization of code.
Libconsensus is immensely valuable to get diversity, as it makes alternate implementations bug-for-bug compatible for a big part of the consensus code.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151117/fc390dd3/attachment.sig>

2023-06-07 17:37:21

- reply

📅 Original date posted:2015-08-23
📝 Original message:I see the huge amount of sweat and love that went into core and it actually hurts to see that most is expended in friction and lack of a vision for the software architecture.
To be concrete, this was my plan if dealing with the Core code base:
1) I'd consider the separation of networking and storage as suggested for a future extended libconsensus low priority, as their design should be (are) dominated by the need of the consensus logic only.
2) create an API to the consensus+networking+storage service that is not at the C++ language level but some scaleable cross-platform remoting, like eg. ZeroMQ.
This API should be minimal and simple, assuming that one fully trusts the node answering it. This API would unlock user land development by distinct teams with diverse technologies.
3) move the wallet, QT and RPC and other backward compatibility stuff (if e.g. there is some mining support) in-top of the new API and into distinct source code repositories.
Tamas Blummer
> On Aug 23, 2015, at 03:23, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I've been pushing for greater modularization since I first got into bitcoin. I got quickly frustrated when I was only able to get through very few things (i.e. moving core structure serialization classes to a separate unit not called main). Working on Bitcoin has an added layer of frustration that goes beyond most open source projects: even though we're clearly in userland working at the application layer, a good layered protocol design is still lacking. We have no standards process separate from what basically amount to updates to one specific reference implementation. And we all need to agree on any major change, since a blockchain that is easily forked in contentious ways pretty much defeats its own purpose.
>
> I went off to develop my own stack, where I could more easily avoid politics and focus on engineering. But I now understand the politics are inevitable. Bitcoin is inherently a cooperative project. Several people have poured themselves passionately into the reference codebase, most of whom did it (at least initially) purely as unpaid volunteers. There's a lot of love that's gone into this. But it's become pretty clear that the modularization is no longer merely a matter of good engineering - it is essential to resolving serious political challenges.
>
> Perhaps the most frustrating thing of all is watching people pushing for relatively superficial yet highly controversial changes while we still lack the proper infrastructure to handle these kinds of divergences of opinion without either stagnating or becoming polarized.
>
> I could continue working to reimplement an entire stack from scratch, as several others have also done - but besides the serious effort duplication this entails, it doesn't really seem like it will ultimately be a convergent process. It's too easy to let ego and habit dictate one's preferences rather than rational engineering considerations.
>
> I know that some might feel I'm just preaching to the choir, but we should probably take a step back from implementation hackery and try to specify some core protocol layers, focusing on interfaces. Specifically, we need a consensus layer that doesn't try to specify networking, storage, wallets, UI, etc. Let different people improve upon these things independently in their own implementations. What matters is that we all converge on a common history and state. At the same time, let's open up more competition on all these other things that are separate from the consensus layer.
>
> If only we were to dedicate a fraction of the effort we've put into this whole block size circus into what's actually important...and I blame myself as well...
>
>
> On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> On Aug 21, 2015, at 21:46, Jorge Timón <jtimon at jtimon.cc <mailto:jtimon at jtimon.cc>> wrote:
>>
>> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com <mailto:tamas at bitsofproof.com>> wrote:
>>> Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
>>> but also open the chance of doing the work better, in the sense of software engineering.
>>
>> But you don't want something better, you want something functionally identical.
>> You may want to watch sipa's explanation on why "the implementation is
>> the specification" and the reasons to separate libconsensus:
>> https://youtu.be/l3O4nh79CUU?t=764 <https://youtu.be/l3O4nh79CUU?t=764>
>
> I do want something better, but not for the focus you have.
>
> Not because what you produce was not high quality, but because quality is achieved at a very
> high cost and is hard to uphold over generations of developer. You focus on a single use case
> while there are many out there for distributed ledgers.
>
> I think in an infrastructure for enterprise applications, building consensus on the ledger is a
> cornerstone there, but is only a piece of the solution. I built several commercially successful
> deployments where I delegated the consensus building to a border router, a Bitcoin Core,
> then interfaced that trusted peer with my implementation that accepted Core’s decisions
> in an SPV manner. One might think of this setup as wasteful and unsuitable for “small devices”
> therefore an example of centralization people here try to avoid.
>
> Enterprises have sufficient resources. Solving the business problem is valuable to them even at
> magnitudes higher cost than a hobbyist would bear.
>
> For mainstream adoption you need to get enterprises on board too, and that is what I care of.
> Enterprises want code that is not only high quality, but is easy to maintain with a development
> team with high attrition. One has to take whatever help is offered for that, and one is modern
> languages and runtimes.
>
> Bits of Proof’s own implementation of the scripts was not practically relevant in my commercially
> successful deployments, because of the use of a border router, but it helped development,
> enabling easier debug and precise error feedback esp. end even after Core had a reject message.
>
> I integrated libconsensus only for the hope that is significantly fastens application side tx verification,
> which it has turned out it does not, until secp265k1 is integrated.
>
> I would likely use an other extended libconsensus too, but do not think there was a dependency on
> that for enterprise development.
>
> It would help there more to have a slim protocol server, no wallet, no rpc, no qt but a high
> performance remoting API.
>
>> Since you already depend on libconsensus for VerifyScript, wouldn't it
>> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
>> You would still have complete control over storage, concurrency,
>> networking, policy...
>> My plan is for the C API to interface with the external storage by
>> passing a function pointer to it.
>
>
> Storage and validation is non-trivially interconnected, but I now the separation can be done,
> since I did it.
>
> Excuse me, but function pointers is a pattern I used in the 80’s. I know that they are behind
> the curtain of modern abstractions with similar use, I still prefer not to see them again.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150823/9129de9d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150823/9129de9d/attachment-0001.sig>

2023-06-07 17:37:20

- reply

📅 Original date posted:2015-08-22
📝 Original message:> On Aug 21, 2015, at 21:46, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com <mailto:tamas at bitsofproof.com>> wrote:
>> Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
>> but also open the chance of doing the work better, in the sense of software engineering.
>
> But you don't want something better, you want something functionally identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764 <https://youtu.be/l3O4nh79CUU?t=764>
I do want something better, but not for the focus you have.
Not because what you produce was not high quality, but because quality is achieved at a very
high cost and is hard to uphold over generations of developer. You focus on a single use case
while there are many out there for distributed ledgers.
I think in an infrastructure for enterprise applications, building consensus on the ledger is a
cornerstone there, but is only a piece of the solution. I built several commercially successful
deployments where I delegated the consensus building to a border router, a Bitcoin Core,
then interfaced that trusted peer with my implementation that accepted Core’s decisions
in an SPV manner. One might think of this setup as wasteful and unsuitable for “small devices”
therefore an example of centralization people here try to avoid.
Enterprises have sufficient resources. Solving the business problem is valuable to them even at
magnitudes higher cost than a hobbyist would bear.
For mainstream adoption you need to get enterprises on board too, and that is what I care of.
Enterprises want code that is not only high quality, but is easy to maintain with a development
team with high attrition. One has to take whatever help is offered for that, and one is modern
languages and runtimes.
Bits of Proof’s own implementation of the scripts was not practically relevant in my commercially
successful deployments, because of the use of a border router, but it helped development,
enabling easier debug and precise error feedback esp. end even after Core had a reject message.
I integrated libconsensus only for the hope that is significantly fastens application side tx verification,
which it has turned out it does not, until secp265k1 is integrated.
I would likely use an other extended libconsensus too, but do not think there was a dependency on
that for enterprise development.
It would help there more to have a slim protocol server, no wallet, no rpc, no qt but a high
performance remoting API.
> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.
Storage and validation is non-trivially interconnected, but I now the separation can be done,
since I did it.
Excuse me, but function pointers is a pattern I used in the 80’s. I know that they are behind
the curtain of modern abstractions with similar use, I still prefer not to see them again.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c501d201/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c501d201/attachment-0001.sig>

2023-06-07 17:37:18

- reply

📅 Original date posted:2015-08-21
📝 Original message:Thinking in Bitcoins only on the level of technology unnecessarily narrows your view.
OK, I hope to be pleasantly surprised.
Tamas Blummer
> On Aug 20, 2015, at 23:35, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
>
>
> On 08/20/15 21:26, Tamas Blummer wrote:
>> I know what you mean as I already have such a component with pluggable
>> block store and networking.
>
> I'm not suggesting pluggable networking, I'm suggesting (and I think
> everyone thinks the design should be) NO networking. The API is
> ValidationResult libconsensus.HeyIFoundABlock(Block) and
> ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
>
>> While you are at it you could aim for isolation of bitcoin specific
>> decisions and algos from generic block chain code.
>
> Are you suggesting to support altcoins? I dont think anyone cares about
> supporting that.
>
>> The magnitude of refactoring you would have to do to get there from
>> main.cpp and the rest of the hairball
>> is harder than a re-write from scratch,
>
> I think you'd be very pleasantly surprised. It sounds like you havent
> dug into Bitcoin Core validation code in years.
>
>> and the result will not be
>> impressive, just hopefully working.
>
> Hmm? The result would be an obviously correct consensus implementation
> that everyone could use, instead of everyone going off and writing their
> own and either being wrong, or never updating in the case of forks. Its
> a huge deal to allow people to focus on making their libraries have good
> APIs/Wallets/etc instead of focusing on making a working validation
> engine (though maybe for that the p2p layer needs to also be in a library).
>
>> I think a slim API server was a lower hanging fruit in Core’s case.
>
> We have one, it just needs a few already obvious performance improvements.
>
>> BTW, support for refactoring is an example where you see if your tool
>> set is modern.
>
> There are a number of good development tools for C++ that allow this....
>
>> Tamas Blummer
>>
>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> I dont think a libconsensus would have any kind of networking layer, nor
>>> is C++ an antique tool set (hopefully libconsensus can avoid a boost
>>> dependency, though thats not antique either). Ideally it would have a
>>> simple API to give it blocks and a simple API for it to inform you of
>>> what the current chain is. If you really want to get fancy maybe it has
>>> pluggable block storage, too, but I dont see why you couldnt use this in
>>> ~any client?
>>>
>>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
>>>> Every re-implementation, re-factoring even copy-paste introduces a
>>>> risk of disagreement,
>>>> but also open the chance of doing the work better, in the sense of
>>>> software engineering.
>>>>
>>>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc
>>>>> <mailto:jtimon at jtimon.cc>> wrote:
>>>>>
>>>>>
>>>>> But the goal is not reimplementing the consensus rules but rather
>>>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>>>> them again.
>>>>
>>>>
>>>>
>>>> My goal is different. Compatibility with Bitcoin is important as I
>>>> also want to deal with Bitcoins,
>>>> but it is also imperative to be able to create and serve other block
>>>> chains with other rules and for those
>>>> I do not want to carry on the legacy of an antique tool set and a
>>>> spaghetti style.
>>>>
>>>> Bits of Proof uses scala (akka networking), java (api service), c++
>>>> (leveledb and now libconsensus)
>>>> and I am eager to integrate secp256k1 (c) as soon as part of
>>>> consensus. The choices were
>>>> made because each piece appears best in what they do.
>>>>
>>>> Tamas Blummer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/9b8a4eb3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/9b8a4eb3/attachment.sig>

2023-06-07 17:37:18

- reply

📅 Original date posted:2015-08-20
📝 Original message:I know what you mean as I already have such a component with pluggable block store and networking.
While you are at it you could aim for isolation of bitcoin specific decisions and algos from generic block chain code.
The magnitude of refactoring you would have to do to get there from main.cpp and the rest of the hairball
is harder than a re-write from scratch, and the result will not be impressive, just hopefully working.
I think a slim API server was a lower hanging fruit in Core’s case.
BTW, support for refactoring is an example where you see if your tool set is modern.
Tamas Blummer
> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I dont think a libconsensus would have any kind of networking layer, nor
> is C++ an antique tool set (hopefully libconsensus can avoid a boost
> dependency, though thats not antique either). Ideally it would have a
> simple API to give it blocks and a simple API for it to inform you of
> what the current chain is. If you really want to get fancy maybe it has
> pluggable block storage, too, but I dont see why you couldnt use this in
> ~any client?
>
> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
>> Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
>> but also open the chance of doing the work better, in the sense of software engineering.
>>
>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
>>>
>>>
>>> But the goal is not reimplementing the consensus rules but rather
>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>> them again.
>>
>>
>>
>> My goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,
>> but it is also imperative to be able to create and serve other block chains with other rules and for those
>> I do not want to carry on the legacy of an antique tool set and a spaghetti style.
>>
>> Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)
>> and I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were
>> made because each piece appears best in what they do.
>>
>> Tamas Blummer
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.sig>

2023-06-07 17:37:17

- reply

📅 Original date posted:2015-08-20
📝 Original message:Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
but also open the chance of doing the work better, in the sense of software engineering.
> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> But the goal is not reimplementing the consensus rules but rather
> extract them from Bitcoin Core so that nobody needs to re-implement
> them again.
My goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,
but it is also imperative to be able to create and serve other block chains with other rules and for those
I do not want to carry on the legacy of an antique tool set and a spaghetti style.
Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)
and I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were
made because each piece appears best in what they do.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/ea9ba04d/attachment.sig>

2023-06-07 17:37:16

- reply

📅 Original date posted:2015-08-20
📝 Original message:Jorge,
separating script engine into libconsensus was very helpful, since wrapped the piece of consensus
that would least likely to be captured exactly with an implementation from scratch. Thank you for your
effort there. Bits of Proof now uses its own or alternatively libconsensus for full validation.
I am sceptical however that a “full” consensus lib extracted from satoshi’s code is worth trying.
Not because it was impossible, but because the result would not be higher quality, if measured on agreement
with satoshi, than other re-implementations. It would actually be lower quality because of the antique tool set.
The rules outside script engine are simpler, therefore much easier to capture exactly. They are however
scattered around in the spaghetti and are often just a single if statement, also repeated elsewhere.
You would either have to very extensively refactor the code, that unlikely goes through as a PR, or
do what me and others did. Read satoshi code and rewrite the same. You have
a slight advantage of copy-paste small fragments, but I doubt the consensus relevant advantage of that.
Tamas Blummer
> On Aug 20, 2015, at 02:53, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> 1) Finish the libconsensus separation in an independent branch on top
> of a given version, for example 0.11.
> 2) Separate a repository from that. Alternative implementations can
> start using a full libconsensus
> 3) Rebase that branch on top of bitcoin/master and start to PR small
> groups of commits. Once the whole branch has been merged, Bitcoin Core
> can replace the consensus folder with the libconsensus subtree, so
> that Bitcoin Core itself can start using a full libconsensus.
>
> Ironically with this plan Bitcoin Core may not be the full node first
> implementation to use a full libconsensus.
> There will be some consensus fork bug risks during 3 (which at the
> current speed I estimate it could easily take 3 or 4 years) and there
> would be some redundant work (replicating every consensus change in
> both Bitcoin Core and libconsensus).
> On the bright side, we may be able to have a full libconsensus this
> year (which was my goal after we exposed VerifyScript in the first
> libconsensus).
>
> Thoughts?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/fc405c9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/fc405c9e/attachment-0001.sig>

2023-06-07 17:37:10

- reply

📅 Original date posted:2015-08-21
📝 Original message:Jameson,
I like your thinking about the implicit reward of full nodes. It was not perceived as sufficient by many, hence full node counts were falling.
This might reverse now as the implicit value of validating yourself however becomes higher in a heterogenous environment, that is if there are hard forks in the wild.
Actually pooled mining became an option through the homogenous nature of the network.
Tamas Blummer
> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> The incentives for running a node may not be obvious to the average user, but they are there. Rather than direct monetary incentives, they are indirect. For one, it allows you to have a local copy of the blockchain that you validated yourself - trustlessness is the entire point of this system. Having local self-validated blockchain data is also essential for any enterprise that needs to quickly access large volumes of it. The other incentive is it supports the network. Users may feel that this is necessary out of altruism or they may feel incentivized to protect their investments in Bitcoin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/c05d53fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/c05d53fc/attachment.sig>

2023-06-07 17:35:35

- reply

📅 Original date posted:2015-08-20
📝 Original message:POW is by design the voting mechanism for the valid chain continuation.
Many rightfully dislike that the same voting mechanism is used on the validity rules, since ideally
validators (non-mining full nodes), SPV user and even those having an investment in their cold wallet
would all have a vote.
That ideal voting mechanism is not yet in the protocol.
Before XT we used discussions and an informal consensus of those with commit access to github to evolve Bitcoin.
The decision, not the discussion, is now suggested to be replaced with POW vote with XT.
It is not hard to see problems with both approaches.
If XT comes closer to miner majority, validators will also be forced to take side, so they will be able to express
their vote. I think that most Bitcoin entrepreneurs will pick XT if Core has no comparable offer
to scale transactions per second.
XT, Not-XT and a Core with some not-BIP101 offer will potentially set the stage for the perfect hard fork storm.
I still believe, that the idea of Bitcoin is powerful enough to weather that storm.
Tamas Blummer
> On Aug 20, 2015, at 14:29, Milly Bitcoin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Security is provided via POW.
>
> POW is only one aspect of security and that algorithm was created by developers and adopted by miners. Developers provide security by creating an algorithm and miners provide security by adopting it. If the developers and miners decided to do something insecure then Bitcoin will be insecure. POW is not some outside force.
>
> The security of Bitcoin as a system is a very complex subject that involve a number of factors that are the result of actions by humans.
>
> Russ
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/f662b0ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/f662b0ec/attachment.sig>

2023-06-07 17:35:26

- reply

📅 Original date posted:2015-08-16
📝 Original message:Hi Adam,
I welcomed XT for its declared focus on usability with current means.
I think there is also more room for non-consenus relevant P2P protocol flavors than a single code base can accommodate.
XT is also as Jeff just tweeted a relief valve.
It became important, that Bitcoin is able to evolve even if there are conflicting educated opinions.
If a review process serves decision making, then I’d be glad to participate.
Tamas Blummer
> On Aug 16, 2015, at 19:01, Adam Back <adam at cypherspace.org> wrote:
>
> Hi Tamas
>
> Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
> deserving of equal consideration? Just curious because of your post.
>
> Will you be interested to participate in the BIP review process and
> perhaps attend the workshop on Bitcoin scaling announced here
> recently?
>
> Adam
>
> On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
>> BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
>> I applaud Mike and Gavin for creating that choice for us.
>>
>> Tamas Blummer
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/946692ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/946692ad/attachment.sig>

2023-06-07 17:35:25

- reply

📅 Original date posted:2015-08-16
📝 Original message:Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/ffcc5a91/attachment.sig>

2023-06-07 17:35:07

- reply

📅 Original date posted:2015-08-18
📝 Original message:Thanks a lot Cory for following through the test case and producing a patch.
I confirm that libconsensus is now running stable within the Bits of Proof stack,
in-line with test cases we use to verify the java implementation of the script engine,
that are BTW borrowed from Bitcoin Core.
The performance of libconsensus is surprisingly close to the java one.
Validating a 2-of-2 a multi-sig transaction runs at 1021 ops/sec with java and 1135 ops/sec
in libconsensus. This is on a 2.2GH i7 laptop (4 hyper threading cores used by 8 threads).
Another nice demonstration why one should not trade in advances
of languages for the last decades for a marginal gain of performance with C/C++,
I assume thereby that Bouncy Castle’ EC lib s not superior to OpenSSL's.
I disagree that the problem was rare in the real-world, it should affect any modern
implementation that validates transactions parallel in multiple threads.
Aborting also does not make the problem less severe in my opinion.
Therefore hope the pull will be included into Core with next release.
I can’t assign a timeline to “near future" secp256k1 integration. Can you?
Tamas Blummer
> On Aug 18, 2015, at 07:03, Cory Fields <lists at coryfields.com> wrote:
>
> Back to the list (from github) in case anyone finds this via Google.
>
> The patch that I posted here a few days ago did not fix the issue for Tamas.
>
> I spent some time tracking down this edge-case because
> libbitcoinconsensus needs to be as bullet-proof as possible. Thanks to
> Tamas for creating a bare-bones test case after some discussion.
>
> I finally managed to reproduce the issue on OSX. It's subtle and
> likely rare in the real-world, though obviously not impossible given
> the report here. For posterity, here's a rundown (braindump) of the
> issue.
>
> When calling EC_KEY_new_by_curve_name(), openssl internally checks to
> see how to setup the curve's EC_METHOD (simple, montgomery, or nist).
>
> Unfortunately, in all released OpenSSL versions (as far as I can tell
> master is the only branch that has fixed this issue), it's tested like
> so:
>
> - Try a method. If it fails, set a global error and return.
> - If the global error is set, try a different method.
>
> Prior to OpenSSL 1.0.0, these were tested in the order:
> EC_GFp_nist_method -> EC_GFp_mont_method. The secp256k1 curve fails
> the ec_GFp_nist_group_set_curve test and sets the global error. That
> error is then checked for failure, and EC_GFp_mont_method is tried
> (and succeeds).
>
> Obviously that global error usage is dangerous, especially since it
> happens for _each_ transaction verification in libbitcoinconsensus. In
> a multi-threaded environment, a crash is guaranteed within a few
> seconds.
>
> However, OpenSSL 1.0.1 reversed the order, trying EC_GFp_mont_method
> first, so that the global error doesn't end up being used:
> https://github.com/openssl/openssl/commit/17674bfdf75bffa4e225f8328b9d42cb74504005
>
> This was backported from master back to 1.0.1, but not to 1.0.0 or 0.9.8.
>
> So that change (accidentally) "solved" the problem. As you can see,
> it's still possible to hit the reversed order in the
> !defined(OPENSSL_BN_ASM_MONT) case. That's easily tested by building
> OpenSSL with the -no-asm config option. It's probably also the case
> for obscure architectures and OSs, but I haven't looked deeply into
> that. In that case, it's reasonable to assume that this crash would
> likely occur on such platforms.
>
> Also, OSX, even the latest version (10.10 as of now), still ships with
> OpenSSL 0.9.8. Which is how Tamas ran into it.
>
> Since Bitcoin Core and libbitcoinconsensus are switching away from
> OpenSSL for verification in the near future, I don't think this is
> much of an issue. Especially since the problem manifests as a
> controlled assertion failure/abort. However, I've prepared a patch for
> anyone who may run into the issue in the short-term:
> https://github.com/theuni/bitcoin/commit/adf0a691ee1c2f02e26828f976cfe5b78896b507
>
> I'll open a pull-request for Bitcoin Core to discuss whether it's
> worth merging or not.
>
> Regards,
> Cory
>
> On Fri, Aug 14, 2015 at 5:10 PM, Cory Fields <lists at coryfields.com> wrote:
>> Ugh, what an unfortunate oversight!
>>
>> The good news is that this issue should be solved in future versions
>> when we switch to the new libsecp256k1 lib for validation.
>>
>> For now, I've thrown together a quick hack to allow a user-specifiable
>> callback for libbitcoinconsensus. I think it's not worth messing with
>> the official API since it will be fixed soon, but rather hacked in as
>> a temporary work-around as needed. It _should_ be documented as an
>> issue with the current version, though.
>>
>> Please see here for a work-around to try:
>> https://github.com/theuni/bitcoin/commits/openssl-consensus-threads
>> Unfortunately it's not pretty, but it works fine here. Note that you
>> should give this some _serious_ testing before deploying in any real
>> way. It should mimic the way we do it in Core, though.
>>
>> That's on top of current master, but it should be trivial to apply to
>> release tags.
>>
>> Please let me know how it works out.
>>
>> Regards,
>> Cory
>>
>> On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
>>>
>>> The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
>>>
>>> Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
>>>
>>> arises under that stress.
>>>
>>> I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
>>> Registering those however would require access to OpenSSL functions, not exported from the lib.
>>>
>>> I’d be thankful for a pointer to a workaround.
>>>
>>> Tamas Blummer
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/43bc1a5b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/43bc1a5b/attachment.sig>

2023-06-07 17:35:07

- reply

📅 Original date posted:2015-08-14
📝 Original message:We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
arises under that stress.
I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
Registering those however would require access to OpenSSL functions, not exported from the lib.
I’d be thankful for a pointer to a workaround.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/35f728b8/attachment-0001.sig>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-02-20
📝 Original message:On Feb 20, 2015, at 5:18 PM, Wladimir <laanwj at gmail.com> wrote:
> On Fri, 20 Feb 2015, Adam Back wrote:
>
>> So I was wondering what about changing to committing a bloom filter of
>> the addresses in the block. Its seems surprising no one thought of it
>> that way before (as it seems obvious when you hear it) but that seems
Such a bloom filter was present in the Bits of Proof block store in its last
public version, so the idea obvious, but not new.
It did support well scanning for BIP32 addresses as the query set extends
while progressing.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/b23aaa4c/attachment.sig>

2023-06-07 15:30:37

- reply

📅 Original date posted:2015-02-19
📝 Original message:On Feb 19, 2015, at 3:03 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> First, I strongly disagree with voting here for reasons that I hope others will elaborate on.
I meant voting by pledging on the lighthouse project, not here on the list. Sorry for not stating this explicitelly.
> Second, I think that squeezing all possible language bindings into a project is also unproductive.
The language binding would be an independent and separately hosted project only using the C interface of the libconsensus library.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/1d9a7a74/attachment.sig>

2023-06-07 15:30:36

- reply

📅 Original date posted:2015-02-19
📝 Original message:On Feb 19, 2015, at 6:22 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> I launched a Lighthouse project to add Java Language Binding to lib consensus. Let's turn the debate to a constructive vote.
>
> See on https://www.reddit.com/r/LighthouseProjects
I should have added the project description here, as above is only readable with lighthouse:
Java Language Binding for Core Consensus Library
Bitcoin Core 0.10.0 comes with a library for external services that validates Bitcoin transactions with the code base of the core.
The proposed language binding would unleash innovation of JVM application developer without raising concern of a network fork through incompatible alternate implementations of the protocol.
The language binding would be written with lightweight, immutable, self contained data classes that use only language standard libraries, therefore suitable for any service framework.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/a81f3361/attachment.sig>

2023-06-07 15:30:36

- reply

📅 Original date posted:2015-02-19
📝 Original message:Libconsensus will create an in-process alternative to the border router setup I currently advocate in a production environment.
It is not sufficient yet, since only checking scripts, but is the move I was long waiting for.
I launched a Lighthouse project to add Java Language Binding to lib consensus. Let's turn the debate to a constructive vote.
See on https://www.reddit.com/r/LighthouseProjects
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/1ac23888/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/1ac23888/attachment.sig>

2023-06-07 15:30:35

- reply

📅 Original date posted:2015-02-15
📝 Original message:On Feb 15, 2015, at 6:02 PM, Peter Todd <pete at petertodd.org> wrote:
> Yes you are dicking around.
I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface.
The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging
and now comes handy to create a side chain.
> Don't assume your prior experience with other commercial projects
Acquire some before you claim its useless.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150215/07a0bd91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150215/07a0bd91/attachment.sig>

2023-06-07 15:30:33

- reply

📅 Original date posted:2015-02-14
📝 Original message:Peter,
You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in.
On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library,
We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore
it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server.
On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Or you can be stereotypical programmers and dick around on github for
> the next ten years chasing stupid consensus bugs in code no-one uses.
The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity
that the ecosystem takes for granted and free.
I honestly admire the core team that works and progresses within these limits and perception.
I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not.
It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way.
It is entirely rational for me to focus on innovation that uses the core as a border router for this block chain.
I am rather thankful for the ideas of the side chains, that enable innovation that is no longer measured on unapologetic compatibility with a given code base, but its services to end user.
Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/e52a0ac4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/e52a0ac4/attachment.sig>

2023-06-07 15:30:20

- reply

📅 Original date posted:2015-02-12
📝 Original message:Mike,
Peter’s pull request might be a foot gun, but we are here to find out. One can’t claim Bitcoin core code is there to fork and then be disappointed if some really do it.
I am not sure protecting unconfirmed transactions ranks higher than fostering innovation not to depend on the same.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/5ff083f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/5ff083f3/attachment.sig>

2023-06-07 15:30:12

- reply

📅 Original date posted:2015-02-12
📝 Original message:Mike,
You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.
Some other’s might have seen the replaced transaction, but that only indicates for sure that the signer is fraudulent.
What should a node do that really cares of good reputation? Ignore both to be on the safe side?
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9e44ecf1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9e44ecf1/attachment.sig>

2023-06-07 15:30:12

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 3:16 PM, Mike Hearn <mike at plan99.net> wrote:
> You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.
>
> Fraudulent in what sense?
Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously.
Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant.
Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/08996a64/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/08996a64/attachment.sig>

2023-06-07 15:30:07

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
>
> How does my replace-by-fee patch *not* do that?
Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a0014230/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a0014230/attachment.sig>

2023-06-07 15:30:07

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> Why don't you use getrawmempool RPC call to synchronize mempool contents?
Since RPC interface does not scale to serve a multi user service.
In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.
POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only.
These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.
On Feb 12, 2015, at 8:45 AM, Peter Todd <pete at petertodd.org> wrote:
> IOW, assume every transaction your "border router" gives you is now the
> one and only true transaction, and everything conflicting with it must
> go.
You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting
double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .
Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.sig>

2023-06-07 15:30:06

- reply

📅 Original date posted:2015-02-12
📝 Original message:Peter,
An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core.
To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router.
Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/582e4829/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/582e4829/attachment.sig>

2023-06-07 15:29:14

- reply

📅 Original date posted:2015-02-01
📝 Original message:Thanks for the clarification. Yes, I referred to CompactSize using the lingo of https://en.bitcoin.it/wiki/Protocol_documentation
I am not sure if it is current concern. Apparently an exception is thrown if non-canonical CompactSize in a transaction s parsed.
Is it ensured that transactions are always parsed before computing their hash?
Tamas Blummer
On Feb 1, 2015, at 11:44 AM, Wladimir <laanwj at gmail.com> wrote:
>
> On Sun, 1 Feb 2015, Tamas Blummer wrote:
>
>> I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01)
>
> In serialize.h lingo you are talking about CompactSize, not VarInt.
>
> CompactSizes indeed have redundancy in their representation, i.e. the same number can be represented as up to four different byte sequences.
>
> VARINTs have a different format that (AFAIK) isn't used anywhere in the block chain. See WriteVarInt / ReadVarInt. These were designed to not have any redundancy in their representation.
>
>> This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the
>> merkle tree.
>
> Are you sure that this is a current concern? Non-canonical CompactSizes are forbidden - in serialize.h this is flagged in ReadCompactSize.
>
> Wladimir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/189a978e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/189a978e/attachment.sig>

2023-06-07 15:29:13

- reply

📅 Original date posted:2015-02-01
📝 Original message:I wonder of consequences if var_int is used in its longer than necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01)
This is already of interest if applying size limit to a block, since transaction count is var_int but is not part of the hashed header or the merkle tree.
It could also be used to create variants of the same transaction message by altered representation of txIn and txout counts, that would remain valid provided signatures validate with the shortest form, as that is created while re-serializing for signature hashing. An implementation that holds mempool by raw message hashes could be tricked to believe that a modified encoded version of the same transaction is a real double spend. One could also mine a valid block with transactions that have a different hash if regularly parsed and re-serialized. An SPV client could be confused by such a transaction as it was present in the merkle tree proof with a different hash than it gets for the tx with its own serialization or from the raw message.
Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/ca581637/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/ca581637/attachment.sig>

2023-06-07 15:29:06

- reply

📅 Original date posted:2015-01-23
📝 Original message:You mean an isolated signing device without memory right?
An isolated node would still know the transactions substantiating its coins, why would it sign them away to fees ?
Tamas Blummer
On Jan 23, 2015, at 4:47 PM, slush <slush at centrum.cz> wrote:
> Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner.
>
> M.
>
> On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed.
>
>
>
>
> On 01/23/2015 10:31 AM, Tamas Blummer wrote:
>> Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions.
>>
>> Tamas Blummer
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/5dc6f4b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/5dc6f4b7/attachment.sig>

2023-06-07 15:29:06

- reply

📅 Original date posted:2015-01-23
📝 Original message:Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions.
Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/04250c18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/04250c18/attachment.sig>