> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blum...@gmail.com> wrote: > > 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.
Burning is not an economic concern and cannot be prevented. As there are fewer coins, all things being equal, the cost of each increases, and thus fewer must be burned to achieve the same cost. So assuming sufficient divisibility (an existing Bitcoin assumption) it is sustainable. But as I demonstrated, it’s not necessary. > - Pay high fees in self dealing transactions. This could work and would > benefit miner. This is essentially what I suggested, though presumably you mean Bitcoin fees not secondary network. > - 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. Another reason why simply spending or burning them is preferential. > - 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. This implies additional complexity with no benefit to anyone required by the scenario, which was my implication. > - 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. The terms lend/borrow are misleading here, as I have previously shown. The coin is neither spendable nor consumable. This is why I have used the terms owner/renter. Yes, the renter can sell the remaining rental expense to another. Yes, the potential incremental value over the other scenarios is transferability of the output, but this accrues to both to the advertiser/renter and the owner (trade always benefits both parties trading). This transfer incurs a fee if on chain, and in the tracking scenario may easily overwhelm the effective benefit (fraction of the rental, no higher than dust, not yet expired), making it economically non-transferrable. In the advertising scenario this transfer can be achieved independent of Bitcoin, by simply changing the advertisement (e.g. publish a provably-superseding ad for the same output), avoiding the material on-chain fee. Recall that the value of the coin cannot be captured by the advertiser through transfer, just the tracking cost. e > Tamas Blummer > > >> On Jul 4, 2019, at 18:43, Eric Voskuil <e...@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 <zmnsc...@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 > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
