Eric Voskuil [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-02 to 2022-10-05
💬 Posted a total of 292 messages
📚 Participated in the following categories: Bitcoin-development, Libbitcoin, bitcoin-dev, BIP 1xx - Draft, BIP Proposal, trivial protocol change BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c

Profile Code

nprofile1qqsgygzlyuhejhvmuap80x3urx32uzzj9js5sfxr5wcp2f0m23v3v8sprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdg2v4j0

Publishing to

relay.noswhere.com

Author Public Key

npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c

Show more details

Last Notes

2023-06-07 23:14:10

- reply

📅 Original date posted:2022-10-05
📝 Original message:>> [Regarding bandwidth waste: I've pointed out in years past that
>> breaking the Bitcoin versioning scheme creates a requirement that any
>> unknown message type be considered valid. Up until a recently-deployed
>> protocol change, it had always been possible to validate messages by
>> type. I noticed recently that validating nodes have been dropping peers
>> at an increasing rate (a consequence of that deployment). Despite being
>> an undocumented compatibility break, it is now unfortunately a matter
>> of protocol that a peer must allow its peers to waste its bandwidth to
>> remain compatible - something which we should eliminate.]
>
> The only message listed as not being preceded by a bumped version number
> in:
>
> https://github.com/libbitcoin/libbitcoin-network/wiki/Protocol-Versioning
Good find, still a work in progress.
> is addrv2 (though addrv2 is gated on mutual exchange of sendaddrv2, so
> it's presumably the sendaddrv2 message at issue),
addrv2 is listed as the BIP title, the message that would cause the break is sendaddrv2 (quoted text).
> however since [0]
> sendaddrv2 messages are only sent to nodes advertising version 70016 or
> later (same as wtxidrelay).
I don’t see this constraint in BIP155. Do you mean that addrv2 support was released in Core at the same time as wtxidrelay, or that it is an undocumented version constraint implemented in Core?
> ADDRV2 was introduced May 20 2020 after the
> 0.20 branch, and SENDADDRV2 gating was merged Dec 9 2020 and included
> from 0.21.0rc3 onwards.
To clarify, there was no Core release of addrv2 without sendaddrv2 apart from 0.21 release candidates?
> [0] https://github.com/bitcoin/bitcoin/pull/20564
>
> I'm only seeing "bytesrecv_per_msg.*other*" entries for nodes advertising
> a version of 0.17 and 0.18,
> which I presume is due to REJECT messages (for taproot txs, perhaps?).
Ideally you should not be seeing reject messages as protocol “other”, as these are valid messages as of protocol version 70002, and they are excluded by negotiated version before that. While there is no requirement to send them (BIP61 only defines a new message type), they remain defined messages until removed by a future protocol version.
> Otherwise, I don't think there are any unexpected
> messages you should be receiving when advertising version 70015 or lower.
Yet nodes with an advertised protocol version of 70013 are receiving sendaddrv2. I've removed the IP address from the log extract below.
17:53:45.022347 DEBUG [network] Peer [x.x.x.x:8333] protocol version (70016) user agent: /Satoshi:0.21.0()/
17:53:45.022377 DEBUG [network] Negotiated protocol version (70013) for [x.x.x.x.135:8333]
17:53:45.022767 INFO [network] Connected outbound channel [x.x.x.x.135:8333]
17:53:45.022913 DEBUG [node] Ask [x.x.x.x:8333] for headers after [00000000000000000002e8c1c59fc86f721ba3a3294d2b1165597ddb910058e6]
17:53:45.023184 WARNING [network] Invalid sendaddrv2 payload from [x.x.x.x:8333] object does not exist
17:53:45.023317 DEBUG [network] Stop protocol version on [x.x.x.x:8333] object does not exist
17:53:45.023359 DEBUG [network] Outbound channel stopped [x.x.x.x:8333] success
To my knowledge the only other time we've seen consistent invalid message traffic on the network was during the work on BIP150 (withdrawn), at which point BIP150 nodes were being deployed on mainnet. I made comments here on the issue at the time, which as I recall were generally rejected in favor of forcing nodes to allow all invalid traffic. In any case BIP150 was withdrawn and BIP324 proposed, which fixes this particular issue (using a service bit).
Some argued at the time that allowance for invalid messages was a longstanding requirement in the protocol. I knew that this was not the case (except for BIP37, break documented in BIP60) because libbitcoin validates all messages, which led me to eventually document it. Recently I updated and posted that documentation (the github wiki link you found). This was a consequence of reviewing the Generic Package Relay proposal, which is also incompatible. In doing so I noticed this issue with BIP155 and BIP330 as well. This led us to check the logs for peer disconnects as a result of invalid messages, at which point the above was found to be an increasingly common occurrence.
Best,
e
> Cheers,
> aj

2023-06-07 23:13:55

- reply

📅 Original date posted:2022-09-27
📝 Original message:Thanks again for the feedback. Comments inline.
> On Sep 27, 2022, at 02:29, alicexbt <alicexbt at protonmail.com> wrote:
>
> Hi Eric,
>
>
>> If by "range" you mean a connected tx subgraph, I don't see why not. But note that nodes only operate over signed txs. PSBT is a wallet workflow.
>
> Matt Corallo mentioned that pre-signed transactions created with low fee rate become an issue when they are broadcasted after a long time and there is a high demand for block space at that moment.
Yes, I understood this. There are many ways that a fee may be created which is too low for propagation.
> Example:
>
> Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte however its taking hours/days to confirm the transaction with such low fee rate.
>
> Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 sat/vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed in a few minutes.
>
>
>> Always. Only signed transactions are accepted. But assuming you are referring to a transaction that has been produced by a pre-signing workflow, I'm not sure how this would be distinct from any other tx.
>
>
> `minfeefilter` for all peers of my node was 0.00001000 at the time of writing this email. I am assuming nobody creates pre-signed transaction with fee rate below 1 sat/vbyte. How often does it happen that `minfeefilter` is above this default value?
I don’t consider node configuration relevant, regardless of its apparent consistency.
>> I'm not sure I follow this, maybe you could reword it. But it seems that you are saying that CPFP fee-bumping is a problem scenario and the complexity of the proposed solutions are not justified by such scenarios.
>
>
> Sorry that sentence was confusing. Yes complexity isn't justified for CPFP fee-bumping txs below minimum fee rate.
>
>
>> There are many node implementations used presently. And of course these are protocol proposals, which presumes more than one implementation.
>
>
> Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) however they aren't used by lot of nodes. Based on this [chart][1] 98% nodes use bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin core contributors and things could be different if even 30% nodes used other implementations.
I don’t consider such a measure relevant. This is a protocol consideration. Also consider that many nodes are not visible, and aspects of nodes, such as for p2p communication, are embedded into applications such as wallets - which could easily exceed the number of visible nodes.
>> I don't consider this relevant to any protocol considerations. Miners should always be expected to select the most optimal set of txs available in the time available to do so.
>
>
> Agree, miners should be expected to select most optimal set of txs. However, according to one [comment][2] by Pieter Wuille, miners could affect the security of some bitcoin projects with MEV.
This would be a deficiency in such projects, by assuming economic irrationality. The fact that fees will become a greater percentage of the block reward is a surprise to no one.
>> Over time we are likely to see that the only policies that remain in widespread application are those that are necessary for DOS protection (fee rate), as other restrictions are not economically rational and cannot be enforced. We've seen recent debate regarding dust policy, and op_return policy. "non-standard" txs are perfectly valid but get stuck very easily. I'll reiterate, any policy beyond what is published via the protocol will cause the above problems.
>
> I completely agree with this.
>
>
> [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
> [2]: https://bitcoin.stackexchange.com/questions/107787/front-running-in-bitcoin#comment123441_107796
>
>
> /dev/fd0

2023-06-07 23:11:38

- reply

📅 Original date posted:2022-07-09
📝 Original message:In Bitcoin we use the term “supply“ as a reference to the number of coins minted. This colloquialism is commonly conflated with the economic concept of supply, and then injected into a supply/demand relation as if it had the same applicability. Economically supply refers to desire to sell, while demand refers to desire to buy.
e
> On Jul 9, 2022, at 08:24, Eric Voskuil <eric at voskuil.org> wrote:
>
> To clarify, price inflation is not caused by market production. Attributing the observed lack of inflation (eg fee %) to loss is an assumed relation.
>
> Even if the amount of loss was known (which it is not), there remains an assumption in the correlation of non-lost coins to price. Demand determines price, not the amount of something in existence, hence the folly of S2F (1/monetary-inflation).
>
> e
>
>> On Jul 9, 2022, at 08:15, Peter Todd <pete at petertodd.org> wrote:
>> On Sat, Jul 09, 2022 at 07:26:22AM -0700, Eric Voskuil wrote:
>>>> Due to lost coins, a tail emission/fixed reward actually results in a stable money supply. Not an (monetarily) inflationary supply.
>>> This observation is not a proof of lost coins, that is an assumption.
>> To be clear, are you claiming that there is no proof that coins are lost?
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 23:11:38

- reply

📅 Original date posted:2022-07-20
📝 Original message:If there’s no block reward, there’s no Bitcoin, so that’s moot. But setting that aside. The business model of the state is to preserve the reward it obtains from its own money. This is the reason for currency controls, which are common.
e
> On Jul 20, 2022, at 03:17, Peter via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >And therefore this reduces to the simple fact that tx fees are what provides censorship resistance, whether you mine your own or others?.
>
>
> What's the business model of the person who mines with the intention to censor transactions when there's no block reward?
>
>
>
> Regards
>
> Peter Kroll
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:11:33

- reply

📅 Original date posted:2022-07-10
📝 Original message:
> On Jul 10, 2022, at 07:17, alicexbt <alicexbt at protonmail.com> wrote:
> Hi ZmnSCPxj,
>
>
>> Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
>> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
>
> `consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can be decreased to 195000. This will reduce the number of halvings from 34 to 14 and subsidy will be 0 when it becomes less than 0.01 although not sure if this will be a soft fork.
Soft fork, though a bit aggressive, as it would invalidate all existing blocks above the first new halving height block which claimed more than the reduced reward.
Increasing the value would be a hard fork, as it would validate blocks that would previously have been invalid, as opposed to a soft fork, which invalidates blocks that would previously have been valid.
e
> I doubt there will be consensus for it because all the [projections and predictability][2] about bitcoin(currency) would be affected by this change. Maybe everyone can agree with this change if most of the miners start being 'compliant' like one of the coinjoin implementation.
>
> [1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
> [2]: https://en.bitcoin.it/wiki/Controlled_supply
>
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> Good morning e, and list,
>>
>>> Yet you posted several links which made that specific correlation, to which I was responding.
>>> Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
>>> The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
>>
>>
>> To clarify about censorship resistance and perpetual issuance ("tail emission"):
>>
>> * Suppose I have two blockchains, one with a constant block subsidy, and one which had a block subsidy but the block subsidy has become negligible or zero.
>> * Now consider a censoring miner.
>> * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
>> * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
>> * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
>> * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
>> * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.
>>
>> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.
>> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
>> Thus, there is no incentive, considering only the block subsidy, to not censor coin movements.
>> Only per-transaction fees have an incentive to not censor coin movements.
>>
>>
>> Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
>> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:11:29

- reply

📅 Original date posted:2022-07-18
📝 Original message:> On Jul 18, 2022, at 14:14, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>>
>> subsidy to directly tie miner revenue to the total value of Bitcoin
>> makes it not exactly how we want to incentivise a service that keeps
>>
>
> again, this is meaningless. if the fees aren't enough to keep bitcoin secure for large transactions, then large holders are incentivised to mine
Yes, this is another way to pay the tx fee - you mine at cost sufficient to overpower the censor. You are spending the block reward in getting your txs confirmed, and that’s your fee.
But unless you are mining full blocks of only your own transactions, this implies that you are accepting these higher fees on censored txs from others. Otherwise you are simply mining at a loss, which we cannot use as a rational basis for security.
And therefore this reduces to the simple fact that tx fees are what provides censorship resistance, whether you mine your own or others’.
e
> that's it.
>
> it's not complicated
> _______________________________________________
> 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/20220718/fd07a1e3/attachment.html>

2023-06-07 23:11:26

- reply

📅 Original date posted:2022-07-09
📝 Original message:Yet you posted several links which made that specific correlation, to which I was responding.
Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
e
> On Jul 9, 2022, at 08:31, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jul 09, 2022 at 08:24:51AM -0700, Eric Voskuil wrote:
>> To clarify, price inflation is not caused by market production. Attributing the observed lack of inflation (eg fee %) to loss is an assumed relation.
>
> My article is a mathematical proof that has nothing to do with observations of
> inflation.
>
> What I did is prove that if there is tail emission/fixed supply, the coin
> supply will converge towards a fixed amount because the coin supply dependant
> rate of coin loss balances out the fixed rate of coin production.
>
> That proof has nothing to do with market dynamics and would happen in any
> system, economic or not, with similar underlying dynamics.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/octet-stream
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220709/be85c5c5/attachment.obj>
-------------- next part --------------

2023-06-07 23:11:24

- reply

📅 Original date posted:2022-07-09
📝 Original message:To clarify, price inflation is not caused by market production. Attributing the observed lack of inflation (eg fee %) to loss is an assumed relation.
Even if the amount of loss was known (which it is not), there remains an assumption in the correlation of non-lost coins to price. Demand determines price, not the amount of something in existence, hence the folly of S2F (1/monetary-inflation).
e
> On Jul 9, 2022, at 08:15, Peter Todd <pete at petertodd.org> wrote:
>
> On Sat, Jul 09, 2022 at 07:26:22AM -0700, Eric Voskuil wrote:
>>> Due to lost coins, a tail emission/fixed reward actually results in a stable money supply. Not an (monetarily) inflationary supply.
>>
>> This observation is not a proof of lost coins, that is an assumption.
>
> To be clear, are you claiming that there is no proof that coins are lost?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/octet-stream
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220709/ea261b14/attachment.obj>

2023-06-07 23:11:22

- reply

📅 Original date posted:2022-07-09
📝 Original message:> Due to lost coins, a tail emission/fixed reward actually results in a stable money supply. Not an (monetarily) inflationary supply.
This observation is not a proof of lost coins, that is an assumption. It is the provable consequence of market, as opposed to monopoly, production.
https://github.com/libbitcoin/libbitcoin-system/wiki/Inflation-Principle
Mises’ unfortunate error in the application of the Cantillon Effect to gold perpetuates this misperception. One could imagine applying this theory to all goods, not just money, and conclude perpetual loss of value in everything produced, as a consequence of production. One might then be tempted to attribute the fact that this is not observable to loss/depreciation/consumption. While it is certainly possible that the amount of gold produced every year is offset by the amount lost, this of course implies that all of it is lost.
“Circulation” does not determine demand, all money is always held by someone. Changing hands only changes who owns the money, not its purchasing power. See Rothbard’s critique of monetary “velocity”.
e
> On Jul 9, 2022, at 05:47, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> New blog post:
>
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
> tl;dr: Due to lost coins, a tail emission/fixed reward actually results in a
> stable money supply. Not an (monetarily) inflationary supply.
>
> ...and for the purposes of reply/discussion, attached is the article itself in
> markdown format:
>
> ---
> layout: post
> title: "Surprisingly, Tail Emission Is Not Inflationary"
> date: 2022-07-09
> tags:
> - bitcoin
> - monero
> ---
>
> At present, all notable proof-of-work currencies reward miners with both a block
> reward, and transaction fees. With most currencies (including Bitcoin) phasing
> out block rewards over time. However in no currency have transaction fees
> consistently been more than 5% to 10% of the total mining
> reward[^fee-in-reward], with the exception of Ethereum, from June 2020 to Aug 2021.
> To date no proof-of-work currency has ever operated solely on transaction
> fees[^pow-tweet], and academic analysis has found that in this condition block
> generation is unstable.[^instability-without-block-reward] To paraphrase Andrew
> Poelstra, it's a scary phase change that no other coin has gone through.[^apoelstra-quote]
>
> [^pow-tweet]: [I asked on Twitter](https://twitter.com/peterktodd/status/1543231264597090304) and no-one replied with counter-examples.
>
> [^fee-in-reward]: [Average Fee Percentage in Total Block Reward](https://bitinfocharts.com/comparison/fee_to_reward-btc-eth-bch-ltc-doge-xmr-bsv-dash-zec.html#alltime)
>
> [^instability-without-block-reward]: [On the Instability of Bitcoin Without the Block Reward](https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf)
>
> [^apoelstra-quote]: [From a panel at TABConf 2021](https://twitter.com/peterktodd/status/1457066946898317316)
>
> Monero has chosen to implement what they call [tail
> emission](https://www.getmonero.org/resources/moneropedia/tail-emission.html):
> a fixed reward per block that continues indefinitely. Dogecoin also has a fixed
> reward, which they widely - and incorrectly - refer to as an "abundant" supply[^dogecoin-abundant].
>
> [^dogecoin-abundant]: Googling "dogecoin abundant" returns dozens of hits.
>
> This article will show that a fixed block reward does **not** lead to an
> abundant supply. In fact, due to the inevitability of lost coins, a fixed
> reward converges to a **stable** monetary supply that is neither inflationary
> nor deflationary, with the total supply proportional to rate of tail emission
> and probability of coin loss.
>
> Credit where credit is due: after writing the bulk of this article I found out
> that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/)
> also observed that tail emission results in a stable coin supply
> [a few years ago](https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/).
> There's probably others too: it's a pretty obvious result.
>
>
> <div markdown="1" class="post-toc">
> # Contents
> {:.no_toc}
> 0. TOC
> {:toc}
> </div>
>
> ## Modeling the Fixed-Reward Monetary Supply
>
> Since the number of blocks is large, we can model the monetary supply as a
> continuous function $$N(t)$$, where $$t$$ is a given moment in time. If the
> block reward is fixed we can model the reward as a slope $$k$$ added to an
> initial supply $$N_0$$:
>
> $$
> N(t) = N_0 + kt
> $$
>
> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independent: I'm not any more or less likely to forget my passphrase because
> you recently lost your coins in a boating accident — an accident I probably
> don't even know happened. Since the number of individual coins (and their
> owners) is large — as with the number of blocks — we can model this loss as
> though it happens continuously.
>
> Since coins can only be lost once, the *rate* of coin loss at time $$t$$ is
> proportional to the total supply *at that moment* in time. So let's look at the
> *first derivative* of our fixed-reward coin supply:
>
> $$
> \frac{dN(t)}{dt} = k
> $$
>
> ...and subtract from it the lost coins, using $$\lambda$$ as our [coin loss
> constant](https://en.wikipedia.org/wiki/Exponential_decay):
>
> $$
> \frac{dN(t)}{dt} = k - \lambda N(t)
> $$
>
> That's a first-order differential equation, which can be easily solved with
> separation of variables to get:
>
> $$
> N(t) = \frac{k}{\lambda} - Ce^{-\lambda t}
> $$
>
> To remove the integration constant $$C$$, let's look at $$t = 0$$, where the
> coin supply is $$N_0$$:
>
> $$
> \begin{align}
> N_0 &= \frac{k}{\lambda} - Ce^{-\lambda 0} = \frac{k}{\lambda} - C \\
> C &= \frac{k}{\lambda} - N_0
> \end{align}
> $$
>
> Thus:
>
> $$
> \begin{align}
> N(t) &= \frac{k}{\lambda} - \left(\frac{k}{\lambda} - N_0 \right)e^{-\lambda t} \\
> &= \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t}
> \end{align}
> $$
>
>
> ## Long Term Coin Supply
>
> It's easy to see that in the long run, the second half of the coin supply
> equation goes to zero because $$\lim_{t \to \infty} e^{-\lambda t} = 0$$:
>
> $$
> \begin{align}
> \lim_{t \to \infty} N(t) &= \lim_{t \to \infty} \left[ \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t} \right ] = \frac{k}{\lambda} \\
> N(\infty) &= \frac{k}{\lambda}
> \end{align}
> $$
>
> An intuitive explanation for this result is that in the long run, the initial
> supply $$N_0$$ doesn't matter, because approximately all of those coins will
> eventually be lost. Thus in the long run, the coin supply will converge towards
> $$\frac{k}{\lambda}$$, the point where coins are created just as fast as they
> are lost.
>
>
> ## Short Term Dynamics and Economic Considerations
>
> Of course, the intuitive explanation for why supply converges to
> $$\frac{k}{\lambda}$$, also tells us that supply must converge fairly slowly:
> if 1% of something is lost per year, after 100 years 37% of the initial supply
> remains. It's not clear what the rate of lost coins actually is in a mature,
> valuable, coin. But 1%/year is likely to be a good guess — quite possibly less.
>
> In the case of Monero, they've introduced tail emission at a point where it
> represents a 0.9% apparent monetary inflation rate[^p2pool-tail]. Since the number of
> previously lost coins, and the current rate of coin loss, is
> unknown[^unknowable] it's not possible to know exactly what the true monetary
> inflation rate is right now. But regardless, the rate will only converge
> towards zero going forward.
>
> [^unknowable]: Being a privacy coin with [shielded amounts](https://localmonero.co/blocks/richlist), it's not even possible to get an estimate of the total amount of XMR in active circulation.
>
> [^p2pool-tail]: P2Pool operates [a page with real-time date figures](https://p2pool.io/tail.html).
>
> If an existing coin decides to implement tail emission as a means to fund
> security, choosing an appropriate emission rate is simple: decide on the
> maximum amount of inflation you are willing to have in the worst case, and set
> the tail emission accordingly. In reality monetary inflation will be even lower
> on day zero due to lost coins, and in the long run, it will converge towards
> zero.
>
> The fact is, economic volatility dwarfs the effect of small amounts of
> inflation. Even a 0.5% inflation rate over 50 years only leads to a 22% drop.
> Meanwhile at the time of writing, Bitcoin has dropped 36% in the past year, and
> gained 993% over the past 5 years. While this discussion is a nice excuse to
> use some mildly interesting math, in the end it's totally pedantic.
>
> ## Could Bitcoin Add Tail Emission?
>
> ...and why could Monero?
>
> Adding tail emission to Bitcoin would be a hard fork: a incompatible rule
> change that existing Bitcoin nodes would reject as invalid. While Monero was
> able to get sufficiently broad consensus in the community to implement tail
> emission, it's unclear at best if it would ever be possible to achieve that for
> the much larger[^btc-vs-xmr-market-cap] Bitcoin. Additionally, Monero has a
> culture of frequent hard forks that simply does not exist in Bitcoin.
>
> [^btc-vs-xmr-market-cap]: [As of writing](https://web.archive.org/web/20220708143920/https://www.coingecko.com/), the apparent market cap of Bitcoin is $409 billion, almost 200x larger than Monero's $2.3 billion.
>
> Ultimately, as long as a substantial fraction of the Bitcoin community continue
> to run full nodes, the only way tail emission could ever be added to Bitcoin is
> by convincing that same community that it is a good idea.
>
>
> ## Footnotes
> _______________________________________________
> 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/20220709/3e785ca0/attachment-0001.html>

2023-06-07 23:11:15

- reply

📅 Original date posted:2022-07-07
📝 Original message:Without a performance requirement there is no reason you can’t store the BIP39 words in any order you want. So it’s certainly possible, just brute force the recovery. If you have less than a second vs. a few days then it’s a different question.
e
> On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Part of the rules of my challenge is that the 'new' words need to be in the same pool as the 'old' words, so any ordering is okay. Without that requirement it's mathematically very straightforward.
>
>> On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak <stick at satoshilabs.com> wrote:
>> There is. Just encode the index of permutation used to scramble the otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3 words should be enough.
>>
>> Repetitions make this more difficult, though.
>>
>>> On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I made a python implementation for a different mnemonic encoding. The encoding requires user to remember words but not the order of those words.
>>>> The code is open (MIT license) at https://github.com/sancoder/noomnem
>>>
>>> Thanks Anton. There's an interesting mathematical question of whether it's possible to make a code like this which always uses the BIP-39 words for the same key as part of its encoding, basically adding a few words as error correction in case the order is lost or confused. If the BIP-39 contains a duplicate you can add an extra word.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> --
>> Best Regards / S pozdravom,
>>
>> Pavol "stick" Rusnak
>> Co-Founder, SatoshiLabs
> _______________________________________________
> 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/20220707/5485b726/attachment.html>

2023-06-07 23:11:04

- reply

📅 Original date posted:2022-07-07
📝 Original message:Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that of 5000tx. This is of course why I stated my assumption. Yet this simple example should make clear that at some point a reduction in confirmation rate reduces reward. Otherwise a rate of zero implies infinite reward.
You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce “much higher fees” or “better security”.
What you call a “bidding war” is merely market pricing, as it occurs with any good. People *always* will pay as much as they will pay. This is tautological. What you cannot say is how much more someone will pay at any given time for any given good, until they have done it. And I’m pretty sure Bitcoin hasn’t done it.
You cannot prove what the price of anything will be, nor can any “papers”. The absurdity of S2F should have clearly demonstrated that by now. Value is an individual human preference.
If everyone pays 1 sat, then either miners are profitable at 1 sat, or these people are not getting confirmed (economic rationality always assumed).
The assumption of 1 sat txs filling blocks is based on a disproportionately high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 per tx in fees today, and as $680. As that falls, fees will continue to keep miners at the same profit level. If demand does not rise to compensate (as it always has) then hash rate will fall.
Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin is a market money. Like gold it is produced at market cost. Yet it will prevent Bitcoin from achieving any meaningful level of censorship resistance. This of course should make people look closely at such arguments.
Of course, once you have a censor, block space gets really small for those who want to resist the censor. Then of course only fees can offset the censorship. Without fee-based tx confirmation (for anonymity), and/or with a disproportionate subsidy going to the censor, a censor can operate profitably and indefinitely (under the assumption of constant demand). There is no reason to assume demand for censored txs wouldn’t even increase, given the white market blessing which so many seem to want.
But there is of course no real issue here. Simply fork off an inflation coin and test your theory. I mean, that’s the only way it can happen anyway.
e
> On Jul 7, 2022, at 14:11, Erik Aronesty <erik at q32.com> wrote:
>
>
> The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher.
>
> **the ones moving more sats will win the top spots and will pay as much as is reasonable**
>
> Smaller blocks produce better security for the network both in validation, and in fees.
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
> With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it.
>
>
>> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric at voskuil.org> wrote:
>> It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant.
>>
>> Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital.
>>
>> The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria.
>>
>> Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold.
>>
>> Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs.
>>
>> Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount.
>>
>> These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue.
>>
>> e
>>
>>>> On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:
>>>>
>>>
>>> > > We should not imbue real technology with magical qualities.
>>>
>>> > Precisely. It is economic forces (people), not technology, that provide security.
>>>
>>> Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives.
>>>
>>> In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators.
>>>
>>> Changes to inflation are, very likely, off the table.
>>>
>>>
>>>
>>>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>
>>>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >
>>>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
>>>> >> Billy,
>>>> >>
>>>> >> Proof of work and the difficulty adjustment function solve literally
>>>> >> everything you are talking about already.
>>>> >
>>>> > Unfortunately you are quite wrong: the difficulty adjustment function merely
>>>> > adjusts for changes in the amount of observable, non-51%-attacking, hashing
>>>> > power. In the event of a chain split, the difficulty adjustment function does
>>>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>>>> > against a censor, the difficulty adjustment does nothing.
>>>>
>>>> Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again.
>>>>
>>>> Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition.
>>>>
>>>> With falling difficulty this incentive is compounded.
>>>>
>>>> Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario.
>>>>
>>>> Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards).
>>>>
>>>> Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making.
>>>>
>>>> It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance.
>>>>
>>>> > We should not imbue real technology with magical qualities.
>>>>
>>>> Precisely. It is economic forces (people), not technology, that provide security.
>>>>
>>>> e
>>>>
>>>> >> Bitcoin does not need active economic governanance by devs or meddlers.
>>>> >
>>>> > Yes, active governance would definitely be an exploitable mechanism. On the
>>>> > other hand, the status quo of the block reward eventually going away entirely
>>>> > is obviously a risky state change too.
>>>> >
>>>> >>>> There is also zero agreement on how much security would constitute such
>>>> >>> an optimum.
>>>> >>>
>>>> >>> This is really step 1. We need to generate consensus on this long before
>>>> >>> the block subsidy becomes too small. Probably in the next 10-15 years. I
>>>> >>> wrote a paper
>>>> >
>>>> > The fact of the matter is that the present amount of security is about 1.7% of
>>>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
>>>> > already an amount low enough that it's much smaller than economic volatility.
>>>> >
>>>> > Obviously 0% is too small.
>>>> >
>>>> > There's zero reason to stress about finding an "optimal" amount. An amount low
>>>> > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
>>>> > would probably be fine; 0.1% would probably be fine.
>>>> >
>>>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on
>>>> > savings; 0.1% works out to be 7.2%
>>>> >
>>>> > These are all amounts that are likely to be dwarfed by economic shifts.
>>>> >
>>>> > --
>>>> > https://petertodd.org 'peter'[:-1]@petertodd.org
>>>> > _______________________________________________
>>>> > 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/20220707/c29f72fb/attachment-0001.html>

2023-06-07 23:11:03

- reply

📅 Original date posted:2022-07-07
📝 Original message:It’s not clear how reducing block size changes the fee aspect of the block reward. Assuming half the space implies twice the fee per avg tx the reward remains constant.
Any additional cost of processing more or less bytes would not matter, because of course this is just a cost that gets nulled out by difficulty — average profit (net income) is the cost of capital.
The reason for smaller vs. larger blocks is to ensure that individuals can afford to validate. That’s a threshold criteria.
Given unlimited size blocks, miners would still have to fix a point in time to mine, gathering as much fee as they can optimize in some time period presumably less than 10 minutes. The produces a limit to transaction volume, yet neither reward nor profit would be affected given the above assumptions. The difference would be in a tradeoff of per tx fee against the threshold.
Given Moore’s Law, that threshold is constantly decreasing, which will make it cheaper over time for more individuals to validate. But the difference for miners for smaller blocks is largely inconsequential relative to their other costs.
Increasing demand is the only thing that increases double spend security (and censorship resistance assuming fee-based reward). With rising demand there is rising overall hash rate, despite block reward and profit remaining constant. This makes the cost of attempting to orphan a block higher, therefore lowering the depth/time requirement implied to secure a given tx amount.
These are the two factors, demand and time. Less demand implies more time to secure a given amount against double spend, and also implies a lower cost to subsidize a censorship regime. But the latter requires a differential in reward between the censor and non-censoring miners. While this could be paid in side fees, that is a significant anonymity issue.
e
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:
>
>
> > > We should not imbue real technology with magical qualities.
>
> > Precisely. It is economic forces (people), not technology, that provide security.
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives.
>
> In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-spend security while reducing the burden on node operators.
>
> Changes to inflation are, very likely, off the table.
>
>
>
>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
>> >> Billy,
>> >>
>> >> Proof of work and the difficulty adjustment function solve literally
>> >> everything you are talking about already.
>> >
>> > Unfortunately you are quite wrong: the difficulty adjustment function merely
>> > adjusts for changes in the amount of observable, non-51%-attacking, hashing
>> > power. In the event of a chain split, the difficulty adjustment function does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>> > against a censor, the difficulty adjustment does nothing.
>>
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again.
>>
>> Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition.
>>
>> With falling difficulty this incentive is compounded.
>>
>> Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario.
>>
>> Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards).
>>
>> Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making.
>>
>> It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance.
>>
>> > We should not imbue real technology with magical qualities.
>>
>> Precisely. It is economic forces (people), not technology, that provide security.
>>
>> e
>>
>> >> Bitcoin does not need active economic governanance by devs or meddlers.
>> >
>> > Yes, active governance would definitely be an exploitable mechanism. On the
>> > other hand, the status quo of the block reward eventually going away entirely
>> > is obviously a risky state change too.
>> >
>> >>>> There is also zero agreement on how much security would constitute such
>> >>> an optimum.
>> >>>
>> >>> This is really step 1. We need to generate consensus on this long before
>> >>> the block subsidy becomes too small. Probably in the next 10-15 years. I
>> >>> wrote a paper
>> >
>> > The fact of the matter is that the present amount of security is about 1.7% of
>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
>> > already an amount low enough that it's much smaller than economic volatility.
>> >
>> > Obviously 0% is too small.
>> >
>> > There's zero reason to stress about finding an "optimal" amount. An amount low
>> > enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
>> > would probably be fine; 0.1% would probably be fine.
>> >
>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on
>> > savings; 0.1% works out to be 7.2%
>> >
>> > These are all amounts that are likely to be dwarfed by economic shifts.
>> >
>> > --
>> > https://petertodd.org 'peter'[:-1]@petertodd.org
>> > _______________________________________________
>> > 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/20220707/84fa83c9/attachment-0001.html>

2023-06-07 23:11:01

- reply

📅 Original date posted:2022-07-07
📝 Original message:> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literally
>> everything you are talking about already.
>
> Unfortunately you are quite wrong: the difficulty adjustment function merely
> adjusts for changes in the amount of observable, non-51%-attacking, hashing
> power. In the event of a chain split, the difficulty adjustment function does
> nothing; against a 51% attacker, the difficulty adjustment does nothing;
> against a censor, the difficulty adjustment does nothing.
Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, possibly to min difficulty if all non-censors stop mining and with all censors collaborating (one miner). Yet as difficulty falls, so does the cost of countering the censor. At min difficulty everyone can CPU mine again.
Given the presumption that fees rise on unconfirmed transactions, there is inherent economic incentive to countering at any level of difficulty. Consequently the censor is compelled to subsidize the loss resulting from forgoing higher fee transactions that are incentivizing its competition.
With falling difficulty this incentive is compounded.
Comparisons of security in different scenarios presume a consistent level of demand. If that demand is insufficient to offset the censor’s subsidy, there is no security in any scenario.
Given that the block subsidy (inflation) is paid equally to censoring and non-censoring miners, it offers no security against censorship whatsoever. Trading fee-based block reward for inflation-based is simply trading censorship resistance for the presumption of double-spend security. But of course, a censor can double spend profitably in any scenario where the double spend value (to the censor) exceeds that of blocks orphaned (as the censor earns 100% of all block rewards).
Banks and state monies offer reasonable double spend security. Not sure that’s a trade worth making.
It’s not clear to me that Satoshi understood this relation. I’ve seen no indication of it. However the decision to phase out subsidy, once a sufficient number of units (to assure divisibility) had been issued, is what transitions Bitcoin from a censorable to a censorship resistant money. If one does not believe there is sufficient demand for such a money, there is no way to reconcile that belief with a model of censorship resistance.
> We should not imbue real technology with magical qualities.
Precisely. It is economic forces (people), not technology, that provide security.
e
>> Bitcoin does not need active economic governanance by devs or meddlers.
>
> Yes, active governance would definitely be an exploitable mechanism. On the
> other hand, the status quo of the block reward eventually going away entirely
> is obviously a risky state change too.
>
>>>> There is also zero agreement on how much security would constitute such
>>> an optimum.
>>>
>>> This is really step 1. We need to generate consensus on this long before
>>> the block subsidy becomes too small. Probably in the next 10-15 years. I
>>> wrote a paper
>
> The fact of the matter is that the present amount of security is about 1.7% of
> the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
> already an amount low enough that it's much smaller than economic volatility.
>
> Obviously 0% is too small.
>
> There's zero reason to stress about finding an "optimal" amount. An amount low
> enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
> would probably be fine; 0.1% would probably be fine.
>
> Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on
> savings; 0.1% works out to be 7.2%
>
> These are all amounts that are likely to be dwarfed by economic shifts.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> 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/octet-stream
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/695b01f5/attachment.obj>

2023-06-07 23:10:07

- reply

📅 Original date posted:2022-06-21
📝 Original message:> On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the
> value of BTC they hold; if Bitcoin blocks aren't reliably created the value of
> *all* BTC goes down. It doesn't make sense for the entire cost of that security
> to be paid for on a per-tx basis.
Actually it does. People who transact are realizing the benefit of money - the avoidance of barter costs. Those who never transact, never realize any benefit.
> And there's a high chance paying for it on a
> per-tx basis won't work anyway due to lack of consistent demand.
>
> FWIW I prefer the demurrage route. Having something with finite supply as a means of measuring economic activity is unprecedented and I believe deeply important. I'm sympathetic to the argument that the security of the chain should not be solely the responsibility of transactors.
Chain security - censorship resistance (as opposed to individual double-spend security), is entirely dependent upon tx fees.
> We realize the value of money on receipt, hold *and* spend and it would be appropriate for there to be a balance of fees to that effect.
There is zero point in saving if you never spend. You can instead just burn your coin.
> While inflation may be simpler to implement (just chop off the last few halvings), I think it would be superior (on the assumption that such a hodl tax was necessary) to keep the supply fixed and have people's utxo balances decay, at least at the level of the UX.
A hoard decays naturally due to opportunity cost. Investing it requires transaction to invest, and transaction to earn (profit), and transaction to return it (interest).
> But also none of this should be reasons we don't improve Bitcoin's value (and therefore demand)
Demand is the only reason we save, and eventually transacting is the only motivation for saving. No transacting implies no demand - and no security.
e
> Keagan
>
>> On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>>> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> if we start seeing issues with block rewards being too low to maintain acceptable security, we're going to have multiple solutions being implemented for it, and definitely a hard fork to indefinitely maintain some degree of block subsidy
>>
>> if we failed to first try increasing block demand with advanced transaction support, it would seem like we were just throwing money and growth away to support one narrative (simplicty of function), while destroying another (finite supply)
>>
>> if stuff like covenant support and mweb gets us higher fees, with stuff like on-chain mixing protocols, vaults, and higher utility, it might be more than enough to sustain bitcoin on fees alone forever
>>
>> _______________________________________________
>> 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/20220621/758f2749/attachment.html>

2023-06-07 23:09:50

- reply

📅 Original date posted:2022-05-24
📝 Original message:The set of txs is the graph. Anything else would just reproduce the tx graph which must be traversed in any case.
Similarly the set of txs is the fee, the sigops, the size, and the weight. The only information required by packaging is the association of the txs with each other for the purpose of aggregate (vs. individual) net reward consideration.
Since a package can only be reasonably considered for a single block, there is a natural effective limit on acceptable package size. Since any number of individual txs may be transmitted, and the size/weight/sigops of one tx is bounded only by block validity, there is no reason to put any other constraints on packages. A package is just a set of txs that may fit into a block and may collectively be worth mining. A rational package is just a block or compact block without the header. Making it any more than that is unnecessary complexity.
If parts of a package satisfy profitability constraints, they will be accepted/mined and if other parts do not, they will be rejected. There’s no preventing this.
The only pertinent feature missing in the p2p protocol is the ability to associate a set of txs for consideration, where the set (or subset) may satisfy profitability constraints that would not be satisfied if the txs were considered individually.
e
> On May 24, 2022, at 16:21, Gloria Zhao via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hi aj,
>
> > If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>
> To clarify, in this situation, I'm imagining something like
> A: 0 sat, 100vB
> B: 1500 sat, 100vB
> C: 0 sat, 100vB
> X: 500 sat, 100vB
> feerate floor is 3sat/vB
>
> With the algo:
> > * is X alone above my fee rate? no, then forget it
> > * otherwise, s := X.size, f := X.fees, R := [X]
> > * for P = P1..Pn:
> > * do I already have P? then skip to the next parent
> > * s += P.size, f += P.fees, R += [P]
> > * if f/s above my fee rate floor? if so, request all the txs in R
>
> We'd erroneously ask for A+B+C+X, but really we should only take A+B.
> But wouldn't A+B also be a package that was announced for B?
> Please lmk if you were imagining something different. I think I may be missing something.
>
> > Is it plausible to add the graph in?
>
> Fun to think about. Most basic design would be to represent {spends, doesn’t spend} for a previous transaction in the package as a bit. Can think of it as a matrix where row i, column j tells you whether Tx j (directly) spends Tx i.
> But of course you can omit the last row, since the child spends all of them. And since topological ordering is a requirement, you only need as many bits as there are transactions preceding this one in the package.
> If you have up to 24 parents, you need 1 + 2 + ... + 23 bits to codify spending for the 2nd ... 24th parent. For a maximum 25 transactions, 23*24/2 = 276, seems like 36 bytes for a child-with-parents package. A few more for tx-with-ancestors.
> Then you can split it up into sub-packages and everything. Still not sure if we really need to.
>
> Also side note, since there are no size/count params, wondering if we should just have "version" in "sendpackages" be a bit field instead of sending a message for each version. 32 versions should be enough right?
>
> Best,
> Gloria
>
>> On Tue, 24 May 2022 at 12:48 Anthony Towns <aj at erisian.com.au> wrote:
>> On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao <gloriajzhao at gmail.com> wrote:
>> >> If you're asking for the package for "D", would a response telling you:
>> >> txid_D (500 sat, 100vB)
>> >> txid_A (0 sat, 100vB)
>> >> txid_B (2000 sat, 100 vB)
>> >> be better, in that case? Then the receiver can maybe do the logic
>> >> themselves to figure out that they already have A in their mempool
>> >> so it's fine, or not?
>> >Right, I also considered giving the fees and sizes of each transaction in
>> >the package in “pckginfo1”. But I don’t think that information provides
>> >additional meaning unless you know the exact topology, i.e. also know if
>> >the parents have dependency relationships between them. For instance, in
>> >the {A, B, D} package there, even if you have the information listed, your
>> >decision should be different depending on whether B spends from A.
>>
>> I don't think that's true? We already know D is above our fee floor so if B with A is also above the floor, we want them all, but also if B isn't above the floor, but all of them combined are, then we also do?
>>
>> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>>
>> Is it plausible to add the graph in?
>>
>> Cheers,
>> aj
>>
>>
>>
>> --
>> Sent from my phone.
> _______________________________________________
> 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/20220524/0e92938d/attachment.html>

2023-06-07 23:08:46

- reply

📅 Original date posted:2022-05-03
📝 Original message:It looks like you are talking about lending where the principal return is guaranteed by covenant at maturity. This make the net present value of the loan zero.
e
> On May 3, 2022, at 11:03, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello ZmnSCPxj,
>
> Such a system will have to be publicly advertised, in the same way we see centralized cryptocurrency staking shops buying ads all over the place. That's how they'll make retail hodlers aware that renting out your coins in this way is possible. If JoinMarket/Teleport users notice such ads appearing then we could change the taker code to remove the intermediate certificate keypair, and have the fidelity bond UTXO key sign the endpoint (IRC nickname or onion hostname) directly. This removes the possibility of fidelity bonds in cold storage. It would have to be done for privacy, and it wouldn't be too bad. Right now there's no cold storage solution for fidelity bonds yet JoinMarket has about 600 bitcoins locked up and advertised, which must be all on hot wallets.
>
> Best,
> CB
>
>> On 03/05/2022 06:26, ZmnSCPxj wrote:
>> Good morning Chris,
>>> Hello ZmnSCPxj,
>>>
>>> Renting out fidelity bonds is an interesting idea. It might happen in
>>> the situation where a hodler wants to generate yield but doesn't want
>>> the hassle of running a full node and yield generator. A big downside of
>>> it is that the yield generator income is random while the rent paid is a
>>> fixed cost, so there's a chance that the income won't cover the rent.
>> The fact that *renting* is at all possible suggests to me that the following situation *could* arise:
>> * A market of lessors arises.
>> * A surveillor creates multiple identities.
>> * Each fake identity rents separately from multiple lessors.
>> * Surveillor gets privacy data by paying out rent money to the lessor market.
>> In defiads, I and Tamas pretty much concluded that rental would happen inevitably.
>> One could say that defiads was a kind of fidelity bond system.
>> Our solution for defiads was to prioritize propagating advertisements (roughly equivalent to the certificates in your system, I think) with larger bonded values * min(bonded_time, 1 year).
>> However, do note that we did not intend defiads to be used for privacy-sensitive applications like JoinMarket/Teleport.
>> Regards,
>> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:06:11

- reply

📅 Original date posted:2022-03-22
📝 Original message:> > Even if it is not needed, it is kind of "free" if you take transaction size into account
>
> But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something.
I haven’t followed this thread, so apologies if I’m missing some context, but confirmed tx signaling remains miner signaling.
Regardless, miners are the only actors who can create soft fork compatibility, so theirs is the only relevant signal. Otherwise people can just fork themselves at any time using any voting mechanism they want.
e

2023-06-07 23:03:52

- reply

📅 Original date posted:2022-02-06
📝 Original message:> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> Dear Bitcoin Developers,
>
>> -When I contacted bitInfoCharts to divide the first interval of addresses, they kindly did divided to 3 intervals. From here:
>> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>> -You can see that there are more than 3.1m addresses holding ≤ 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
>
>> -Therefore, a simple solution would be to follow the difficulty adjustment idea and just delete all those
>
> That would be a soft-fork, and arguably could be considered theft. While commonly (but non universally) implemented standardness rules may prevent spending them currently, there is no requirement that such a rule remain in place. Depending on how feerate economics work out in the future, such outputs may not even remain uneconomical to spend. Therefore, dropping them entirely from the UTXO set is potentially destroying potentially useful funds people own.
>
>> or at least remove them to secondary storage
>
> Commonly adopted Bitcoin full nodes already have two levels of storage effectively (disk and in-RAM cache). It may be useful to investigate using amount as a heuristic about what to keep and how long. IIRC, not even every full node implementation even uses a UTXO model.
You recall correctly. Libbitcoin has never used a UTXO store. A full node has no logical need for an additional store of outputs, as transactions already contain them, and a full node requires all of them, spent or otherwise.
The hand-wringing over UTXO set size does not apply to full nodes, it is relevant only to pruning. Given linear worst case growth, even that is ultimately a non-issue.
>> for Archiving with extra cost to get them back, along with non-standard UTXOs and Burned ones (at least for publicly known, published, burn addresses).
>
> Do you mean this as a standardness rule, or a consensus rule?
>
> * As a standardness rule it's feasible, but it makes policy (further) deviate from economically rational behavior. There is no reason for miners to require a higher price for spending such outputs.
> * As a consensus rule, I expect something like this to be very controversial. There are currently no rules that demand any minimal fee for anything, and given uncertainly over how fee levels could evolve in the future, it's unclear what those rules, if any, should be.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:03:09

- reply

📅 Original date posted:2022-02-01
📝 Original message:> On Feb 1, 2022, at 00:32, Bram Cohen <bram at chia.net> wrote:
>
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric at voskuil.org> wrote:
>>
>>
>>>> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on.
>> What flag?
>
> The opt-in RBF flag in transactions.
Was being facetious. The “disrespect” referred to above assumes respect that some implementations have never given.
>>> There are two different common regimes which result in different incentivized behavior. One of them is that there's more than a block's backlog in the mempool in which case between two conflicting transactions the one with the higher fee rate should win. In the other case where there isn't a whole block's worth of transactions the one with higher total value should win.
>> These are not distinct scenarios. The rational choice is the highest fee block-valid subgraph of the set of unconfirmed transactions, in both cases (within the limits of what is computationally feasible of course).
>
> It's weird because which of two or more conflicting transactions should win can oscillate back and forth depending on other stuff going on in the mempool.
The assumption of RAM storage is an error and unrelated to network protocol. There is nothing “going on” in a set of unconfirmed valid transactions. They are logically unchanging.
> There's already a bit of that with child pays but this is stranger and has more oddball edge cases about which transactions to route.
There’s really no such thing. The p2p network is necessarily permissionless. A person can route whatever he wants. Presumably people will not generally waste their own bandwidth by routing what they believe to be unconfirmable. And whatever they would retain themselves is their presumption of confirmable.
This decision of what to retain one’s self is just a graph traversal to determine the most valuable subset - an optimizing CSP (though generally suboptimal due to the time constraint).
Short of DoS, the most profitable model is to retain *all* valid transactions. [Note that a spend conflict is not an invalidity. Two valid transactions can be confirmed in sibling branch blocks - both valid in some context.]
So the only consideration is low cost storage fill. The fee is a proof of spend, which like proof of work (for headers/blocks), is the basis of DoS protection (for unconfirmed transactions). The issue with two conflicting subgraphs is that one or the other is ultimately unspendable. As such the fee on each is non-cumulative and therefore only one (the highest) is providing DoS protection. Any subsequent conflicting subgraph must pay not only for itself, but for all preceding conflicting subgraphs.
This pays for the storage, which is a trade accepted by the owner of the node in order to have a preview of confirmable transactions. This supports both mining generation of candidate blocks and rapid validation/confirmation of blocks.
It’s a rather straightforward system when considered in terms of how it actually works (ie from a consensus standpoint). The only p2p issue is the need to package transactions for consideration as a set, as otherwise parents may be discarded before children can pay for them. Any set up to a full block is entirely reasonable for consideration.
e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/db23f327/attachment.html>

2023-06-07 23:03:07

- reply

📅 Original date posted:2022-01-31
📝 Original message:> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
…
> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on.
What flag?
>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>> accept replacement transactions which would decrease fee profits
>> of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
>
> There are two different common regimes which result in different incentivized behavior. One of them is that there's more than a block's backlog in the mempool in which case between two conflicting transactions the one with the higher fee rate should win. In the other case where there isn't a whole block's worth of transactions the one with higher total value should win.
These are not distinct scenarios. The rational choice is the highest fee block-valid subgraph of the set of unconfirmed transactions, in both cases (within the limits of what is computationally feasible of course).
When collecting pooled txs the only issue is DoS protection, which is simply a question of what any given miner is willing to pay, in terms of disk space, to archive conflicts for the opportunity to optimize block reward.
> It would be nice to have consolidated logic which handles both, it seems the issue has to do with the slope of the supply/demand curve which in the first case is gentle enough to keep the one transaction from hitting the rate but in the second one is basically infinite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220131/1aafa200/attachment.html>

2023-06-07 22:58:28

- reply

📅 Original date posted:2021-09-06
📝 Original message:Switching pools has always been possible. But the largest pool is the most profitable, and centralized pools are easily controlled. Decoupling selection without decoupling payout is an engineering change without a pooling pressure change.
e
> On Sep 6, 2021, at 10:01, David A. Harding <dave at dtrt.org> wrote:
>
> On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote:
>> It doesn’t centralize payment, which ultimately controls transaction selection (censorship).
>
> Yeah, but if you get paid after each share via LN and you can switch
> pools instantly, then the worst case with centralized pools is that
> you don't get paid for one share. If the hasher sets their share
> difficulty low enough, that shouldn't be a big deal.
>
> I'm interested in whether braidpool offers any significant benefits over
> an idealized version of centralized mining with independent transaction
> selection.
>
> -Dave

2023-06-07 22:58:28

- reply

📅 Original date posted:2021-09-06
📝 Original message:It doesn’t centralize payment, which ultimately controls transaction selection (censorship).
e
> On Sep 6, 2021, at 08:25, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote:
>> How would you compare this to Stratum v2?
>
> Specifically, I'd be interested in learning what advantages this has
> over a centralized mining pool using BetterHash or StratumV2 with
> payouts made via LN (perhaps immediately after each submitted share is
> validated).
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:56:46

- reply

📅 Original date posted:2021-07-09
📝 Original message:>> You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>You're using terms in non-standard ways. Putting money into a bank is not considered "lending" to the bank.
What people consider is irrelevant, all that matters is what is correct. A bank account as you are referring to it is indistinguishable from a money market (investment) fund in all aspects but federal reserve membership and regulatory controls. Interest (and offset expenses) derives directly from their earnings on this *investment*. Describing it otherwise is either an error (leading to false conclusions) or a lie.
> You may make a case that you're lending to a bank, and that they legally owe you repayment of that money on demand limited by the terms you mentioned. But regardless of a case that can be made there, pretty much no one considers that "lending". Since you you like defining things legally, depositing money in a bank is legally not defined as lending to the bank.
Please don’t bother to try and use statue as if it was at all relevant regarding economic concepts.
> So no, all other scenarios do not imply lending. You can have your coins in custody with someone else, and that someone else can keep 100% reserves if they choose (or agreed to) and can prove it to you via the method I described or the methods others have linked to.
That’s what Rothbard calls a “warehouse” - in order to distinguish it from investment. I’ve already made this distinction. Easier to prove with your own wallet, as I said. You are conflating this with banking, which should be obvious.
>> They are time deposits, read your bank agreement.
> You are https://www.investopedia.com/terms/t/timedeposit.asp#:~:text=A%20time%20deposit%20is%20an,pre%2Dset%20date%20of%20maturity.&text=Time%20deposits%20generally%20pay%20a,of%20investment%20is%20term%20deposit.. https://www.slsp.sk/en/personal/faq/what-is-the-difference-between-a-term-deposit-and-savings-account if you don't believe me. The only way you would be correct is if banks were committing fraud and calling something a "savings account" when it isn't in fact a savings account.
No, I am not wrong. It's not a question of believing you, it's a question of understanding the concepts. You will find this language in your deposit agreement (as required by statute):
"9. Our right to require advance notice of withdrawals
For all savings accounts and all personal interest-bearing checking accounts, we reserve the right to require seven days’ prior written notice of withdrawal."
https://www.chase.com/content/dam/chasecom/en/checking/documents/deposit_account_agreement.pdf
"When a man deposits goods at a warehouse, he is given a receipt and pays the owner of the warehouse a certain sum for the service of storage. He still retains ownership of the property; the owner of the warehouse is simply guarding it for him. When the warehouse receipt is presented, the owner is obligated to restore the good deposited. A warehouse specializing in money is known as a "bank.""
- Rothbard
As you can see, he is not talking about what you are talking about when it comes to colloquial use of the term "bank", he is clear to define what he means by "bank".
"Someone else's property is taken by the warehouse and used for its own money-making purposes. It is not borrowed, since no interest is paid for the use of the money."
- Rothbard
Any expectation of interest implies *borrowing*, in other words, a *loan* to the bank.
"Whether saved capital is channeled into investments via stocks or via loans is unimportant. The only difference is in the legal technicalities. Indeed, even the legal difference between the creditor and the owner is a negligible one."
- Rothbard
> You're using terms in non-standard ways. Putting money into a bank is not considered "lending" to the bank.
I think it's quite clear that Rothbard considers it lending. I'm not big on appeal to authority, but sometimes it helps open minds. Links here:
https://github.com/libbitcoin/libbitcoin-system/wiki/Full-Reserve-Fallacy
>> money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> Lol, money markets are so new that they've had no opportunity to show their true risk.
1971, 50 years.
https://en.wikipedia.org/wiki/Money_market_fund
> In the finance world, things work fine for a long time until they fail spectacularly, losing more than the gain they made in the first place. This is a regular occurence. Its the reason bitcoin was created.
regular occurrence...
"Buck breaking has rarely happened. Up to the 2008 financial crisis, only three money funds had broken the buck in the 37-year history of money funds... The first money market mutual fund to break the buck was First Multifund for Daily Income (FMDI) in 1978, liquidating and restating NAV at 94 cents per share"
An investment loss of 6%.
"The Community Bankers US Government Fund broke the buck in 1994, paying investors 96 cents per share."
An investment loss of 4%.
"This was only the second failure in the then 23-year history of money funds and there were no further failures for 14 years... No further failures occurred until September 2008, a month that saw tumultuous events for money funds."
It was a "tumultuous" month for nearly all investments. The feds of course doled out the pork, and the funds had to take it (as if their competition did and they didn't they would fail due to higher relative capital costs and thereby lower rates). In the past, absent pork, they had raised money where necessary to maintain their NAV (just as banks do, but they go to the taxpayer, and just as all business do from time to time).
These are remarkably stable in terms of NAV. And people seem to be satisfied with them:
"At the end of 2011, there were 632 money market funds in operation,[19] with total assets of nearly US$2.7 trillion.[19] Of this $2.7 trillion, retail money market funds had $940 billion in Assets Under Management (AUM). Institutional funds had $1.75 trillion under management.[19]"
The point being, that this is as close to free market bank-based investing as exists in the white market. In a money market fund, the NAV is reflected in the share price, so any losses are evenly distributed - no different than when all those HODLers take a hit when Elon farts, and the reserve they maintain has been very effective in maintaining their $1/share *target* despite paying *interest* on *investments*. They are merely shifting market returns into interest, just like banks. Market returns over short periods aren't always positive. No surprise. The larger point being, BANKS ARE INVESTMENT FUNDS.
>> Irrelevant.
> It is certainly not irrelevant. People have been lead to believe that they can withdraw their money from their accounts. People expect this.
Irrelevant, people have minds and free will and can read the contracts they are actually signing. Contracts are the *actual* Law associated with non-aggression.
> Banks are doing nothing to educate people on the limitations of that fact.
Again, irrelevant. And wholly unnecessary given compulsory taxpayer deposit insurance.
> PoR would give people the ability to see quite accurately how much reserves there are and can use this knowledge to put pressure on institutions to keep the reserves those people think they should keep.
For all of the reasons I've stated, it's a fairly pointless exercise, but people can do what they want. But if they are doing this with a deeply flawed understanding of banking to start with, they will be disappointed in the outcome.
>> Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”.
> You can show proof that you're 80% solvent, and then claim the other 20% is in other assets. This is, again, still useful.
80% solvent ... 50% pregnant.
>>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve
> You're right, but that's irrelevant.
I'll leave that to the reader. The alternative is to use your own wallet.
> But it seems like you're not interested in understanding what I'm saying or discussing these things honestly.
I'm not interested in allowing flawed concepts to be perpetuated without question. This is just a drain on capital that could be put to much better use. How many times have I heard the oxymoron "full reserve banking", and how much capital has been burned on this futile exercise, simply due to a failure to understand these concepts.
> So I'm going to end my conversation with you here.
While seemingly off-topic, these are things that need to be aired in this community. Thanks for the discourse.
e
On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev <mailto:bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Jul 9, 2021, at 10:44, Billy Tetrud <mailto:billy.tetrud at gmail.com> wrote:
>
> > there is an unsupportable leap being made here
>
> You think that because you're misinterpreting me. I'm in no way claiming that any solvent company can prove it, I'm simply claiming that any company can prove that they have bitcoin reserves to cover bitcoins promised as account balances.
You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
> > Banks (lending institutions) do not operate under any such pretense
>
> You seem to be saying that banks are under no legal obligation to serve cash on demand to customers. While you might be right,
I am, as banks are lending institutions.
> again you're misinterpreting me. Banks do in fact make claims to their customers that they'll be able to get cash out of their account on demand.
Up to the insured limit, in 7 days. This is of course true because the taxpayer has insured the bank to that level.
> They're called demand deposit accounts for a reason.
They are time deposits, read your bank agreement. Not that it makes any difference. How the contract is satisfied is not a term of the contract, just that it is. And as I pointed out, money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> And certainly customers expect to be able to withdraw their cash on demand.
Irrelevant.
> > With a 100% of investment cash hoard, there is zero lending and zero return
>
> I did say "pretend" did I not?
See above.
> > “relate to” is a far cry from 100% “reserve”
>
> Indeed. Again, you seem to be misunderstanding me. You're putting the words "100% reserve" in my mouth, when I never said any such thing. Proof of 80%/50%/20% reserves is still useful if that's the clear expectation for the customer/client.
Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”. And even with that, investors would have to accept the promise that there are no other liabilities.
The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve.
It’s information, sure, but it’s not what people seem to think. If one wants full reserve banking, use a wallet. If one wants to invest, the money will be spent - that’s why it was raised. There can be no covenant placed on it that will ensure it’s return.
e
_______________________________________________
bitcoin-dev mailing list
mailto:bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:56:45

- reply

📅 Original date posted:2021-07-09
📝 Original message:> On Jul 9, 2021, at 10:44, Billy Tetrud <billy.tetrud at gmail.com> wrote:
>
> > there is an unsupportable leap being made here
>
> You think that because you're misinterpreting me. I'm in no way claiming that any solvent company can prove it, I'm simply claiming that any company can prove that they have bitcoin reserves to cover bitcoins promised as account balances.
You can prove that in your own wallet. All other scenarios imply lending (which is what is implied by “reserve”) and lending cannot be 100% reserve.
> > Banks (lending institutions) do not operate under any such pretense
>
> You seem to be saying that banks are under no legal obligation to serve cash on demand to customers. While you might be right,
I am, as banks are lending institutions.
> again you're misinterpreting me. Banks do in fact make claims to their customers that they'll be able to get cash out of their account on demand.
Up to the insured limit, in 7 days. This is of course true because the taxpayer has insured the bank to that level.
> They're called demand deposit accounts for a reason.
They are time deposits, read your bank agreement. Not that it makes any difference. How the contract is satisfied is not a term of the contract, just that it is. And as I pointed out, money markets have had no reserve requirement and have a nearly spotless record of satisfying their obligations.
> And certainly customers expect to be able to withdraw their cash on demand.
Irrelevant.
> > With a 100% of investment cash hoard, there is zero lending and zero return
>
> I did say "pretend" did I not?
See above.
> > “relate to” is a far cry from 100% “reserve”
>
> Indeed. Again, you seem to be misunderstanding me. You're putting the words "100% reserve" in my mouth, when I never said any such thing. Proof of 80%/50%/20% reserves is still useful if that's the clear expectation for the customer/client.
Without 100% “reserve” there is no way to cryptographically demonstrate “solvency”. And even with that, investors would have to accept the promise that there are no other liabilities.
The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state seizure, no matter what the reserve.
It’s information, sure, but it’s not what people seem to think. If one wants full reserve banking, use a wallet. If one wants to invest, the money will be spent - that’s why it was raised. There can be no covenant placed on it that will ensure it’s return.
e

2023-06-07 22:56:44

- reply

📅 Original date posted:2021-07-09
📝 Original message:> On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> But people can certainly pull their money out of companies that can't show solvency.
As I pointed out previously there is an unsupportable leap being made here between a vault (money warehouse) and any company (including a bank).
A company cannot possibly show that it has all of the money that every person has invested into it. At times a solvent company may even have zero cash. It is also not possible for a company provide cryptographic proof of its many necessarily non-crypto assets and liabilities. What is presumed here is a community-verified sort of crypto balance sheet, with no considerations of risk - a central aspect of business.
As I said, if you want a vault, you can just use your own wallet. Solvency does not in any way imply 100% cash balance of the amounts invested. Raising money under such terms is pointless for both company and investors (the owners of the company).
> > Nonsense, any business can fail, regardless of temporal cash reserves.
>
> I agree that any business can fail. But a bank that pretends it can serve cash on demand is not a normal business,
Banks (lending institutions) do not operate under any such pretense. US banks require 7 day time deposits for all interest bearing accounts (read your depositor agreement), and it should be clear that your uninsured balance is at risk. Banks are investment funds, not money warehouses (in Rothbard’s terminology).
With a 100% of investment cash hoard, there is zero lending and zero return. This is true for all business.
> and cash reserves absolutely relate to their ability to survive as a bank.
“relate to” is a far cry from 100% “reserve”. At 100% reserve an investment fund would most certainly fail. At 20% it would fail. Money markets (banks without a reserve requirement) don’t break the buck, compete effectively with banks with reserve requirements (required by the taxpayer who is insuring deposits and providing discount credit), and maintain around 10% reserve. This is consistent with a world of people with time preference that creates around a 10% interest rate (return on investment).
> Its honestly confusing to me how you could think otherwise.
It’s confusing to me how anyone would put money into a business and expect (even want) it to sit there.
> Also, calling my thoughts "nonsense" is rude, please check yourself, Eric.
Check myself? Nonsense is English for “doesn’t make sense”. It’s not an insult.
e

2023-06-07 22:56:41

- reply

📅 Original date posted:2021-07-06
📝 Original message:> @Eric
> Auditability Fallacy
>
> > A solvency audit requires simultaneous (atomic) proof of both the full amount of the asset held by a custodian and the securities issued against it.
>
> > in the case where the security is issued on a distinct public chain the atomicity requirement is not satisfied.
>
> I think what its saying is that you can't get atomicity of both the security and the reserve. While this is true, what you can get is a system where the order of events can be established to a degree of precision. Ie, you can know that between reserve-snapshot A and B, the balances add up to X. Each user can validate that their balance was indeed that value between A and B. With reserve snapshots and balance snapshots frequent enough, this can allow reasonably high accuracy of estimated solvency. However, it does seem clear that perfect accuracy is not possible.
If perfect is not possible, it’s not possible. It reduces to trust, which is the status quo.
All “users” need to simultaneously share their individual and temporary audits with each other (ie publicly).
> > Historically it has not been difficult to detect such deviations. The difficulty arises in stopping them.
>
> I disagree here that it has not been difficult to detect deviations (insolvency).
It is not hard to spot price inflation. Stopping or avoiding it is the actual issue. No “proof” of reserve can do this. The federal reserve was clearly insolvent from its early days, as that was its purpose.
> I mean, "difficulty" isn't the right word. These things always become clear eventually. But I think its important to detect insolvency quickly. Historically insolvency has certainly not been detected quickly. Insolvency is instead practically perpetual, and the question is only how insolvent and when will it explode?
There is no “proof” that answers this question.
> I'm of the opinion that you can't prevent insolvency.
It’s not a matter of opinion. Lending implies risk. When you invest you are in fact the owner of the insolvency, not someone else.
> Places will have money troubles and will try to cover it up, since usually there is no downside (admitting insolvency can lead to bankrupcy, and failure to conceal insolvency has the same result - so why not try to conceal it and hope you can shore it up). However, its important that people know the institutions they have their money in are insolvent, or to what degree they are. If that information were well tracked, it could become clear over time that a 10% insolvent company rarely goes out of business, but a 20% insolvent company usually does.
Nonsense, any business can fail, regardless of temporal cash reserves.
> Then people can have parameters where they're ok with a certain measurable degree of insolvency, but react swiftly and strongly when a company is too reckless. Currently the amount of recklessness any given company engages in is basically a company secret that their clients don't have insight into. PoR would greatly help this I think. You don't think so?
Reckless is a subjective term. Proofs will not insure any investment.
e
>> On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil <eric at voskuil.org> wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>>
>>>> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>>>
>>> Good morning Billy,
>>>
>>>
>>>>
>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns
>>>>
>>>> Sure, but even if both participants in the channel sign a correct statement of truth, one of the participants can send funds out in the next second, invalidating that truth. While proof of ownership of on-chain UTXOs can be seen publicly in real time if they are spent, LN transactions aren't public like that. So any balance attestation is at best only valid the instant its taken, and can't be used as verification the money is still owned by the same channel partner in the next second.
>>>
>>> The same problem really also exists onchain --- a thief (or "thief") who has gotten a copy of the key can sign a transaction that spends it, one second after the proof-of-reserves is made.
>>>
>>> Really, though, the issue is that ownership of funds is conditional on *knowledge* of keys.
>>> And *knowledge* is easily copyable.
>>>
>>> Thus, it is possible that the funds that are "proven" to be the reserve of a custodian is actually *also* owned by someone else who has gotten to the privkeys (e.g. somebody threw a copy of it from a boating accident and a fearless scuba diver rescued it), and thus can also move the funds outside of the control of the custodian.
>>> This condition can remain for many months or years, as well, without knowledge of the custodian clients, *or* of the custodian itself.
>>>
>>> There is no way to prove that there is no alternate copy of the privkeys, hence "if only one could prove that he won't get into a boating accident".
>>>
>>> On the other hand, one could argue that at least the onchain proof requires more conditions to occur, so we might plausibly live with "we cannot prove we will never get into a boating accident but we can show evidence that we live in a landlocked city far from any lakes, seas, or rivers".
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>>
>>>>> a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels
>>>>
>>>> That would be a neat trick. But yeah, I don't know how that would be possible.
>>>>
>>>>> I believe it is one reason why custodian proof-of-reserves is not that popular ... it does not prove that the key will not get lost
>>>>
>>>> True, but at least if funds do get lost, it would be come clear far quicker. Today, an insolvent company could go many months without the public finding out.
>>>>
>>>>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>>>>
>>>>> Good morning e,
>>>>>
>>>>>> If only one could prove that he won’t get into a boating accident.
>>>>>
>>>>> At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
>>>>> If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
>>>>>
>>>>> On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
>>>>> I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
>>>>>
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>
>>>>>>
>>>>>> e
>>>>>>
>>>>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>>>>> Good morning Billy,
>>>>>>>
>>>>>>>> I wonder if there would be some way to include the ability to prove balances held on the lightning network, but I suspect that isn't generally possible.
>>>>>>>
>>>>>>> Thinking about this in terms of economic logic:
>>>>>>> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>>>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
>>>>>>> One of the participants should provably be the custodian.
>>>>>>>
>>>>>>> - If the counterparty is a true third party, it has no incentive to lie about its money.
>>>>>>> - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
>>>>>>> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
>>>>>>> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
>>>>>>>
>>>>>>> - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>>>>>>>
>>>>>>> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
>>>>>>> Regards,
>>>>>>> ZmnSCPxj
>>>>>>>
>>>>>>> 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/20210706/fdd3ae32/attachment-0001.html>

2023-06-07 22:56:38

- reply

📅 Original date posted:2021-07-06
📝 Original message:https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
> On Jul 5, 2021, at 21:54, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Billy,
>
>
>>
>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns
>>
>> Sure, but even if both participants in the channel sign a correct statement of truth, one of the participants can send funds out in the next second, invalidating that truth. While proof of ownership of on-chain UTXOs can be seen publicly in real time if they are spent, LN transactions aren't public like that. So any balance attestation is at best only valid the instant its taken, and can't be used as verification the money is still owned by the same channel partner in the next second.
>
> The same problem really also exists onchain --- a thief (or "thief") who has gotten a copy of the key can sign a transaction that spends it, one second after the proof-of-reserves is made.
>
> Really, though, the issue is that ownership of funds is conditional on *knowledge* of keys.
> And *knowledge* is easily copyable.
>
> Thus, it is possible that the funds that are "proven" to be the reserve of a custodian is actually *also* owned by someone else who has gotten to the privkeys (e.g. somebody threw a copy of it from a boating accident and a fearless scuba diver rescued it), and thus can also move the funds outside of the control of the custodian.
> This condition can remain for many months or years, as well, without knowledge of the custodian clients, *or* of the custodian itself.
>
> There is no way to prove that there is no alternate copy of the privkeys, hence "if only one could prove that he won't get into a boating accident".
>
> On the other hand, one could argue that at least the onchain proof requires more conditions to occur, so we might plausibly live with "we cannot prove we will never get into a boating accident but we can show evidence that we live in a landlocked city far from any lakes, seas, or rivers".
>
> Regards,
> ZmnSCPxj
>
>>
>>> a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels
>>
>> That would be a neat trick. But yeah, I don't know how that would be possible.
>>
>>> I believe it is one reason why custodian proof-of-reserves is not that popular ... it does not prove that the key will not get lost
>>
>> True, but at least if funds do get lost, it would be come clear far quicker. Today, an insolvent company could go many months without the public finding out.
>>
>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>>> Good morning e,
>>>
>>>> If only one could prove that he won’t get into a boating accident.
>>>
>>> At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive to unilaterally close the channel, which reveals the exact amounts (though not necessarily who owns which).
>>> If the other party then uses its funds in a new proof-of-reserves, then obviously the other output of the unilateral close was the one lost in the boating accident.
>>>
>>> On the other hand, yes, custodians losing custodied funds in boating accidents is much too common.
>>> I believe it is one reason why custodian proof-of-reserves is not that popular --- it only proves that the funds were owned under a particular key at some snapshot of the past, it does not prove that the key will not get lost (or "lost and then salvaged by a scuba diver") later.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>>
>>>> e
>>>>
>>>>> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>>> Good morning Billy,
>>>>>
>>>>>> I wonder if there would be some way to include the ability to prove balances held on the lightning network, but I suspect that isn't generally possible.
>>>>>
>>>>> Thinking about this in terms of economic logic:
>>>>> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>>>>> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
>>>>> One of the participants should provably be the custodian.
>>>>>
>>>>> - If the counterparty is a true third party, it has no incentive to lie about its money.
>>>>> - Especially if the counterparty is another custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
>>>>> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
>>>>> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
>>>>>
>>>>> - If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>>>>>
>>>>> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of all channels.
>>>>> Regards,
>>>>> ZmnSCPxj
>>>>>
>>>>> 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/20210705/60070878/attachment-0001.html>

2023-06-07 22:56:37

- reply

📅 Original date posted:2021-07-05
📝 Original message:If only one could prove that he won’t get into a boating accident.
e
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Billy,
>
>> I wonder if there would be some way to include the ability to prove balances held on the lightning network, but I suspect that isn't generally possible.
>
> Thinking about this in terms of economic logic:
>
> Every channel is anchored onchain, and that anchor (the funding txout) is proof of the existence, and size, of the channel.
>
> The two participants in the channel can sign a plaintext containing their node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
>
> * If the counterparty is a true third party, it has no incentive to lie about its money.
> * Especially if the counterparty is *another* custodian who wants proof-of-reserves, it has every incentive to overreport, but then the first party will refuse to sign.
> It has a disincentive to underreport, and would itself refuse to sign a dishonest report that assigns more funds to the first party.
> The only case that would be acceptable to both custodians would be to honestly report their holdings in the Lightning channel.
> * If the counterparty is a sockpuppet of the custodian, then the entire channel is owned by the custodian and it would be fairly dumb of he custodian to claim to have less funds than the entire channel.
>
> Perhaps a more practical problem is that Lightning channel states change fairly quickly, and there are possible race conditions, due to network latency (remember, both nodes need to sign, meaning both of them need to communicate with each other, thus hit by network latency and other race conditions) where a custodian Lightning node is unable to "freeze" a snapshot of its current state and make an atomic proof-of-reserves of *all* channels.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:55:44

- reply

📅 Original date posted:2021-06-30
📝 Original message:> On Jun 30, 2021, at 05:45, Zac Greenwood <zachgrw at gmail.com> wrote:
>
>
> Eric,
>
> > A million nodes saying a transaction is invalid does nothing to enforce that knowledge
>
> It does. Nodes disregard invalid transactions and invalid blocks as if they never existed. It is not possible for any party to transact bitcoin in a way that violates the set of rules enforced by the network of consensus-compatible nodes that we call Bitcoin.
When Fincen walks into Coinbase and every other exchange (and white market business in the country), and tells them to change a rule or they are taking the CEO out in hancuffs for money laundering, I’m pretty sure that their node with not be able to prevent it.
Enforcement is always people. We use the term node as a metaphorical term for people who use the node to avoid taking bad money. Like those machines that test paper money, they offer no resistance themselves.
A node in a closet checking transactions, unconnected to any human actually rejecting the money in trade, offers no resistance to anything. It can be forked off without any consequence whatsoever.
This subject was discussed here during the BCH split. People were setting up nodes on cloud services, to boost numbers. These non-economic nodes were of course of no consequence, which was not a matter of debate. I’m explaining to you why that is.
The network ignores non-economic nodes as if they never existed.
> Zac
>
>
>> On Wed, Jun 30, 2021 at 2:03 PM Eric Voskuil <eric at voskuil.org> wrote:
>> A million nodes saying a transaction is invalid does nothing to enforce that knowledge.
>>
>> An economic node is a person who refuses to accept invalid money. A node only informs this decision, it cannot enforce it. That’s up to people.
>>
>> And clearly if one is not actually accepting bitcoin for anything at the time, he is not enforcing anything.
>>
>> The idea of a non-economic node is well established, nothing new here.
>>
>> e
>>
>>>> On Jun 30, 2021, at 04:33, Zac Greenwood <zachgrw at gmail.com> wrote:
>>>>
>>>
>>> Hi Eric,
>>>
>>> > A node (software) doesn’t enforce anything. Merchants enforce consensus rules
>>>
>>> … by running a node which they believe to enforce the rules of Bitcoin.
>>>
>>> A node definitely enforces consensus rules and defines what is Bitcoin. I am quite disturbed that this is even being debated here.
>>>
>>> Zac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/9f52caa5/attachment.html>

2023-06-07 22:55:43

- reply

📅 Original date posted:2021-06-30
📝 Original message:A million nodes saying a transaction is invalid does nothing to enforce that knowledge.
An economic node is a person who refuses to accept invalid money. A node only informs this decision, it cannot enforce it. That’s up to people.
And clearly if one is not actually accepting bitcoin for anything at the time, he is not enforcing anything.
The idea of a non-economic node is well established, nothing new here.
e
> On Jun 30, 2021, at 04:33, Zac Greenwood <zachgrw at gmail.com> wrote:
>
>
> Hi Eric,
>
> > A node (software) doesn’t enforce anything. Merchants enforce consensus rules
>
> … by running a node which they believe to enforce the rules of Bitcoin.
>
> A node definitely enforces consensus rules and defines what is Bitcoin. I am quite disturbed that this is even being debated here.
>
> Zac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/c2d70213/attachment.html>

2023-06-07 22:55:34

- reply

📅 Original date posted:2021-06-29
📝 Original message:> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> "Confirmation" isn't needed for softforks.
All transactions require confirmation. Splitting does not change this.
Softforks are not compatible without miner enforcement. So soft forking without it has essentially the same effect as hard forking, the chain splits.
> Miners controlling confirmation doesn't mean miners control the rules, they never did.
Please define “control” because these statements hinge on that word. Nobody “controls” the rules of others, nor did anyone claim that to be the case. Majority hash power does have the ability to determine what gets confirmed. That is the central design principle of proof of work. It takes that decision out of the hands of politicians and places it at the feet of the market.
> Read section 11 of the bitcoin paper "even with a majority of hashrate one cannot arbitrarily change rules or forge signatures.
Never claimed that was the case. One can run any rules that one desires.
> You may say users chosing the rules is "politicial". Isn't miners deciding them for users more political?
No, it’s economic. The largest investment in mining (including highest fees paid to incentivize it) determines censorship resistance.
> Whatever you call it, it is still how free software works: users decide what to run.
A *person* can run whatever software they want. Money requires that others agree (same rules), and to be money bitcoin requires confirmation.
> It is extremely disappointing to see how few developers seem to ubderstand this, or even care about users deciding or miners not deciding the rules.
It’s poorly understood because there are so many who should know better making very misleading statements.
> How can we expect users to understand bitcoin when most developers don't seem to understand it?
Clearly we cannot.
> It is really sad.
>
>> On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric at voskuil.org> wrote:
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1) concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> This is the nature of bitcoin. And merchants control validation, entirely. Anyone can be a miner or a merchant. Neither is inherently “better” than the other. The largest merchants are likely a handful of exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship resistance inherent to Bitcoin. Coordinating this split requires coordinated action. The whole point of bitcoin is coordinate that action based on mining (proof of work). Replacing that with a political process is just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s about how one gets others to go along with the new coin, or stay with the old. An entirely political process, which is clearly evident from the campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to concede,
>> > rather than passively continue the disagreement ongoing after the attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> >> At least we are now acknowledging that splitting is what it’s about. That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>
>> >>>
>> >>> I think the option of "permanent failure because miners veto" should
>> >>> actually be abandoned. No, I don't think we should avoid splits when
>> >>> possible, I don't think we should avoid splits at all costs.
>> >>>
>> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com> wrote:
>> >>>> @Luke
>> >>>>
>> >>>>> They can still slow it down.
>> >>>>
>> >>>> Absolutely. However I think that the option of permanent failure is
>> >>>> important. It certainly would be ideal to ensure that enough bitcoin
>> >>>> users support the upgrade *before* releasing it, however realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released before
>> >>>> it becomes clear that a large supermajority of users want the upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done after
>> >>>> an initial failure to deploy occurs. My proposal is essentially a
>> >>>> mechanism to improve upon the speedy-trial idea, allowing for even
>> >>>> speedier releases (than speedy trial) without adding additional risk of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my proposal is
>> >>>> materially different - it is the signaling itself that is trinary, not
>> >>>> just which chain is being followed. This allows others to know and make
>> >>>> programmatic decisions (in software) based on that signaling. I'm sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out. Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful, but
>> >>>> there were a significant amount of users that disagreed, and they have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible. Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of users
>> >>>> wants which rules? We don't have a divining rod to determine with
>> >>>> certainty what users want. We can only make polls of various levels of
>> >>>> inaccuracy. The methods bitcoin has been using is community discussion
>> >>>> and social consensus estimation as well as miner signaling during the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade, and
>> >>>> why we need to have higher thresholds of success (require larger
>> >>>> supermajorities in both consensus and miner signaling).
>> >>>>
>> >>>> Developers obviously care about bitcoin and have an incentive (personal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to mine on
>> >>>> the chain that the economic majority of users is using. But measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily difficult
>> >>>> to do with consistent accuracy, and so I think miner signaling as it has
>> >>>> been used as a second barrier to entry for an upgrade is quite
>> >>>> appropriate.
>> >>>>
>> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org> wrote:
>> >>>>> I have not objected to anyone splitting. As I said, a split is always
>> >>>>> possible, and of course has been done on a large scale. It is only the
>> >>>>> misleading statements about inherent soft fork “compatibility” and the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” decide the rules is not the question. The
>> >>>>> question is only how to avoid a split. If one does not care he can
>> >>>>> split at any time, no discussion required.
>> >>>>>
>> >>>>> e
>> >>>>>
>> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people want.
>> >>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can mine,
>> >>>>>>> so everyone gets a say. Mining is trading capital now for more
>> >>>>>>> later. If enough people want to do that, they can enforce a soft
>> >>>>>>> fork. It’s time Bitcoiners stop thinking of miners as other people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside from
>> >>>>>>>>> their role as also being users). The miner involvement is only out
>> >>>>>>>>> of necessity (to set the bit in the header, which users coordinate
>> >>>>>>>>> with) and potentially to accelerate activation by protecting
>> >>>>>>>>> upgrade-lagging users.
>> >>>>>>>>>
>> >>>>>>>>> Luke
>> >>>>>>>>>
>> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blo
>> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades that
>> >>>>>>>>>> solve both problems.
>> >>>>>>>>>>
>> >>>>>>>>>> The proposal uses trinary version signaling rather than binary
>> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade, this
>> >>>>>>>>>> allows for three signaling states:
>> >>>>>>>>>>
>> >>>>>>>>>> * Actively support the change.
>> >>>>>>>>>> * Actively oppose the change.
>> >>>>>>>>>> * Not signaling (neither support or oppose). This is the default
>> >>>>>>>>>> state.
>> >>>>>>>>>>
>> >>>>>>>>>> Using this additional information, we can release non-contentious
>> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppose
>> >>>>>>>>>> the change are incentivized to update their software to a version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if they
>> >>>>>>>>>> actually oppose the change while at the same time allowing these
>> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork
>> >>>>>>>>>> activation much.
>> >>>>>>>>>>
>> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> 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/20210629/5c4c96b0/attachment-0001.html>

2023-06-07 22:55:32

- reply

📅 Original date posted:2021-06-29
📝 Original message:> On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> wrote:
>
> The only alternative to a split in the problematic scenarios are 1) concede
> centralised miner control over the network,
Miners control confirmation, entirely.
This is the nature of bitcoin. And merchants control validation, entirely. Anyone can be a miner or a merchant. Neither is inherently “better” than the other. The largest merchants are likely a handful of exchanges, likely at least as centralized as miners are pooled.
Splitting does not change this.
> and 2) have inconsistent
> enforcement of rules by users who don't agree on what the correct rules are,
There are no “correct” rules. Whatever rules one enforces determine what network he chooses to participate in.
> again leading to centralised miner control over the network.
Leading to? Miners control confirmation, always. Whether that is centralized, just as with merchanting, is up to individuals.
> In other words, in this context, accepting a split between disagreeing users
> is the ONLY way Bitcoin can possibly continue as a decentralised currency.
No, it is not. You are proposing splitting as the method of censorship resistance inherent to Bitcoin. Coordinating this split requires coordinated action. The whole point of bitcoin is coordinate that action based on mining (proof of work). Replacing that with a political process is just a reversion to political money.
> Making that split as clean and well-defined as possible not only ensures the
> best opportunity for both sides of the disagreement,
Trivially accomplished, just change a rule. This isn’t about that. It’s about how one gets others to go along with the new coin, or stay with the old. An entirely political process, which is clearly evident from the campaigns around such attempts.
> but also minimises the
> risk that the split occurs at all (since the "losing" side needs to concede,
> rather than passively continue the disagreement ongoing after the attempted
> protocol change).
Nobody “needs to” concede once a split has occurred, which is evident in existing splits.
e
> Luke
>
>
>> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> At least we are now acknowledging that splitting is what it’s about. That’s
>> progress.
>>
>> e
>>
>>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
>>>
>>>
>>> I think the option of "permanent failure because miners veto" should
>>> actually be abandoned. No, I don't think we should avoid splits when
>>> possible, I don't think we should avoid splits at all costs.
>>>
>>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com> wrote:
>>>> @Luke
>>>>
>>>>> They can still slow it down.
>>>>
>>>> Absolutely. However I think that the option of permanent failure is
>>>> important. It certainly would be ideal to ensure that enough bitcoin
>>>> users support the upgrade *before* releasing it, however realistically
>>>> this can never be more than an estimate, and estimates can sometimes be
>>>> wildly wrong. It would be unfortunate if miners had a substantially
>>>> different estimate of user support than the people putting in the work
>>>> to release bitcoin upgrades. Even if upgrades are never released before
>>>> it becomes clear that a large supermajority of users want the upgrade,
>>>> if miners don't agree with the estimate a harmful chain split could
>>>> occur. And I agree with Eric that the goal here is to prevent a chain
>>>> split during an upgrade when possible. This includes permanent failure
>>>> of an upgrade when there is unexpectedly large miner opposition.
>>>>
>>>> This of course does not prevent a UASF-style deployment to be done after
>>>> an initial failure to deploy occurs. My proposal is essentially a
>>>> mechanism to improve upon the speedy-trial idea, allowing for even
>>>> speedier releases (than speedy trial) without adding additional risk of
>>>> undesired chain splits.
>>>>
>>>>> [BIP8] already has the trinary state you seem to be describing
>>>>
>>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the
>>>> longest chain, B. Follow the upgrade chain, or C. follow the
>>>> non-upgraded chain. I agree. However the trinary state in my proposal is
>>>> materially different - it is the signaling itself that is trinary, not
>>>> just which chain is being followed. This allows others to know and make
>>>> programmatic decisions (in software) based on that signaling. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>>
>>>>> No additional bit is needed, as softforks are coordinated between
>>>>> users, NOT miners
>>>>
>>>> And yet there is miner involvement, as you rightly pointed out. Miners
>>>> are needed to set the nVersion in the header. So when you say "no
>>>> additional bit is needed", could you please be clearer as to what you
>>>> mean? Do you mean that signaling of opposition in a block can be done
>>>> without any "additional bit"? Or are you just saying that it is
>>>> redundant to consider what miners might be opposing an upgrade?
>>>>
>>>> @Jorge
>>>>
>>>>> If different users want different incompatible things... there's no
>>>>> way to avoid the split
>>>>
>>>> I agree. This happened with bcash, and that's fine. It was painful, but
>>>> there were a significant amount of users that disagreed, and they have
>>>> the chain they want now.
>>>>
>>>> But we generally all want to avoid a chain split when possible. Because
>>>> chain splits have a cost, and that cost can be high, its likely that
>>>> many users would rather choose the chain with the most support rather
>>>> than choosing the chain with their preferred rules.
>>>>
>>>> However, the question here is: how do we estimate what fraction of users
>>>> wants which rules? We don't have a divining rod to determine with
>>>> certainty what users want. We can only make polls of various levels of
>>>> inaccuracy. The methods bitcoin has been using is community discussion
>>>> and social consensus estimation as well as miner signaling during the
>>>> actual deployment period. Neither of these are perfect, but they are
>>>> both reasonable enough mechanisms. However, because both of these
>>>> mechanisms are very rough estimates of user sentiment, we need to
>>>> consider the possibility that sometimes the estimate may be
>>>> substantially inaccurate when we design deployment procedures. This
>>>> inaccuracy is why we need multiple barriers in place for an upgrade, and
>>>> why we need to have higher thresholds of success (require larger
>>>> supermajorities in both consensus and miner signaling).
>>>>
>>>> Developers obviously care about bitcoin and have an incentive (personal
>>>> and probably financial) to do it right. And miners have both an
>>>> incentive to keep the system healthy, as well as an incentive to mine on
>>>> the chain that the economic majority of users is using. But measuring
>>>> the consensus of the bitcoin community can be extraordinarily difficult
>>>> to do with consistent accuracy, and so I think miner signaling as it has
>>>> been used as a second barrier to entry for an upgrade is quite
>>>> appropriate.
>>>>
>>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org> wrote:
>>>>> I have not objected to anyone splitting. As I said, a split is always
>>>>> possible, and of course has been done on a large scale. It is only the
>>>>> misleading statements about inherent soft fork “compatibility” and the
>>>>> implication that activation without hash power enforcement does not
>>>>> create a split that I object to. People who know better should be
>>>>> honest about it.
>>>>>
>>>>> Far too many people have been led to believe there is some sort of
>>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>>>>> There is only a choice between creating a split and hash power
>>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>>>>> unless enforced by majority hash power.
>>>>>
>>>>> The statements below are grossly misleading and need to be called out
>>>>> as such so that people can actually make this decision you speak of.
>>>>> This idea that “users” decide the rules is not the question. The
>>>>> question is only how to avoid a split. If one does not care he can
>>>>> split at any time, no discussion required.
>>>>>
>>>>> e
>>>>>
>>>>>> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>>>>>>
>>>>>> If different users want different incompatible things (enough on
>>>>>> each side), there's no way to avoid the split. We shouldn't try to
>>>>>> avoid such a split.
>>>>>> Users decide the rules, not miners nor developers.
>>>>>>
>>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>
>>>>>>> Ultimately there is only one answer to this question. Get majority
>>>>>>> hash power support.
>>>>>>>
>>>>>>> Soft fork enforcement is the same act as any other censorship
>>>>>>> enforcement, the difference is only a question of what people want.
>>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
>>>>>>> resolves this question of conflicting wants, but it is not a
>>>>>>> democracy, it’s a market. One votes by trading.
>>>>>>>
>>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>>>>>>> accomplished by mining (or paying others to do so). Anyone can mine,
>>>>>>> so everyone gets a say. Mining is trading capital now for more
>>>>>>> later. If enough people want to do that, they can enforce a soft
>>>>>>> fork. It’s time Bitcoiners stop thinking of miners as other people.
>>>>>>> Anyone can mine, and that’s your vote.
>>>>>>>
>>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But it’s
>>>>>>> dishonest to imply that one can do this and all others will surely
>>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>>>>>>> that has been shown to not always pay off.
>>>>>>>
>>>>>>> e
>>>>>>>
>>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
>>>>>>>>
>>>>>>>> For some definitions of “block”.
>>>>>>>>
>>>>>>>> Without majority hash power support, activation simply means you
>>>>>>>> are off on a chain split. Anyone can of course split off from a
>>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>>>>>>>> is a bit of an empty claim.
>>>>>>>>
>>>>>>>> Nobody can stop a person from splitting. The relevant question is
>>>>>>>> how to *prevent* a split. And activation without majority hash
>>>>>>>> power certainly does not “ensure” this.
>>>>>>>>
>>>>>>>> e
>>>>>>>>
>>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>>>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>>>
>>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>>>>>>>>> entirely. They can still slow it down.
>>>>>>>>>
>>>>>>>>> It also already has the trinary state you seem to be describing
>>>>>>>>> (although perhaps this could be better documented in the BIP):
>>>>>>>>> users who oppose the softfork can and should treat the successful
>>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
>>>>>>>>> not follow a chain with the rules in force.
>>>>>>>>>
>>>>>>>>> No additional bit is needed, as softforks are coordinated between
>>>>>>>>> users, NOT miners (who have no particular say in them, aside from
>>>>>>>>> their role as also being users). The miner involvement is only out
>>>>>>>>> of necessity (to set the bit in the header, which users coordinate
>>>>>>>>> with) and potentially to accelerate activation by protecting
>>>>>>>>> upgrade-lagging users.
>>>>>>>>>
>>>>>>>>> Luke
>>>>>>>>>
>>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>>>>>>>>>> ways to solve the problems that both sides brought up. In short,
>>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners failing
>>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>>>>>>>>>> have created a proposal
>>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blo
>>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades that
>>>>>>>>>> solve both problems.
>>>>>>>>>>
>>>>>>>>>> The proposal uses trinary version signaling rather than binary
>>>>>>>>>> signaling. For any particular prospective soft fork upgrade, this
>>>>>>>>>> allows for three signaling states:
>>>>>>>>>>
>>>>>>>>>> * Actively support the change.
>>>>>>>>>> * Actively oppose the change.
>>>>>>>>>> * Not signaling (neither support or oppose). This is the default
>>>>>>>>>> state.
>>>>>>>>>>
>>>>>>>>>> Using this additional information, we can release non-contentious
>>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>>>>>>>>>> signaling support). For contentious upgrades, miners who oppose
>>>>>>>>>> the change are incentivized to update their software to a version
>>>>>>>>>> that can actively signal opposition to the change. The more
>>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>>>>>>>>>> the proposal, this chart shows how much support signaling would
>>>>>>>>>> be necessary given a particular amount of active opposition
>>>>>>>>>> signaling:
>>>>>>>>>>
>>>>>>>>>> [image: thresholdChart.png]
>>>>>>>>>> If literally no one signals opposition, a 60% threshold should be
>>>>>>>>>> relatively safe because it is a supermajority amount that is
>>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>>>>>>>>>> miners support the change today, its unlikely that less than a
>>>>>>>>>> majority of miners would support the change a year or two from
>>>>>>>>>> now), and if no one is signaling opposition, chances are that the
>>>>>>>>>> vast majority of the other 40% would also eventually signal
>>>>>>>>>> support.
>>>>>>>>>>
>>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if they
>>>>>>>>>> actually oppose the change while at the same time allowing these
>>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork
>>>>>>>>>> activation much.
>>>>>>>>>>
>>>>>>>>>> I think now is the right time to discuss new soft fork upgrade
>>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
>>>>>>>>>> this will only delay things and cause contention again like it
>>>>>>>>>> did with taproot.
>>>>>>>>>>
>>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>>>>>>>>>> would appreciate any comments here, or written as github issues
>>>>>>>>>> on the proposal repo itself.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> BT
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>

2023-06-07 22:55:30

- reply

📅 Original date posted:2021-06-29
📝 Original message:At least we are now acknowledging that splitting is what it’s about. That’s progress.
e
> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> I think the option of "permanent failure because miners veto" should actually be abandoned.
> No, I don't think we should avoid splits when possible, I don't think we should avoid splits at all costs.
>
>
>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com> wrote:
>> @Luke
>> > They can still slow it down.
>>
>> Absolutely. However I think that the option of permanent failure is important. It certainly would be ideal to ensure that enough bitcoin users support the upgrade *before* releasing it, however realistically this can never be more than an estimate, and estimates can sometimes be wildly wrong. It would be unfortunate if miners had a substantially different estimate of user support than the people putting in the work to release bitcoin upgrades. Even if upgrades are never released before it becomes clear that a large supermajority of users want the upgrade, if miners don't agree with the estimate a harmful chain split could occur. And I agree with Eric that the goal here is to prevent a chain split during an upgrade when possible. This includes permanent failure of an upgrade when there is unexpectedly large miner opposition.
>>
>> This of course does not prevent a UASF-style deployment to be done after an initial failure to deploy occurs. My proposal is essentially a mechanism to improve upon the speedy-trial idea, allowing for even speedier releases (than speedy trial) without adding additional risk of undesired chain splits.
>>
>> > [BIP8] already has the trinary state you seem to be describing
>>
>> It sounds like you're saying the trinary state of BIP8 is A. Follow the longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded chain. I agree. However the trinary state in my proposal is materially different - it is the signaling itself that is trinary, not just which chain is being followed. This allows others to know and make programmatic decisions (in software) based on that signaling. I'm sure you can agree that does not exist in BIP8.
>>
>> > No additional bit is needed, as softforks are coordinated between users, NOT miners
>>
>> And yet there is miner involvement, as you rightly pointed out. Miners are needed to set the nVersion in the header. So when you say "no additional bit is needed", could you please be clearer as to what you mean? Do you mean that signaling of opposition in a block can be done without any "additional bit"? Or are you just saying that it is redundant to consider what miners might be opposing an upgrade?
>>
>> @Jorge
>> > If different users want different incompatible things... there's no way to avoid the split
>>
>> I agree. This happened with bcash, and that's fine. It was painful, but there were a significant amount of users that disagreed, and they have the chain they want now.
>>
>> But we generally all want to avoid a chain split when possible. Because chain splits have a cost, and that cost can be high, its likely that many users would rather choose the chain with the most support rather than choosing the chain with their preferred rules.
>>
>> However, the question here is: how do we estimate what fraction of users wants which rules? We don't have a divining rod to determine with certainty what users want. We can only make polls of various levels of inaccuracy. The methods bitcoin has been using is community discussion and social consensus estimation as well as miner signaling during the actual deployment period. Neither of these are perfect, but they are both reasonable enough mechanisms. However, because both of these mechanisms are very rough estimates of user sentiment, we need to consider the possibility that sometimes the estimate may be substantially inaccurate when we design deployment procedures. This inaccuracy is why we need multiple barriers in place for an upgrade, and why we need to have higher thresholds of success (require larger supermajorities in both consensus and miner signaling).
>>
>> Developers obviously care about bitcoin and have an incentive (personal and probably financial) to do it right. And miners have both an incentive to keep the system healthy, as well as an incentive to mine on the chain that the economic majority of users is using. But measuring the consensus of the bitcoin community can be extraordinarily difficult to do with consistent accuracy, and so I think miner signaling as it has been used as a second barrier to entry for an upgrade is quite appropriate.
>>
>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org> wrote:
>>> I have not objected to anyone splitting. As I said, a split is always possible, and of course has been done on a large scale. It is only the misleading statements about inherent soft fork “compatibility” and the implication that activation without hash power enforcement does not create a split that I object to. People who know better should be honest about it.
>>>
>>> Far too many people have been led to believe there is some sort of activation choice with “ensured” equal outcomes (maybe “slowed down”). There is only a choice between creating a split and hash power enforcement. Soft forks are rule changes, and thereby incompatible - unless enforced by majority hash power.
>>>
>>> The statements below are grossly misleading and need to be called out as such so that people can actually make this decision you speak of. This idea that “users” decide the rules is not the question. The question is only how to avoid a split. If one does not care he can split at any time, no discussion required.
>>>
>>> e
>>>
>>> > On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>>> >
>>> > If different users want different incompatible things (enough on each
>>> > side), there's no way to avoid the split. We shouldn't try to avoid
>>> > such a split.
>>> > Users decide the rules, not miners nor developers.
>>> >
>>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>
>>> >> Ultimately there is only one answer to this question. Get majority hash power support.
>>> >>
>>> >> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>>> >>
>>> >> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>>> >>
>>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>>> >>
>>> >> e
>>> >>
>>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
>>> >>>
>>> >>> For some definitions of “block”.
>>> >>>
>>> >>> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>> >>>
>>> >>> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
>>> >>>
>>> >>> e
>>> >>>
>>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>>
>>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
>>> >>>> still slow it down.
>>> >>>>
>>> >>>> It also already has the trinary state you seem to be describing (although
>>> >>>> perhaps this could be better documented in the BIP): users who oppose the
>>> >>>> softfork can and should treat the successful signal (whether MASF or UASF) as
>>> >>>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>>> >>>>
>>> >>>> No additional bit is needed, as softforks are coordinated between users, NOT
>>> >>>> miners (who have no particular say in them, aside from their role as also
>>> >>>> being users). The miner involvement is only out of necessity (to set the bit
>>> >>>> in the header, which users coordinate with) and potentially to accelerate
>>> >>>> activation by protecting upgrade-lagging users.
>>> >>>>
>>> >>>> Luke
>>> >>>>
>>> >>>>
>>> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>>> >>>>> Given the recent controversy over upgrade mechanisms for the
>>> >>>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>> >>>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>> >>>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>> >>>>> proponents make the point that LOT=true can lead to undesirable forks that
>>> >>>>> might cause a lot of chaos. I believe both points are essentially correct
>>> >>>>> and have created a proposal
>>> >>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>> >>>>>
>>> >>>>> The proposal uses trinary version signaling rather than binary signaling.
>>> >>>>> For any particular prospective soft fork upgrade, this allows for three
>>> >>>>> signaling states:
>>> >>>>>
>>> >>>>> * Actively support the change.
>>> >>>>> * Actively oppose the change.
>>> >>>>> * Not signaling (neither support or oppose). This is the default state.
>>> >>>>>
>>> >>>>> Using this additional information, we can release non-contentious upgrades
>>> >>>>> much quicker (with a much lower percent of miners signaling support). For
>>> >>>>> contentious upgrades, miners who oppose the change are incentivized to
>>> >>>>> update their software to a version that can actively signal opposition to
>>> >>>>> the change. The more opposition there is, the higher the threshold
>>> >>>>> necessary to lock in the upgrade. With the parameters I currently
>>> >>>>> recommended in the proposal, this chart shows how much support signaling
>>> >>>>> would be necessary given a particular amount of active opposition
>>> >>>>> signaling:
>>> >>>>>
>>> >>>>> [image: thresholdChart.png]
>>> >>>>> If literally no one signals opposition, a 60% threshold should be
>>> >>>>> relatively safe because it is a supermajority amount that is unlikely to
>>> >>>>> change significantly very quickly (ie if 60% of miners support the change
>>> >>>>> today, its unlikely that less than a majority of miners would support the
>>> >>>>> change a year or two from now), and if no one is signaling opposition,
>>> >>>>> chances are that the vast majority of the other 40% would also eventually
>>> >>>>> signal support.
>>> >>>>>
>>> >>>>> This both gives an incentive for "lazy" miners to upgrade if they actually
>>> >>>>> oppose the change while at the same time allowing these lazy miners to
>>> >>>>> remain lazy without slowing down the soft fork activation much.
>>> >>>>>
>>> >>>>> I think now is the right time to discuss new soft fork upgrade mechanisms,
>>> >>>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>> >>>>> until we need to deploy a soft fork to discuss this will only delay things
>>> >>>>> and cause contention again like it did with taproot.
>>> >>>>>
>>> >>>>> I'm very curious to know what people think of this mechanism. I would
>>> >>>>> appreciate any comments here, or written as github issues on the proposal
>>> >>>>> repo itself.
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>> BT
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> 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/20210629/dfc06d8f/attachment-0001.html>

2023-06-07 22:55:26

- reply

📅 Original date posted:2021-06-27
📝 Original message:I have not objected to anyone splitting. As I said, a split is always possible, and of course has been done on a large scale. It is only the misleading statements about inherent soft fork “compatibility” and the implication that activation without hash power enforcement does not create a split that I object to. People who know better should be honest about it.
Far too many people have been led to believe there is some sort of activation choice with “ensured” equal outcomes (maybe “slowed down”). There is only a choice between creating a split and hash power enforcement. Soft forks are rule changes, and thereby incompatible - unless enforced by majority hash power.
The statements below are grossly misleading and need to be called out as such so that people can actually make this decision you speak of. This idea that “users” decide the rules is not the question. The question is only how to avoid a split. If one does not care he can split at any time, no discussion required.
e
> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> If different users want different incompatible things (enough on each
> side), there's no way to avoid the split. We shouldn't try to avoid
> such a split.
> Users decide the rules, not miners nor developers.
>
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Ultimately there is only one answer to this question. Get majority hash power support.
>>
>> Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>>
>> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
>>
>> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>>
>> e
>>
>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
>>>
>>> For some definitions of “block”.
>>>
>>> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>>
>>> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
>>>
>>> e
>>>
>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
>>>> still slow it down.
>>>>
>>>> It also already has the trinary state you seem to be describing (although
>>>> perhaps this could be better documented in the BIP): users who oppose the
>>>> softfork can and should treat the successful signal (whether MASF or UASF) as
>>>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>>>>
>>>> No additional bit is needed, as softforks are coordinated between users, NOT
>>>> miners (who have no particular say in them, aside from their role as also
>>>> being users). The miner involvement is only out of necessity (to set the bit
>>>> in the header, which users coordinate with) and potentially to accelerate
>>>> activation by protecting upgrade-lagging users.
>>>>
>>>> Luke
>>>>
>>>>
>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>>>> proponents make the point that LOT=true can lead to undesirable forks that
>>>>> might cause a lot of chaos. I believe both points are essentially correct
>>>>> and have created a proposal
>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>>>>
>>>>> The proposal uses trinary version signaling rather than binary signaling.
>>>>> For any particular prospective soft fork upgrade, this allows for three
>>>>> signaling states:
>>>>>
>>>>> * Actively support the change.
>>>>> * Actively oppose the change.
>>>>> * Not signaling (neither support or oppose). This is the default state.
>>>>>
>>>>> Using this additional information, we can release non-contentious upgrades
>>>>> much quicker (with a much lower percent of miners signaling support). For
>>>>> contentious upgrades, miners who oppose the change are incentivized to
>>>>> update their software to a version that can actively signal opposition to
>>>>> the change. The more opposition there is, the higher the threshold
>>>>> necessary to lock in the upgrade. With the parameters I currently
>>>>> recommended in the proposal, this chart shows how much support signaling
>>>>> would be necessary given a particular amount of active opposition
>>>>> signaling:
>>>>>
>>>>> [image: thresholdChart.png]
>>>>> If literally no one signals opposition, a 60% threshold should be
>>>>> relatively safe because it is a supermajority amount that is unlikely to
>>>>> change significantly very quickly (ie if 60% of miners support the change
>>>>> today, its unlikely that less than a majority of miners would support the
>>>>> change a year or two from now), and if no one is signaling opposition,
>>>>> chances are that the vast majority of the other 40% would also eventually
>>>>> signal support.
>>>>>
>>>>> This both gives an incentive for "lazy" miners to upgrade if they actually
>>>>> oppose the change while at the same time allowing these lazy miners to
>>>>> remain lazy without slowing down the soft fork activation much.
>>>>>
>>>>> I think now is the right time to discuss new soft fork upgrade mechanisms,
>>>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>>>> until we need to deploy a soft fork to discuss this will only delay things
>>>>> and cause contention again like it did with taproot.
>>>>>
>>>>> I'm very curious to know what people think of this mechanism. I would
>>>>> appreciate any comments here, or written as github issues on the proposal
>>>>> repo itself.
>>>>>
>>>>> Thanks,
>>>>> BT
>>>>
>>>> _______________________________________________
>>>> 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

2023-06-07 22:55:25

- reply

📅 Original date posted:2021-06-26
📝 Original message:Ultimately there is only one answer to this question. Get majority hash power support.
Soft fork enforcement is the same act as any other censorship enforcement, the difference is only a question of what people want. Given that there is no collective “we”, those wants differ. Bitcoin resolves this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.
Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
e
> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
>
> For some definitions of “block”.
>
> Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>
> Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
>
> e
>
>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
>> still slow it down.
>>
>> It also already has the trinary state you seem to be describing (although
>> perhaps this could be better documented in the BIP): users who oppose the
>> softfork can and should treat the successful signal (whether MASF or UASF) as
>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>>
>> No additional bit is needed, as softforks are coordinated between users, NOT
>> miners (who have no particular say in them, aside from their role as also
>> being users). The miner involvement is only out of necessity (to set the bit
>> in the header, which users coordinate with) and potentially to accelerate
>> activation by protecting upgrade-lagging users.
>>
>> Luke
>>
>>
>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>>> Given the recent controversy over upgrade mechanisms for the
>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>> proponents make the point that LOT=true can lead to undesirable forks that
>>> might cause a lot of chaos. I believe both points are essentially correct
>>> and have created a proposal
>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>>
>>> The proposal uses trinary version signaling rather than binary signaling.
>>> For any particular prospective soft fork upgrade, this allows for three
>>> signaling states:
>>>
>>> * Actively support the change.
>>> * Actively oppose the change.
>>> * Not signaling (neither support or oppose). This is the default state.
>>>
>>> Using this additional information, we can release non-contentious upgrades
>>> much quicker (with a much lower percent of miners signaling support). For
>>> contentious upgrades, miners who oppose the change are incentivized to
>>> update their software to a version that can actively signal opposition to
>>> the change. The more opposition there is, the higher the threshold
>>> necessary to lock in the upgrade. With the parameters I currently
>>> recommended in the proposal, this chart shows how much support signaling
>>> would be necessary given a particular amount of active opposition
>>> signaling:
>>>
>>> [image: thresholdChart.png]
>>> If literally no one signals opposition, a 60% threshold should be
>>> relatively safe because it is a supermajority amount that is unlikely to
>>> change significantly very quickly (ie if 60% of miners support the change
>>> today, its unlikely that less than a majority of miners would support the
>>> change a year or two from now), and if no one is signaling opposition,
>>> chances are that the vast majority of the other 40% would also eventually
>>> signal support.
>>>
>>> This both gives an incentive for "lazy" miners to upgrade if they actually
>>> oppose the change while at the same time allowing these lazy miners to
>>> remain lazy without slowing down the soft fork activation much.
>>>
>>> I think now is the right time to discuss new soft fork upgrade mechanisms,
>>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>>> until we need to deploy a soft fork to discuss this will only delay things
>>> and cause contention again like it did with taproot.
>>>
>>> I'm very curious to know what people think of this mechanism. I would
>>> appreciate any comments here, or written as github issues on the proposal
>>> repo itself.
>>>
>>> Thanks,
>>> BT
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:55:25

- reply

📅 Original date posted:2021-06-26
📝 Original message:For some definitions of “block”.
Without majority hash power support, activation simply means you are off on a chain split. Anyone can of course split off from a chain by changing a rule (soft or otherwise) at any time, so this is a bit of an empty claim.
Nobody can stop a person from splitting. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
e
> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
> still slow it down.
>
> It also already has the trinary state you seem to be describing (although
> perhaps this could be better documented in the BIP): users who oppose the
> softfork can and should treat the successful signal (whether MASF or UASF) as
> invalid, thereby ensuring they do not follow a chain with the rules in force.
>
> No additional bit is needed, as softforks are coordinated between users, NOT
> miners (who have no particular say in them, aside from their role as also
> being users). The miner involvement is only out of necessity (to set the bit
> in the header, which users coordinate with) and potentially to accelerate
> activation by protecting upgrade-lagging users.
>
> Luke
>
>
>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>> Given the recent controversy over upgrade mechanisms for the
>> non-controversial taproot upgrade, I have been thinking about ways to solve
>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>> make the point that lazy miners failing to upgrade in a timely manner slow
>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>> proponents make the point that LOT=true can lead to undesirable forks that
>> might cause a lot of chaos. I believe both points are essentially correct
>> and have created a proposal
>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>
>> The proposal uses trinary version signaling rather than binary signaling.
>> For any particular prospective soft fork upgrade, this allows for three
>> signaling states:
>>
>> * Actively support the change.
>> * Actively oppose the change.
>> * Not signaling (neither support or oppose). This is the default state.
>>
>> Using this additional information, we can release non-contentious upgrades
>> much quicker (with a much lower percent of miners signaling support). For
>> contentious upgrades, miners who oppose the change are incentivized to
>> update their software to a version that can actively signal opposition to
>> the change. The more opposition there is, the higher the threshold
>> necessary to lock in the upgrade. With the parameters I currently
>> recommended in the proposal, this chart shows how much support signaling
>> would be necessary given a particular amount of active opposition
>> signaling:
>>
>> [image: thresholdChart.png]
>> If literally no one signals opposition, a 60% threshold should be
>> relatively safe because it is a supermajority amount that is unlikely to
>> change significantly very quickly (ie if 60% of miners support the change
>> today, its unlikely that less than a majority of miners would support the
>> change a year or two from now), and if no one is signaling opposition,
>> chances are that the vast majority of the other 40% would also eventually
>> signal support.
>>
>> This both gives an incentive for "lazy" miners to upgrade if they actually
>> oppose the change while at the same time allowing these lazy miners to
>> remain lazy without slowing down the soft fork activation much.
>>
>> I think now is the right time to discuss new soft fork upgrade mechanisms,
>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>> until we need to deploy a soft fork to discuss this will only delay things
>> and cause contention again like it did with taproot.
>>
>> I'm very curious to know what people think of this mechanism. I would
>> appreciate any comments here, or written as github issues on the proposal
>> repo itself.
>>
>> Thanks,
>> BT
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:53:27

- reply

📅 Original date posted:2021-05-16
📝 Original message:https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210516/d8707941/attachment.html>

2023-06-07 22:52:36

- reply

📅 Original date posted:2021-05-07
📝 Original message:https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
> On May 7, 2021, at 15:50, SatoshiSingh via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage of bitcoin mining. I understand a lot mining happens with renewable resources but the impact is still high.
>
> I want to get your opinion on implementing proof of stake for bitcoin mining in future. For now, proof of stake is still untested and not battle tested like proof of work. Though someday it will be.
>
> In the following years we'll be seeing proof of stake being implemented. Smaller networks can test PoS which is a luxury bitcoin can't afford. Here's how I see this the possibilities:
>
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended
>
> IF PoS turns out to be good after battle testing, would you consider implementing it for Bitcoin? I understand this would invoke a lot of controversies and a hard fork that no one likes. But its important enough to consider a hard fork. What are your opinions provided PoS does work?
>
> Love from India.
> _______________________________________________
> 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/20210507/ed773f98/attachment.html>

2023-06-07 18:30:34

- reply

📅 Original date posted:2021-03-06
📝 Original message:The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote:
>> ## Example timeline
>> - T+0: release of one or more full nodes with activation code
>> - T+14: signal tracking begins
>> - T+28: earliest possible lock in
>> - T+104: locked in by this date or need to try a different activation process
>> - T+194: activation (if lockin occurred)
>
>> ### Base activation protocol
>> The idea can be implemented on top of either Bitcoin Core's existing
>> BIP9 code or its proposed BIP8 patchset.[6]
>> BIP9 is already part of Bitcoin Core and I think the changes being
>> proposed would be relatively small, resulting in a small patch that
>> could be easy to review.
>
> To get to specifics, here's a PR, based on #21334, that updates bip9
> to support an extra parameter to delay the transition from LOCKED_IN
> to ACTIVE until a particular timestamp is reached, and to reduce the
> activation threshold to 90%:
>
> https://github.com/bitcoin/bitcoin/pull/21377
>
> With that in mind, I think the example timeline above could translate
> to taproot parameters of:
>
> nStartTime = 1618358400; // April 14, 2021
> nTimeout = 1626220800; // July 14 2021
> activation_time = 1633046400; // October 1 2021
>
> That is, signalling begins with the first retarget period whose parent's
> median time is at least April 14th; and concludes with the last retarget
> period whose final block's median time is prior to July 14th; that's
> 91 days which should be about ~6.5 retarget periods, so should cover 6
> full retarget periods, but could only cover 5. Activation is delayed
> until the first retarget period where the final block of the previous
> retarget period has a timestamp of at least October 1st.
>
> Note that the timeout there is prior to the expected timestamp of the
> startheight block specified in the proposal for bip8 parameters:
>
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
>
> and earliest activation is after the expected release of 22.0 and hence
> the maintenance end of 0.20.
>
> Note also that the PR above specifies the delay as a deadline, not a
> delta between lockin and activation; so earlier lockin does not produce
> an earlier activation with the code referenced above.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:26

- reply

📅 Original date posted:2021-03-05
📝 Original message:FYI it’s generally considered bad form repost a private thread, especially one you initiate.
...
It’s typically more effective to generate some community support before actually submitting a BIP. Otherwise the process gets easily overwhelmed. This is likely why you aren’t getting a response. You can draft the BIP in your own repo and collect feedback from interested parties.
Posting a link to your research/code is a good start. I’d be happy to look at an overview of the central principles. I’m not a cryptographer. I write code, but I look at these things from economic principles. So far all I have to go on is that you go “much beyond” Chia. That’s not really anything.
e
> On Mar 5, 2021, at 14:03, Lonero Foundation <loneroassociation at gmail.com> wrote:
>
>
> Hi, Eric. Chia's network is a bad example. They go after energy consumption in the wrong way entirely. True, it requires a comparable cost of hardware. I am trying to tackle cryptography in a way that goes much beyond that. Part of what I am doing includes lowering invalided proofs while trying to get the best of both worlds in regards to PoW and PoC. It is an efficiency issue to the core. In regards to the mechanisms of how I will do that, I suggest you look at the entire proposal which is why I am hoping the BIP team would be so gracious as to allow me to draft it out on GitHub.
>
> Best regards, Andrew
>
>> On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil <eric at voskuil.org> wrote:
>> How is the argument against PoM only partially true?
>>
>> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm, before he blocked me. Two years later, after they finally realized I was correct, one of their PhDs contacted me and told me. Better to flesh this out early. They had already raised $20 and done their research, so he wasn’t exactly in a listening mode.
>>
>> e
>>
>>>> On Mar 5, 2021, at 13:20, Lonero Foundation <loneroassociation at gmail.com> wrote:
>>>>
>>>
>>> Actually I mentioned a proof of space and time hybrid which is much different than staking. Sorry to draw for the confusion as PoC is more commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Work as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of being both CPU compatible and memory-hard compatible. There are lots of benefits outside of the realm of efficiency, and I already looked into numerous fault tolerant designs as well and what others in the cryptography community attempted to propose. The actual argument you have only against this is the Proof of Memory fallacy, which is only partially true. Given how the current hashing algorithm works, hard memory allocation wouldn't be of much benefit given it is more optimized for CPU/ASIC specific mining. I'm working towards a hybrid mechanism that fixes that. BTW: The way Bitcoin currently stands in its cryptography still needs updating regardless. If someone figures out NP hardness or the halting problem the traditional rule of millions of years to break all of Bitcoin's cryptography now comes down to minutes. Bitcoin is going to have to eventually radically upgrade their cryptography and hashing algo in the future regardless. I want to integrate some form of NP complexity in regards to the hybrid cryptography I'm aiming to provide which includes a polynomial time algorithm in the cryptography. More than likely the first version of my BTC hard fork will be coded in a way where integrating such complexity in the future only requires a soft fork or minor upgrade to its chain.
>>>
>>> In regards to the argument, "As a separate issue, proposing a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining entities and disincentivize future capital expenditure into mining hardware that may compute these more "useful" proofs of work."
>>>
>>> A large portion of BTC is already mined through AWS servers and non-asic specific hardware anyways. A majority of them would benefit from a hybrid proof, and the fact that it is hybrid in that manner wouldn't disenfranchise currently optimized mining entities as well.
>>>
>>> There are other reasons why a cryptography upgrade like this is beneficial. Theoretically one can argue BItcoin isn't fully decentralized. It is few unsolved mathematical proofs away from being entirely broken. My goal outside of efficiency is to build cryptography in a way that prevents such an event from happening in the future, if it was to ever happen. I have various research in regards to this area and work alot with distributed computing. I believe if the BTC community likes such a proposal, I would single handedly be able to build the cryptographic proof myself (though would like as many open source contributors as I can get :)
>>>
>>> Anyways just something to consider. We are in the same space in regards to what warrants a shitcoin or the whole argument against staking.
>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>>>
>>> Best regards, Andrew
>>>
>>>> On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil <eric at voskuil.org> wrote:
>>>> Hi Andrew,
>>>>
>>>> Do you mean that you can reduce the cost of executing the cryptography at a comparable level of security? If so this will only have the effect of increasing the amount of it that is required to consume the same cost.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
>>>>
>>>> You mentioned a staking hybrid in your original post.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy
>>>>
>>>> This would be a change to dynamics - the economic forces at work. Staking is not censorship resistant
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>>>>
>>>> and is therefore what I refer to as cryptodynamically insecure.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles
>>>>
>>>> As such it wouldn’t likely be considered as a contribution to Bitcoin. It might of course be useful in some other context.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition
>>>>
>>>> But BIPs are proposals aimed at Bitcoin improvement.
>>>>
>>>> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP
>>>>
>>>> Non-staking attempts to improve energy efficiency are either proof of work in disguise, such as proof of memory:
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
>>>>
>>>> or attempts to repurpose “wasteful” computing, such as by finding prime numbers, which does not imply a reduction in dedicated energy consumption.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle
>>>>
>>>> Finally, waste and renewable energy approaches at “carbon” (vs energy) reduction must still consume the same in cost as the reward. In other words, the apparent benefit represents a temporary market shift, with advantage to first movers. The market will still consume what it consumes. If the hashing energy was free all reward consumption would shift to operations.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy
>>>>
>>>> The motivation behind these attempts is naively understandable, but based on a false premise.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy
>>>>
>>>> The one thing that reduces Bitcoin energy consumption is an increase in energy cost relative to block reward.
>>>>
>>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy
>>>>
>>>> e
>>>>
>>>>>> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>
>>>>> Hi, this isn't about the energy efficient argument in regards to renewables or mining devices but a better cryptography layer to get the most out of your hashing for validation. I do understand the arbitrariness of it, but do want to still propose a document. Do I use the Media Wiki format on GitHub and just attach it as my proposal?
>>>>>
>>>>> Best regards, Andrew
>>>>>
>>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>>>>>> Hi Ryan and Andrew,
>>>>>>
>>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>
>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/
>>>>>>> "Nothing is Cheaper than Proof of Work"
>>>>>>> on | 04 Aug 2015
>>>>>>>
>>>>>>
>>>>>> Just to belabor this a bit, the paper demonstrates that the mining market will tend to expend resources equivalent to miner reward. It does not prove that mining work has to expend *energy* as a primary cost.
>>>>>>
>>>>>> Some might argue that energy expenditure has negative externalities and that we should move to other resources. I would argue that the negative externalities will go away soon because of the move to renewables, so the point is likely moot.
>>>>>>
>>>>> _______________________________________________
>>>>> 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/20210305/20099e8b/attachment-0001.html>

2023-06-07 18:30:25

- reply

📅 Original date posted:2021-03-05
📝 Original message:Hi Andrew,
Do you mean that you can reduce the cost of executing the cryptography at a comparable level of security? If so this will only have the effect of increasing the amount of it that is required to consume the same cost.
https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
You mentioned a staking hybrid in your original post.
https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy
This would be a change to dynamics - the economic forces at work. Staking is not censorship resistant
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
and is therefore what I refer to as cryptodynamically insecure.
https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles
As such it wouldn’t likely be considered as a contribution to Bitcoin. It might of course be useful in some other context.
https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition
But BIPs are proposals aimed at Bitcoin improvement.
https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP
Non-staking attempts to improve energy efficiency are either proof of work in disguise, such as proof of memory:
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
or attempts to repurpose “wasteful” computing, such as by finding prime numbers, which does not imply a reduction in dedicated energy consumption.
https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle
Finally, waste and renewable energy approaches at “carbon” (vs energy) reduction must still consume the same in cost as the reward. In other words, the apparent benefit represents a temporary market shift, with advantage to first movers. The market will still consume what it consumes. If the hashing energy was free all reward consumption would shift to operations.
https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy
The motivation behind these attempts is naively understandable, but based on a false premise.
https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy
The one thing that reduces Bitcoin energy consumption is an increase in energy cost relative to block reward.
https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy
e
> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi, this isn't about the energy efficient argument in regards to renewables or mining devices but a better cryptography layer to get the most out of your hashing for validation. I do understand the arbitrariness of it, but do want to still propose a document. Do I use the Media Wiki format on GitHub and just attach it as my proposal?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>> Hi Ryan and Andrew,
>>
>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> https://www.truthcoin.info/blog/pow-cheapest/
>>> "Nothing is Cheaper than Proof of Work"
>>> on | 04 Aug 2015
>>
>> Just to belabor this a bit, the paper demonstrates that the mining market will tend to expend resources equivalent to miner reward. It does not prove that mining work has to expend *energy* as a primary cost.
>>
>> Some might argue that energy expenditure has negative externalities and that we should move to other resources. I would argue that the negative externalities will go away soon because of the move to renewables, so the point is likely moot.
> _______________________________________________
> 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/20210305/a6aaba91/attachment.html>

2023-06-07 18:29:55

- reply

📅 Original date posted:2021-03-04
📝 Original message:Mike was wrong about a number of things, and in the end decided that Bitcoin was pointless, as people could not defend it against the state. He used this as the basis for his defense of large blocks and centralized mining. When that didn’t work out he quit, to work on centralized systems.
People can of course do what they want, but unnecessarily splitting from the existing chain reduces utility, which seems counterproductive. BCH is a good example of this.
Compatibility isn’t “dangerous”. Old nodes don’t need to know what new nodes are doing. If the person operating one needs to validate a taproot payment to himself, he would have to upgrade. Otherwise it’s of no consequence, his node is economic (relevant) only in relation to the legacy payments he receives, which he can continue to validate.
e
> On Mar 4, 2021, at 15:22, Vincent Truong via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
> I must remind everyone of Mike Hearn's proposal not many years ago, which ought to be on everyone's mind right now. "Every soft fork should be a hard fork, and that soft forks are inherently dangerous because old nodes are tricked to not know what the new nodes are doing" (paraphrased). Whether taproot is dangerous is not the issue; whether old nodes should or should not ignore new rules, is.
>
> Flag day activation of a soft fork is basically proposing a hard fork, but without saying or doing it at full commitment. May as well just do a flag day hard fork.
>
> Bitcoin Cash/Bcash has already tested for you how a market driven hard fork should work. Bitcoin didn't die. We should be learning from the mistakes made in those early hard forks to not repeat them when Bitcoin hard forks - like having replay protection written before deployment.
>
> If it's not evident within the first 6-12 blocks which fork is winning, then the market will trade it out. Just like what happened with Bitcoin Cash/Bcash.
>
> Not only that, it stops the drama of Bitcoin Core devs from "being in control" of consensus. The market will choose, you just create the safest way for users to participate. The market is consensus. Rough consensus is just the conversation starter.
>
>
>> On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The bitcoin world is close to total gridlock on the question of how to
>> activate taproot. There's no agreement on activation[1][2], and if an
>> agreement isn't reached then nothing happens. That would be really
>> terrible because we'd miss out on the benefits of taproot and
>> potentially other future soft forks.
>>
>> A major problem with BIP8 is that it would result to a situation where
>> different parts of the bitcoin ecosystem run different consensus rules.
>> Some people will run LOT=true and others LOT=false. Worst of all, it
>> becomes vulnerable to a twitter/reddit/social media blitz which could
>> attempt to move the date of miner activation around.
>>
>> Twitter and reddit drama provide a perfect cover for social attacks on
>> bitcoin.
>>
>> Forced signalling leads to brinksmanship. Where two or more sides
>> (backed up by social media drama) enter into a game of chicken with
>> deployed nodes. If one of them doesn't concede then we get a damaging
>> chain split. And the $1 trillion in value that the bitcoin network
>> protects is put at risk. From the point of view of a miner or big
>> exchange stuck in the middle, if they look at the ecosystem of twitter
>> and reddit (especially if you think about all the problems with bots and
>> sockpuppets) they have no idea which consensus rules they should
>> actually follow and exactly what date they take effect. Miners,
>> exchanges, merchants and the rest of the ecosystem exist to serve their
>> customers and users, and trouble happens when they don't know what their
>> customers really want. Social media attacks are not just a theoretical
>> concern; back during the block size drama, the bitcoin reddits were
>> targetted by bots, sockpuppets and brigading[3].
>>
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except have its own
>> followers fork away. Crucially, miner signalling cant be used to change
>> the activation date for nodes that didn't choose to and just passively
>> follow signalling. Changing the activation date requires all those users
>> to actually run different node software.
>>
>> Flag day activation works simply: we choose a block height and after
>> that block height the new taproot rules become enforced.
>>
>>
>> Supporters of the permissionless, "users rule" approach of LOT=true
>> should be happy because it completely takes miners out of activation.
>>
>> Supporters of the safe, conservative approach of LOT=false can be made
>> happy with a few ways of derisking:
>>
>> * Getting mining pools, businesses and users to look at the code and ask
>> if they (a) think its either neutral or good for their business or use
>> case and (b) they believe others view it similarly and that the
>> consensus changes proposed have a good social consensus around them.
>>
>> * Setting the flag day far in the future (18 months or 2 years in the
>> original proposal[3]).
>>
>>
>> == What if flag day activation is used maliciously? ==
>>
>> What if one day the Core developer team is co-opted and uses the flag
>> day method to do something bad? For example, a soft fork where sending
>> to certain blacklisted addresses is not allowed. The bitcoin user
>> community who wants to resist this can create their own
>> counter-soft-fork full node, where the first block after the flag day
>> MUST pay to one of those addresses on the blacklist. This forces a chain
>> split between the censorship rules and the no-censorship rules, and its
>> pretty obvious that the real bitcoin which most people follow will be
>> the chain without censorship.
>>
>> For example, if a group of users didn't agree with taproot then they
>> could create their own counter-flag-day-activation which requires that a
>> transaction is included that does an invalid-spend from a taproot output
>> in the first block after the flag day height.
>>
>> This is always possible with any user activated soft fork. In BIP8
>> LOT=true it could be done by rejecting block headers with certain
>> version bits signalled.
>>
>>
>> == But it will take so long! ==
>>
>> We seem to be at a deadlock now. This will take less time than any other
>> method, because other methods might never happen. BIP8 is dead and from
>> what I see there's no other credible plan.
>>
>> We've already waited years for taproot. I remember listening to talks
>> about bitcoin from 2015 of people discussing Schnorr signatures. And
>> given how slow segwit and p2sh adoption were its pretty likely that
>> we'll waiting a while for taproot to be actually adopted.
>>
>>
>> == A social media blitz could still try to activate it early ==
>>
>> The brinksmanship only works because miner signalling can make many
>> other nodes activate early, even if those other nodes didn't do
>> anything. There can't be a game of chicken that puts the bitcoin network
>> at risk.
>>
>> If a group of people did adopt alternative node software which has a
>> shorter flag day, they actually have a risk of slow blocks. Because they
>> cant trick or force any other nodes to come along with them, they are
>> likely to only have a small economy and therefore would lose a lot of
>> hashrate. Imagine trading bitcoins for cash in person and instead of
>> waiting 10 minutes for a confirmation you have to wait 3 hours because
>> the blocks are slow.
>>
>> Also, the argument for downloading and running a different software only
>> to speed up activation is pretty weak. Taproot would activate in ~18
>> months, so why are you so impatient that you need it in 6 months? And
>> risk slow blocks for you while doing so? The big difference with BIP148
>> the segwit UASF, is that people *had to* run some other software
>> otherwise they would get *no soft fork at all*.
>>
>>
>> == Without miner signalling how do we know the new rules are even
>> activated? ==
>>
>> When did you see miners signalling their support for the inflation schedule?
>>
>> Bitcoin's rules are enforced by wallets backed by full nodes. You'll
>> always know if your own full node is enforcing the new rules. The thing
>> that matters isnt miner signalling but your own full node, and the nodes
>> of those you trade with.
>>
>> Flag day activation is quite similar to the way block reward halvenings
>> work. At and after block height 630000 miners are only allowed to create
>> 6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
>> to create 12.5 BTC or more they would be unable to sell or spend those
>> coins anywhere.
>>
>> In 2017 when segwit was being activated people created a huge list of
>> various bitcoin companies, merchants and wallets:
>> https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
>> Looking at that list, you would know that if someone stole coins from a
>> segwit address they would be unable to deposit them in many exchanges
>> and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
>> Vaultoro, HitBTC, etc.
>>
>> Then what happened is only a month after S2X was beaten this guy moved
>> 40000 BTC to a segwit address, confident about the power of the network
>> to protect his coins.
>> https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/
>>
>> If there's ever any doubt about flag day activation we can always draw
>> up a similar list, although if there's broad consensus about it then
>> there's no reason why bitcoin businesses wouldn't upgrade to the latest
>> Core, like they did with every other previous soft fork.
>>
>>
>> == This gives the impression that Core developers control the protocol ==
>>
>> This objection has a mirror image argument: BIP8 with LOT=false gives
>> the impression that miners control the protocol(!)
>>
>> Eventually some group has to make a decision. We will ask the bitcoin
>> economy and users what they think of flag day activation. It's pretty
>> clear that nobody seriously objects to taproot, and as described above
>> if Core developers did something evil the community could resist it with
>> a counter-flag-day-activation.
>>
>>
>>
>> == TL;DR ==
>>
>> I believe flag day activation is the way forward. It should answer all
>> the objections and risks which make other methods too controversial.
>> Let's go ahead and bring taproot to bitcoin!
>>
>>
>>
>> == References ==
>>
>> [1] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
>> luke-jr posts saying LOT=false in his view reintroduces a bug, he
>> compares it to introducing an inflation bug and just hoping that miners
>> will not exploit it.
>>
>> [2] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
>> This whole thread has many people disagreeing with LOT=true
>>
>> [3] -
>> https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/
>>
>> https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1
>>
>> https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3
>>
>> [4] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
>> Matt Corallo's flag day activation proposal
>> _______________________________________________
>> 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/20210304/c4f49241/attachment-0001.html>

2023-06-07 18:29:47

- reply

📅 Original date posted:2021-03-02
📝 Original message:I personally don’t like the term 51% attack as applied to censorship. A miner is free to mine or not mine any transactions it wants (censor). The term attack is better reserved for stealing from someone (reclaiming spends using hash power), as it implies a moral distinction.
But 51% attack is the term in common use for a majority censor and using it helps people understand the mechanism of hash power soft fork enforcement. It’s not intended as a pejorative.
However “without social support” is a political term. It confuses the actual behavior to imply the mechanism is somehow not the same because there is some ill-defined level of agreement.
e
> On Mar 2, 2021, at 10:58, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
>> I'm realizing that a clear advantage of LOT=false is that it can happen
>> without the need for a social movement. All that is really needed is the
>> convincing of 95% miners. Apathetic users will never notice any kind of
>> service disruption no matter the success or failure of the activation. This
>> is obviously why it naturally became the default activation method.
>
> No. Miners enforcing rules without the social support is a 51% attack, not a
> softfork.
>
>> While LOT=true, on the other hand, must be able to 51% the blockchain to
>> win the apathetic users. But then the reorgs will not be pretty. Or if it
>> ever clearly gets over the 51% hurdle then all apathetic users now need to
>> scramble to use the rogue client to be safe from reorgs. Either way it's
>> disruptive.
>
> No, LOT=True doesn't do this. It only happens if miners choose to create an
> invalid chain, which they could do at any time with or without a softfork
> involved.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:45

- reply

📅 Original date posted:2021-03-02
📝 Original message:To clarify, it is the soft fork enforcement by majority hash power that is the 51% attack, not the stopping of it. Majority hash power censors non-conforming transactions. To counter it requires only a non-censoring majority to continue mining.
It is correct that the purpose of supermajority signaling is to reduce the chance of a chain split. It is misleading to call it a bug and to imply that user activation isn’t actually intended to create, or at least threaten, a chain split. It’s a game of chicken.
e
> On Mar 2, 2021, at 10:22, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.
>
> As we vividly saw in the events of the 2017 UASF, the purpose of miner
> signalling isn't to activate or enforce the new rules but to stop a
> chain split. A majority of miners can stop a chain split by essentially
> doing a 51% attack. Such attacks have been known about since day one,
> and even the whitepaper writes about them.
>
> So they are not a bug but an inherent part of the way bitcoin works. If
> fixing this issue was a simple as setting a consensus rule parameter
> then bitcoin would have been invented decades earlier than it was.
>
> And certainly miner signalling cannot be compared to an inflation bug.
> The inflation rules are enforced by the economy using full nodes, but
> chain splits or lack of them is enforced by miners. They are two
> different parts of the bitcoin system. Back in 2010 there was an
> inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
> my point. Even though miners created a block which printed 184 billion
> bitcoins, the economy quickly adopted a patch which fixed the bug and
> miners switched over to the correct chain which soon overtook the bugged
> chain (there was a reorg of 53 blocks).
>
>
>
>
> Also another point: in a hypothetical chain split it's true that the
> LOT=false chain would be vulnerable to reorgs, but it's also true that
> the LOT=true would suffer from slow blocks.
>
> So for example, imagine trading bitcoin for cash in person, but instead
> of waiting on average 10 minutes for a confirmation you have to wait 2
> hours. Imagine depositing coins to an exchange which requires 3
> confirmation, then instead of waiting ~30 minutes you have to actually
> wait 6 hours. This is a significant degradation in usability. The
> situation is a mirror image of how the LOT=false chain is vulnerable to
> reorgs. Both chains suffer if a chain split happens which is why they
> are pretty important to avoid. That's why its inaccurate to portray
> LOT=true chain as safe with no downsides at all.
>
>
>
>
>> On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
>> (Note: I am writing this as a general case against LOT=False, but using
>> Taproot simply as an example softfork. Note that this is addressing
>> activation under the assumption that the softfork is ethical and has
>> sufficient community support. If those criteria have not been met, no
>> activation should be deployed at all, of any type.)
>>
>> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone,
>> despite its potential benefits, also leaves open the door to a miner veto.
>> This was never the intended behaviour, and a bug, which took a rushed
>> deployment of BIP148 to address. LOT=False would reintroduce that same bug.
>> It wouldn't be much different than adding back the inflation bug
>> (CVE-2018-17144) and trusting miners not to exploit it.
>>
>> Some have tried to spin LOT=True as some kind of punishment for miners or
>> reactive "counter-attack". Rather, it is simply a fallback to avoid
>> regression on this and other bugs. "Flag day" activation is not fundamentally
>> flawed or dangerous, just slow since everyone needs time to upgrade.
>> BIP 8(LOT=True) combines the certainty of such a flag day, with the speed
>> improvement of a MASF, so that softforks can be activated both reasonably
>> quick and safely.
>>
>> In the normal path, and that which BIP8(True) best incentivises, miners will
>> simply upgrade and signal, and activation can occur as soon as the economic
>> majority is expected to have had time to upgrade. In the worst-case path, the
>> behaviour of LOT=True is the least-harmful result: unambiguous activation and
>> enforcement by the economy, with miners either deciding to make an
>> anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners
>> revolt against the softfork, the LOT=True nodes are simply faced with a
>> choice to hardfork (replacing the miners with a PoW change) or concede - they
>> do not risk vulnerability or loss.
>>
>> With LOT=False in the picture, however, things can get messy: some users will
>> enforce Taproot(eg) (those running LOT=True), while others will not (those
>> with LOT=False). Users with LOT=True will still get all the safety thereof,
>> but those with LOT=False will (in the event of miners deciding to produce a
>> chain split) face an unreliable chain, being replaced by the LOT=True chain
>> every time it overtakes the LOT=False chain in work. For 2 weeks, users with
>> LOT=False would not have a usable network. The only way to resolve this would
>> be to upgrade to LOT=True or to produce a softfork that makes an activated
>> chain invalid (thereby taking the anti-Taproot path). Even if nobody ran
>> LOT=True (very unlikely), LOT=False would still fail because users would be
>> faced with either accepting the loss of Taproot(eg), or re-deploying from
>> scratch with LOT=True. It accomplishes nothing compared to just deploying
>> LOT=True from the beginning. Furthermore, this process creates a lot of
>> confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have
>> to do it AGAIN?"), and in some scenarios additional code may be needed to
>> handle the subsequent upgrade cleanly.
>>
>> To make matters worse for LOT=False, giving miners a veto also creates an
>> incentive to second-guess the decision to activate and/or hold the activation
>> hostage. This is a direct result of the bug giving them a power they weren't
>> intended to have. Even if we trust miners to act ethically, that does not
>> justify sustaining the bug creating both a possibility and incentive to
>> behave unethically.
>>
>> So in all possible scenarios, LOT=False puts users and the network at
>> significant risk. In all possible scenarios, LOT=True minimises risk to
>> everyone and has no risk to users running LOT=True.
>>
>> The overall risk is maximally reduced by LOT=True being the only deployed
>> parameter, and any introduction of LOT=False only increases risk probability
>> and severity.
>>
>> For all these reasons, I regret adding LOT as an option to BIP 8, and think it
>> would be best to remove it entirely, with all deployments in the future
>> behaving as LOT=True. I do also recognise that there is not yet consensus on
>> this, and for that reason I have not taken action (nor intend to) to remove
>> LOT from BIP 8. However, the fact remains that LOT=False should not be used,
>> and it is best if every softfork is deployed with LOT=True.
>>
>> Luke
>> _______________________________________________
>> 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

2023-06-07 18:29:38

- reply

📅 Original date posted:2021-03-04
📝 Original message:Your Excellency,
You don’t seem to understand how Bitcoin currently works. A signature is a mathematical /probabilistical proof that the person who signed (the output) is the same person who created the script (the input) that was paid to (i.e. not fraud). You cannot see that he is that person, you can only do the math - giving yourself a reasonable assurance that it is not a fraud.
Taproot is not a proposed change to this design, so I’m not sure to what exactly you are objecting. The math continues to be the sole assurance and visibility that the money was created and transferred in accordance with the agreed rules (consensus). There is no other way for anyone to “look at” potential fraud on the chain.
If you are aware of any flaw in the existing or proposed mathematics that would enable fraudulent creation or transfer of bitcoin, please spell it out for us.
e
> On Mar 3, 2021, at 21:10, LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au> wrote:
>
> Good Afternoon,
>
> I will reply privately here, what do you say I am not in support of fungibility? This fungibility is because of consensus including transparency. Otherwise, if it is just a fraud no-one can look at it.
>
> KING JAMES HRMH
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Felipe Micaroni Lalli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Thursday, 4 March 2021 3:30 AM
> To: eric at voskuil.org <eric at voskuil.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Taproot NACK
>
> Dear LORD HIS EXCELLENCY JAMES HRMH (& HMRH), a.k.a. "The Australian",
>
> This discussion list is serious stuff, please stop making noise. Fungibility is a desirable property, anyway.
>
> Thank you!
>
>> On Wed, Mar 3, 2021 at 12:04 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > consensus requires the ledger to be honest does not prove that it is honest.
>
> Actually, that’s exactly what it does. A logical/mathematical requirement (necessity) is also called a proof.
>
> e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/9eda8a92/attachment-0001.html>

2023-06-07 18:29:38

- reply

📅 Original date posted:2021-03-17
📝 Original message:> If you actually believe the operation of consensus and the discussion relevant to that is a mundane or philosophical dissection of people's ability to grasp a humorous while on-topic but obligatorily unnecessary conversation you may prefer if you enquire how Bitcoin is censorship-resistant.
https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210317/c6eeab73/attachment.html>

2023-06-07 18:29:29

- reply

📅 Original date posted:2021-03-12
📝 Original message:I’m pretty sure it’s subtle mockery. Even a legit title doesn’t warrant additional attention.
e
> On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Can I just point out (to those addressing James as Lord/Excelency/etc
> that he isn't noble nor a Lord, so just wanted to mention this in case
> people were giving him more attention than the average person would be
> afforded.
>
> My 2p (an equal 2p) on Taproot is ACK, by the way.

2023-06-07 18:29:23

- reply

📅 Original date posted:2021-03-01
📝 Original message:To be clear, is this a NACK because Taproot reduces “transparency” (increases privacy) on the chain (“maintaining consensus” is obviously an argument against any protocol change, so that’s a red herring)?
And is it your theory that only an “honest” (statute abiding) person should have privacy, and not against the state, and/or that mixers are sufficient privacy?
Personally, I’m not moved by such an argument. What do you think is the value proposition of Bitcoin?
e
> On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Good Afternoon,
>
> I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
>
> My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
>
> The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
>
> My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
> <ip.bitcointalk.org.png>
>
> [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw
> from this thread https://bitcointalk.org/index.php?topic=5267588
>
>
> The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
> https://github.com/jambler-io/bitcoin-mixer
>
> The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
> https://jambler.io/become-partner.php
>
> I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
>
> If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> From: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
> Sent: Monday, 1 March 2021 12:07 AM
> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Taproot NACK
>
> Hello LORD HIS EXCELLENCY JAMES HRMH
>
> I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
>
> At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
>
> Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
>
> Cheers
> Ariel Lorenzo-Luaces
> On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good Evening,
>
> Thank-you for your advice @JeremyRubin on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
>
> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
>
> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> From: Jeremy <jlrubin at mit.edu>
> Sent: Sunday, 28 February 2021 3:14 AM
> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Taproot NACK
>
> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
>
> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
>
> Do you have a source on your reporting?
>
> You may wish to rescind your nack.
>
>
> --
> @JeremyRubin
>
>
> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good Afternoon,
>
> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
>
> If that is the case I offer a full NACK and let me explain.
>
> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
>
> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> _______________________________________________
> 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
> <ip.bitcointalk.org.png>
> _______________________________________________
> 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/20210301/0f83b45c/attachment-0001.html>

2023-06-07 18:29:21

- reply

📅 Original date posted:2021-02-28
📝 Original message:I think it has been shown that an understanding of reasonableness is not universal, making any assertion about it as a collective goal kind of self-defeating. The question is what is achievable, not what is reasonable. I’m not making any value judgements here. Simply pointing out that anything other than a successful 51% attack will create a split.
e
> On Feb 28, 2021, at 12:25, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically addressed each of in the OP of this thread.
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
>
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> In the attempt to change consensus rules there is a simple set of choices:
>> 1) hard fork: creates a chain split
>> 2) soft fork: creates a chain split
>> 3) 51% attack: does not create a chain split
>> The presumption being that one can never assume 100% explicit adoption of any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than majority threshold, as has been done in the past.
>> Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody is in charge.
>> The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. No power is given to them by developers or anyone else. They have that power based on their own capital invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If there is some other objective, it’s not clear to me what it is.
>> e
>>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>
>>> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced selfish mining" to take advantage of it.
>>>
>>>
>>> Hard to analyze exactly what that looks like, but...
>>>
>>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving themselves a larger % of hashrate.
>>>
>>> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners leads to some nasty oscillating hashrate being optimal.
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>>>
>>>
>>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>> wrote:
>>>
>>> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running
>>> Bitcoin
>>> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3)
>>> from
>>> my original post - it results in any miner who has not taken active action (and ensured every part of their
>>> often-large
>>> infrastructure has been correctly reconfigured) generating invalid blocks.
>>>
>>> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>>> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>>
>>> Matt
>>>
>>>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>> > I agree with much of the logic presented by Matt here.
>>> >
>>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a
>>> "tiny"
>>> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a
>>> concept
>>> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>>> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>>> > should do and when.
>>> >
>>> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on
>>> its own,
>>> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain
>>> date are
>>> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a
>>> cooptable
>>> > consensus process than something more straightforward.
>>> >
>>> >
>>> > That said, a few points strike me as worth delving into.
>>> >
>>> >
>>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days --
>>> one for
>>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and
>>> flag day
>>> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV
>>> mining
>>> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>>> > ensure the tip is valid).
>>> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients
>>> would
>>> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g.,
>>> LOT=true
>>> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation
>>> is/was
>>> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering
>>> schedules,
>>> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a
>>> quantized
>>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>>> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if
>>> signaling does
>>> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with
>>> start
>>> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that
>>> secondary
>>> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining
>>> reward). So I
>>> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard
>>> fork if
>>> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>>> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>>> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year
>>> flag
>>> > day, to do that via LOT=true so that taproot can still have early activation if desired.
>>> >
>>> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>>> > closer to a flag day might not be so bad either for future forks as well.
>>> >
>>> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best
>>> option
>>> > at this time as it allows our flag day to remain compatible with such an early activation.
>>> >
>>> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any
>>> future
>>> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>>> > parameters).
>>> >
>>> >
>>> > _______________________________________________
>>> > 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>
>>> >
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:19

- reply

📅 Original date posted:2021-02-28
📝 Original message:In the attempt to change consensus rules there is a simple set of choices:
1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split
The presumption being that one can never assume 100% explicit adoption of any rule change.
A 51% attack can of course fail. It is also possible that signaling can be untruthful. But miner signaling provides some level of assurance that it will be successful. This level of assurance is increased by adoption of a higher than majority threshold, as has been done in the past.
Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody is in charge.
The majority of those who mine can choose to enforce censorship any time they want. They don’t need anyone’s permission. No power is given to them by developers or anyone else. They have that power based on their own capital invested.
Similarly, the economy (those who accept bitcoin) can enforce any rule change it wants to. And it can do so at any level of participation that wants to go along. Anyone can do this, it requires nobody’s permission. Furthermore, it is possible for the economy to signal its level of agreement in every transaction, as miners have done in blocks previously.
But if the objective is to produce a rule change while avoiding a chain split, 50% is a much lower bar than 100%. If there is some other objective, it’s not clear to me what it is.
e
> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced selfish mining" to take advantage of it.
>
>
> Hard to analyze exactly what that looks like, but...
>
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine bad blocks would mean 1/4th of the time you could make 20% of the hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One could analyze out that the lost hash rate for bad blocks only matters for the first difficulty adjustment period you're doing this for too, as the hashrate drop will be accounted for -- but then a miner can switch back to mining valid chain, giving themselves a larger % of hashrate.
>
> So it is still possible that an un-upgraded miner will fail part 3, and attempting to accommodate un-upgraded miners leads to some nasty oscillating hashrate being optimal.
>
>
> --
> @JeremyRubin
>
>
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists at mattcorallo.com> wrote:
>> Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
>> Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
>> my original post - it results in any miner who has not taken active action (and ensured every part of their often-large
>> infrastructure has been correctly reconfigured) generating invalid blocks.
>>
>> As for "Taproot" took too long, hey, at least if its locked in people can just build things assuming it exists. Some
>> already are, but once its clearly locked in, there's no reason to not continue other work at the same time.
>>
>> Matt
>>
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> >
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny"
>> > parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept
>> > here given differing levels of sophistication and information). It is therefore much simpler and more likely to be
>> > universally understood by all network participants to just have a flag day. It is easier to communicate what users
>> > should do and when.
>> >
>> > This is ultimately not coercive to users because the upgrade for Taproot itself is provable and analyzable on its own,
>> > but activation parameters based on what % of economically relevant nodes are running an upgrade by a certain date are
>> > not. Selecting these sorts of complicated consensus parameters may ultimately present more opportunity for a cooptable
>> > consensus process than something more straightforward.
>> >
>> >
>> > That said, a few points strike me as worth delving into.
>> >
>> >
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory signaling is effectively 2 flag days -- one for
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap between flag day for signaling and flag day
>> > for taproot rules is, more or less, so that nodes who aren't taproot ready at the 1st flag day do not end up SPV mining
>> > (using standardness rules in mempool prevents them from mining an invalid block on top of a valid tip, but does not
>> > ensure the tip is valid).
>> > 2) Con: Releasing a flag day without releasing the LOT=true code leading up to that flag day means that clients would
>> > not be fully compatible with an early activation that could be proposed before the flag day is reached. E.g., LOT=true
>> > is a flag day that retains the possibility of being compatible with other BIP8 releases without changing software.
>> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm personally skeptical that early activation is/was
>> > ever a good idea. A fixed activation date may be largely superior for business purposes, software engineering schedules,
>> > etc. I think even with signaling BIP8, it would be possibly superior to activate rules at a fixed date (or a quantized
>> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more).
>> > 4) Pro: part of the argument for BIP-8=false is that it is possible that the rule could not activate, if signaling does
>> > not occur, providing additional stopgap against dev collusion and bugs. But BIP-8 can activate immediately (with start
>> > times being proposed 1 month after release?) so we don't have certainty around how much time there is for that secondary
>> > review process (read -- I think it isn't that valuable) and if there *is* a deadly bug discovered, we might want to
>> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rule activates it enables more mining reward). So I
>> > think that it's a healthier mindset to release a with definite deadline and not rule out having to do a hard fork if
>> > there is a grave issue (we shouldn't ever release a SF if we think this is at all likely, mind you).
>> > 5) Con: It's already taken so long for taproot, the schedule around taproot was based on the idea it could early
>> > activate, 2022 is now too far away. I don't know how to defray this other than, if your preferred idea is 1 year flag
>> > day, to do that via LOT=true so that taproot can still have early activation if desired.
>> >
>> > Overall I agree with the point that all the contention around LOT, makes a flag day look not so bad. And something
>> > closer to a flag day might not be so bad either for future forks as well.
>> >
>> > However, I think given the appetite for early activation, if a flag day is desired I think LOT=true is the best option
>> > at this time as it allows our flag day to remain compatible with such an early activation.
>> >
>> > I think we can also clearly communicate that LOT=true for Taproot is not a precedent setting occurence for any future
>> > forks (hold me accountable to not using this as precedent this should I ever advocate for a SF with similar release
>> > parameters).
>> >
>> >
>> > _______________________________________________
>> > 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/20210228/7aaf54ca/attachment-0001.html>

2023-06-07 18:26:33

- reply

📅 Original date posted:2020-08-23
📝 Original message:> On Aug 21, 2020, at 13:45, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> This seems to be pretty overengineered.
I agree. In fact all proposals I’ve seen on this are over engineered.
> Do you have a specific use-case in mind for anything more than simply continuing the pattern we've been using of sending a message indicating support for a given feature?
Correct me if I’m wrong, but this pattern is what the proposal aims to eliminate. There is no reason whatsoever for a message per indication. The appropriate pattern is already established in the implementation of service bits. In fact in this discussion it has been pointed out that the problem with service bits is simply too few bits.
> If we find some in the future,
> we could deploy something like this, though the current proposal makes it possible to do it on a per-feature case.
As does any other proposal, including passage of the full set of optional sub-protocols in the verack.
> The great thing about Suhas' proposal is the diff is about -1/+1 (not including tests), while still getting all the flexibility we need.
> Even better, the code already exists.
This is neither true nor relevant. Maybe the Segwit 2X guys should have used this argument.
e
> Matt
>
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> I have a proposal:
>> Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature negotiation.
>> This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be clear that we're acking more than version.
>> I don't care about when or where these messages are sequenced overall, it seems to have minimal impact. If I had free choice, I slightly agree with Eric that verack should come before feature negotiation, as we want to divorce the idea that protocol number and feature support are tied.
>> But once this is done, we can supplant Verack with HANDSHAKENACK or HANDSHAKEACK to signal success or failure to agree on a connection. A NACK reason (version too high/low or an important feature missing) could be optional. Implicit NACK would be disconnecting, but is discouraged because a peer doesn't know if it should reconnect or the failure was intentional.
>> ------
>> AJ: I think I generally do prefer to have a FEATURE wrapper as you suggested, or a rule that all messages in this period are interpreted as features (and may be redundant with p2p message types -- so you can literally just use the p2p message name w/o any data).
>> I think we would want a semantic (which could be based just on message names, but first-class support would be nice) for ACKing that a feature is enabled. This is because a transcript of:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> VERACK
>> NODE1:
>> FEATURE A
>> VERACK
>> It remains unclear if Node 1 ignored B because it's an unknown feature, or because it is disabled. A transcript like:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> FEATURE C
>> ACK A
>> VERACK
>> NODE1:
>> FEATURE A
>> ACK A
>> NACK B
>> VERACK
>> would make it clear that A and B are known, B is disabled, and C is unknown. C has 0 support, B Node 0 should support inbound messages but knows not to send to Node 1, and A has full bilateral support. Maybe instead it could a message FEATURE SEND A and FEATURE RECV A, so we can make the split explicit rather than inferred from ACK/NACK.
>> ------
>> I'd also propose that we add a message which is SYNC, which indicates the end of a list of FEATURES and a request to send ACKS or NACKS back (which are followed by a SYNC). This allows multi-round negotiation where based on the presence of other features, I may expand the set of features I am offering. I think you could do without SYNC, but there are more edge cases and the explicitness is nice given that this already introduces future complexity.
>> This multi-round makes it an actual negotiation rather than a pure announcement system. I don't think it would be used much in the near term, but it makes sense to define it correctly now. Build for the future and all...
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>

2023-06-07 18:26:32

- reply

📅 Original date posted:2020-08-24
📝 Original message:I see no requirement for anything here apart from exchanging a list of supported “features”. Conditionally hiding a feature provides no benefit. Any peer that wants it can get it (obfuscation being weak security), and otherwise it’s a non-issue.
e
> On Aug 24, 2020, at 13:22, Jeremy <jlrubin at mit.edu> wrote:
>
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric at voskuil.org> wrote:
>> I said security, not privacy. You are in fact exposing the feature to any node that wants to negotiate for it. if you don’t want to expose the buggy feature, then disable it. Otherwise you cannot prevent peers from accessing it. Presumably peers prefer the new feature if they support it, so there is no need for this complexity.
>
> I interpreted " This seems to imply a security benefit (I can’t discern any other rationale for this complexity). It should be clear that this is no more than trivially weak obfuscation and not worth complicating the protocol to achieve.", to be about obfuscation and therefore privacy.
>
> The functionality that I'm mentioning might not be buggy, it might just not support peers who don't support another feature. You can always disconnect a peer who sends a message that you didn't handshake on (or maybe we should elbow bump given the times).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/e5e1facc/attachment-0001.html>

2023-06-07 18:26:32

- reply

📅 Original date posted:2020-08-21
📝 Original message:Service bits are advertised, protocol support is not.
https://en.bitcoin.it/wiki/Protocol_documentation#Network_address
e
> On Aug 21, 2020, at 14:08, Jeremy <jlrubin at mit.edu> wrote:
>
>
> Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature support, so this would supercede that.
> --
> @JeremyRubin
>
>
>> On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo <lf-lists at mattcorallo.com> wrote:
>> This seems to be pretty overengineered. Do you have a specific use-case in mind for anything more than simply continuing
>> the pattern we've been using of sending a message indicating support for a given feature? If we find some in the future,
>> we could deploy something like this, though the current proposal makes it possible to do it on a per-feature case.
>>
>> The great thing about Suhas' proposal is the diff is about -1/+1 (not including tests), while still getting all the
>> flexibility we need. Even better, the code already exists.
>>
>> Matt
>>
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> > I have a proposal:
>> >
>> > Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature
>> > negotiation.
>> >
>> > This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be
>> > clear that we're acking more than version.
>> >
>> > I don't care about when or where these messages are sequenced overall, it seems to have minimal impact. If I had free
>> > choice, I slightly agree with Eric that verack should come before feature negotiation, as we want to divorce the idea
>> > that protocol number and feature support are tied.
>> >
>> > But once this is done, we can supplant Verack with HANDSHAKENACK or HANDSHAKEACK to signal success or failure to agree
>> > on a connection. A NACK reason (version too high/low or an important feature missing) could be optional. Implicit NACK
>> > would be disconnecting, but is discouraged because a peer doesn't know if it should reconnect or the failure was
>> > intentional.
>> >
>> > ------
>> >
>> > AJ: I think I generally do prefer to have a FEATURE wrapper as you suggested, or a rule that all messages in this period
>> > are interpreted as features (and may be redundant with p2p message types -- so you can literally just use the p2p
>> > message name w/o any data).
>> >
>> > I think we would want a semantic (which could be based just on message names, but first-class support would be nice) for
>> > ACKing that a feature is enabled. This is because a transcript of:
>> >
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > VERACK
>> >
>> > NODE1:
>> > FEATURE A
>> > VERACK
>> >
>> > It remains unclear if Node 1 ignored B because it's an unknown feature, or because it is disabled. A transcript like:
>> >
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > FEATURE C
>> > ACK A
>> > VERACK
>> >
>> > NODE1:
>> > FEATURE A
>> > ACK A
>> > NACK B
>> > VERACK
>> >
>> > would make it clear that A and B are known, B is disabled, and C is unknown. C has 0 support, B Node 0 should support
>> > inbound messages but knows not to send to Node 1, and A has full bilateral support. Maybe instead it could a message
>> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit rather than inferred from ACK/NACK.
>> >
>> >
>> > ------
>> >
>> > I'd also propose that we add a message which is SYNC, which indicates the end of a list of FEATURES and a request to
>> > send ACKS or NACKS back (which are followed by a SYNC). This allows multi-round negotiation where based on the presence
>> > of other features, I may expand the set of features I am offering. I think you could do without SYNC, but there are more
>> > edge cases and the explicitness is nice given that this already introduces future complexity.
>> >
>> > This multi-round makes it an actual negotiation rather than a pure announcement system. I don't think it would be used
>> > much in the near term, but it makes sense to define it correctly now. Build for the future and all...
>> >
>> >
>> >
>> > --
>> > @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200821/f8dbf6e4/attachment.html>

2023-06-07 18:26:31

- reply

📅 Original date posted:2020-08-24
📝 Original message:I said security, not privacy. You are in fact exposing the feature to any node that wants to negotiate for it. if you don’t want to expose the buggy feature, then disable it. Otherwise you cannot prevent peers from accessing it. Presumably peers prefer the new feature if they support it, so there is no need for this complexity.
e
> On Aug 24, 2020, at 12:59, Jeremy <jlrubin at mit.edu> wrote:
>
>
>>
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but for old nodes you'll still do it if B is unknown to them.
>>
>> This seems to imply a security benefit (I can’t discern any other rationale for this complexity). It should be clear that this is no more than trivially weak obfuscation and not worth complicating the protocol to achieve.
>
>
> The benefit is not privacy oriented and I didn't intend to imply as such. The benefit is that you may only wish to expose functionality to peers which support some other set of features. For example, with wtxid relay, I might want to expose some additional functionality after establishing my peer supports it, that peers which do not have wtxid relay should not be allowed to use. The benefit over just exposing all functions is then a node might be programmed to support the new feature but not wtxid relay, which can lead to some incompatibilities.
>
> You cannot implement this logic as a purely post-hoc "advertise all and then figure out what is allowed" because then you require strict consistency between peers of that post-hoc feature availability implication map.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/edfe09fb/attachment.html>

2023-06-07 18:26:30

- reply

📅 Original date posted:2020-08-23
📝 Original message:> On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> Hmm, could that not be accomplished by simply building this into new messages? eg, send "betterprotocol", if you see a verack and no "betterprotocol" from your peer, send "worseprotocol" before you send a "verack".
>
> Matt
>
>> On 8/21/20 5:17 PM, Jeremy wrote:
>> As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but for old nodes you'll still do it if B is unknown to them.
This seems to imply a security benefit (I can’t discern any other rationale for this complexity). It should be clear that this is no more than trivially weak obfuscation and not worth complicating the protocol to achieve.
>> An example of this would be (were it not already out without a feature negotiation existing) WTXID/TXID relay.
>> The SYNC primitve simply codifies what order messages should be in and when you're done for a phase of negotiation offering something. It can be done without, but then you have to be more careful to broadcast in the correct order and it's not clear when/if you should wait for more time before responding.
>> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin at mit.edu <mailto:jlrubin at mit.edu>> wrote:
>> Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature
>> support, so this would supercede that.
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>

2023-06-07 18:26:28

- reply

📅 Original date posted:2020-08-21
📝 Original message:I’m pretty sure one can run whatever they want even without a BIP. There is nobody here to do any “allowing”. On the other hand, standards development is tedious for good reason.
Generally speaking, overloading is a primary source of complexity (creating more branches in code and human explanation). Nevertheless this is verack payload, no additional messages are necessary or helpful.
e
> On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Sure, we could do a new message for negotiation, but there doesn’t seem to be a lot of reason for it - using the same namespace for negotiation seems fine too. In any case, this is one of those things that doesn’t matter in the slightest, and if one person volunteers to write a BIP and code, no reason they shouldn’t just decide and be allowed to run with it. Rough consensus and running code, as it were :)
>
> Matt
>
>
>>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote:
>>> In thinking about the mechanism used there, I thought it would be helpful to
>>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>>> messages received before a VERACK. A draft of my proposal is available here
>>> [2].
>>
>> Rather than allowing arbitrary messages, maybe it would make sense to
>> have a specific feature negotiation message, eg:
>>
>> VERSION ...
>> FEATURE wtxidrelay
>> FEATURE packagerelay
>> VERACK
>>
>> with the behaviour being that it's valid only between VERSION and VERACK,
>> and it takes a length-prefixed-string giving the feature name, optional
>> additional data, and if the feature name isn't recognised the message
>> is ignored.
>>
>> If we were to support a "polite disconnect" feature like Jeremy suggested,
>> it might be easier to do that for a generic FEATURE message, than
>> reimplement it for the message proposed by each new feature.
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> 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

2023-06-07 18:26:28

- reply

📅 Original date posted:2020-08-21
📝 Original message:Hi Anthony,
This is what I was implying in my last post (the reference to the unnecessary overload of message typing). However, if one imagines a sequence diagram for this communication it becomes obvious that all such messages are 100% redundant with verack.
e
> On Aug 20, 2020, at 19:37, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote:
>> In thinking about the mechanism used there, I thought it would be helpful to
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>> messages received before a VERACK. A draft of my proposal is available here
>> [2].
>
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
>
> VERSION ...
> FEATURE wtxidrelay
> FEATURE packagerelay
> VERACK
>
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
>
> If we were to support a "polite disconnect" feature like Jeremy suggested,
> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:26:27

- reply

📅 Original date posted:2020-08-18
📝 Original message:> On Aug 18, 2020, at 11:25, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> On 8/18/20 2:11 PM, Eric Voskuil wrote:
> - snip -
>>> Still, I think we're talking pedantics here, and not in a useful way.
>> Not to be pedantic, but I don’t know what that means.
>
> It means that part of the discussion is not useful, and not worth bothering to go back and figure out what was shipped before the version increase and what wasn't, lets talk about what makes sense for the future :).
When the discussion centers on backward compatibility, and there is confusion over what that actually implies, this is a central question. You snipped the bit about what actually constitutes the existing protocol. I have implemented every aspect of the protocol that is widely deployed, and I can say without question that the protocol does not require a peer to accept arbitrary messages. In other words, your statement on the subject was a very relevant factual error. Furthermore no reason has been demonstrated here to accept arbitrary traffic.
>>> Ultimately we need some kind of negotiation which is flexible in allowing different software to negotiate different features without a global lock-step version number increase.
>> I have shown below how that already works.
>>> Or, to put it another way, if a feature is fully optional, why should there be a version number increase for it
>> For the reasons previously given.
>>> - the negotiation of it is independent and a version number only increases confusion over which change "owns" a given version number.
>> Presumably this is why we have a standards process. Any new message implies ownership. Deconflicting that is required, which implies it can easily be version associated (as it has been).
>
> I think the point is, this doesn't work today, bumping the protocol version requires everyone agreeing on which features make sense,
As I have shown, this is not the case. While I have given my support to simplifying the process, we should not proceed based on an incorrect understanding of actual behavior.
> and as we can see from this email thread alone, that isn't a common result in this community. People happily ignore BIPs that make no sense, of which there are a lot, and they should totally be able to do that!
>
> You can say that the current world works, but there's a reason over time we've shifted away from the original "shove another bit on the end of the version message, and everyone agrees on the order of those bits for new feature negotiation." Version bumping is an extension of that, really.
Actually the protocol has not done this. It has used the version to signal a new sub-protocol, and then in some cases that sub-protocol has been made optional through subsequent negotiation. What is being proposed here is to simplify that process by collapsing the secondary negotiation into the handshake.
In fact I argued against this secondary ad-hoc negotiation when it began. Now we are coming around to recognizing that it’s a handshake issue, as I said at the time. I’m glad to see that.
>>> I presume you'd support a single message that lists the set of features which a node (optionally) wishes to support on the connection. This proposal is fully equivalent to that, instead opting to list them as individual messages instead of one message, which is a bit nicer in that they can be handled more independently or by different subsystems including even the message hashing.
>> This presumes an implementation. As part of the handshake, collection of an arbitrary set of messages is a significant and unnecessary complication *of the protocol*. Extension of the verack is not. It is the simplest change possible to implement the desired behavior. Each peer simply supplies the matrix of sub-protocols it supports and only those supported by both are allowed. There is no reason for the protocol to split that matrix up into multiple messages, requiring termination. Independent messages exist because of timing or ordering requirements. Implementing dependent messages as if they were independent is wasteful and complicating.
>
> Some things may need further negotiation. eg compact blocks sends multiple redundant messages with different versions and then deduces the correct version based on the message ordering and version set supported. Doing this via verack locks you into a very specific possible negotiation protocols.
This is a moot point. Whether a list of supported optional sub-protocols is listed in one or multiple messages in the handshake would not change this.
> You could extend it further and suggest a verack K-V list which allows for more flexible negotiation, but I'm not sure that it isn't more complicated than just shoving more messages on the wire.
There is no difference between a constrained set of key-value pairs and a distinct set of options, so there is no additional complexity here.
>> I’m well aware of the inefficiency produced by version linearity in the face of optional sub-protocols. The protocol must negotiate to the version where it can then negotiate support, which has been done. I support creating a simpler system, eliminating these extra messages. The existing numeric version can be reserved exclusively for “must” implement, and can be used to signal an extension to the verack. The verack can then carry a list of “may” or “should” sub-protocols for final negotiation.
>
> I think we agree here - the current method of protocol version bumping isn't scalable and something more flexible is definitely a better world.
To be clear this does not increase flexibility, it reduces communication and therefore complexity, and allows peers to lock in allowed message semantics by the end of the handshake, as opposed to allowing them to change at any time.
>> The format of the matrix is arbitrary, but the requirement is to list a set of optional sub-protocols. This implies a namespace. This implies “ownership“ of names. In other words, that coordination requirement is not eliminated.
>
> This is true, there is some ownership requirement, we could switch to hashes or something of the like, but human-readable names have shown to be relatively non-colliding in past Bitcoin protocol changes.
Hashes don’t prevent collisions. Someone can just use the same hash. Bitcoin uses names (message names) and numbers (version, service, relay...). It’s a protocol, coordination is the whole point.
e
>> e
>>> Matt
>>>
>>>> On 8/18/20 12:54 PM, Eric Voskuil wrote:
>>>> “Bitcoin protocol has always expected clients to ignore unknown messages”
>>>> This is not true. Bitcoin has long implemented version negotiation, which is the opposite expectation. Libbitcoin’s p2p protocol implementation immediately drops a peer that sends an invalid message according to the negotiated version. The fact that a given client does not validate the protocol does not make it an expectation that the protocol not be validated.
>>>> Features can clearly be optional within an actual protocol. There have been post-handshake negotiations implemented for optional messages which are valid at the negotiated version. The protocol may be flexible while remaining validateable. There is no reason to force a client to accept unknown message traffic.
>>>> A generalized versioning change can be implemented in or after the handshake. The latter is already done on an ad-hoc basis. The former is possible as long as the peer’s version is sufficient to be aware of the behavior. This does not imply any need to send invalid messages. The verack itself can simply be extended with a matrix of feature support. There is no reason to complicate negotiation with an additional message(s).
>>>> FWIW, bip37 did this poorly, adding a feature field to the version message, resulting in bip60. Due to this design, older protocol-validating clients were broken. In this case it was message length that was presumed to not be validated.
>>>> e
>>>>>> On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> This sounds like a great idea!
>>>>>
>>>>> Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each. The Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially the Bitcoin protocol had a simple numerical version field, but that is wholly impractical for any diverse network - some clients may not wish to implement every possible new relay mechanic, and why should they have to in order to use other new features?
>>>>>
>>>>> Bitcoin protocol changes have, many times in recent history, been made via new dummy "negotiation" messages, which take advantage of the fact that the Bitcoin protocol has always expected clients to ignore unknown messages. Given that pattern, it makes sense to have an explicit negotiation phase - after version and before verack, just send the list of features that you support to negotiate what the connection will be capable of. The exact way we do that doesn't matter much, and sending it as a stream of messages which each indicate support for a given protocol feature perfectly captures the pattern that has been used in several recent network upgrades, keeping consistency.
>>>>>
>>>>> Matt
>>>>>
>>>>> On 8/14/20 3:28 PM, Suhas Daftuar via bitcoin-dev wrote:
>>>>>> Hi,
>>>>>> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>>>>>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>>>>>> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>>>>>> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding that this is the standard of how other network clients operate would be helpful.
>>>>>> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
>>>>>> Thanks,
>>>>>> Suhas Daftuar
>>>>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html>
>>>>>> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki <https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki>
>>>>>> _______________________________________________
>>>>>> 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

2023-06-07 18:26:26

- reply

📅 Original date posted:2020-08-18
📝 Original message:> On Aug 18, 2020, at 10:26, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> There are several cases where a new message has been sent as a part of a negotiation without changing the protocol version.
Such as?
> You may chose to ignore that, but that doesn't mean that it isn't an understood and even relied upon feature of the Bitcoin P2P protocol. If you wish to fail connections to new nodes (and risk network splits, as Suhas points out), then you may do so, but that doesn't make it a part of the Bitcoin P2P protocol that you must do so. Of course there is no "official document" by which we can make a formal appeal, but historical precedent suggests otherwise.
You are misrepresenting “historical precedent”. I’ve seen several attempts to require arbitrary traffic over the years and none have been realized.
> Still, I think we're talking pedantics here, and not in a useful way.
Not to be pedantic, but I don’t know what that means.
> Ultimately we need some kind of negotiation which is flexible in allowing different software to negotiate different features without a global lock-step version number increase.
I have shown below how that already works.
> Or, to put it another way, if a feature is fully optional, why should there be a version number increase for it
For the reasons previously given.
> - the negotiation of it is independent and a version number only increases confusion over which change "owns" a given version number.
Presumably this is why we have a standards process. Any new message implies ownership. Deconflicting that is required, which implies it can easily be version associated (as it has been).
> I presume you'd support a single message that lists the set of features which a node (optionally) wishes to support on the connection. This proposal is fully equivalent to that, instead opting to list them as individual messages instead of one message, which is a bit nicer in that they can be handled more independently or by different subsystems including even the message hashing.
This presumes an implementation. As part of the handshake, collection of an arbitrary set of messages is a significant and unnecessary complication *of the protocol*. Extension of the verack is not. It is the simplest change possible to implement the desired behavior. Each peer simply supplies the matrix of sub-protocols it supports and only those supported by both are allowed. There is no reason for the protocol to split that matrix up into multiple messages, requiring termination. Independent messages exist because of timing or ordering requirements. Implementing dependent messages as if they were independent is wasteful and complicating.
I’m well aware of the inefficiency produced by version linearity in the face of optional sub-protocols. The protocol must negotiate to the version where it can then negotiate support, which has been done. I support creating a simpler system, eliminating these extra messages. The existing numeric version can be reserved exclusively for “must” implement, and can be used to signal an extension to the verack. The verack can then carry a list of “may” or “should” sub-protocols for final negotiation.
The format of the matrix is arbitrary, but the requirement is to list a set of optional sub-protocols. This implies a namespace. This implies “ownership“ of names. In other words, that coordination requirement is not eliminated.
e
> Matt
>
>> On 8/18/20 12:54 PM, Eric Voskuil wrote:
>> “Bitcoin protocol has always expected clients to ignore unknown messages”
>> This is not true. Bitcoin has long implemented version negotiation, which is the opposite expectation. Libbitcoin’s p2p protocol implementation immediately drops a peer that sends an invalid message according to the negotiated version. The fact that a given client does not validate the protocol does not make it an expectation that the protocol not be validated.
>> Features can clearly be optional within an actual protocol. There have been post-handshake negotiations implemented for optional messages which are valid at the negotiated version. The protocol may be flexible while remaining validateable. There is no reason to force a client to accept unknown message traffic.
>> A generalized versioning change can be implemented in or after the handshake. The latter is already done on an ad-hoc basis. The former is possible as long as the peer’s version is sufficient to be aware of the behavior. This does not imply any need to send invalid messages. The verack itself can simply be extended with a matrix of feature support. There is no reason to complicate negotiation with an additional message(s).
>> FWIW, bip37 did this poorly, adding a feature field to the version message, resulting in bip60. Due to this design, older protocol-validating clients were broken. In this case it was message length that was presumed to not be validated.
>> e
>>>> On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> This sounds like a great idea!
>>>
>>> Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each. The Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially the Bitcoin protocol had a simple numerical version field, but that is wholly impractical for any diverse network - some clients may not wish to implement every possible new relay mechanic, and why should they have to in order to use other new features?
>>>
>>> Bitcoin protocol changes have, many times in recent history, been made via new dummy "negotiation" messages, which take advantage of the fact that the Bitcoin protocol has always expected clients to ignore unknown messages. Given that pattern, it makes sense to have an explicit negotiation phase - after version and before verack, just send the list of features that you support to negotiate what the connection will be capable of. The exact way we do that doesn't matter much, and sending it as a stream of messages which each indicate support for a given protocol feature perfectly captures the pattern that has been used in several recent network upgrades, keeping consistency.
>>>
>>> Matt
>>>
>>> On 8/14/20 3:28 PM, Suhas Daftuar via bitcoin-dev wrote:
>>>> Hi,
>>>> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>>>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>>>> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>>>> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding that this is the standard of how other network clients operate would be helpful.
>>>> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
>>>> Thanks,
>>>> Suhas Daftuar
>>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html>
>>>> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki <https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki>
>>>> _______________________________________________
>>>> 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

2023-06-07 18:26:25

- reply

📅 Original date posted:2020-08-18
📝 Original message:“Bitcoin protocol has always expected clients to ignore unknown messages”
This is not true. Bitcoin has long implemented version negotiation, which is the opposite expectation. Libbitcoin’s p2p protocol implementation immediately drops a peer that sends an invalid message according to the negotiated version. The fact that a given client does not validate the protocol does not make it an expectation that the protocol not be validated.
Features can clearly be optional within an actual protocol. There have been post-handshake negotiations implemented for optional messages which are valid at the negotiated version. The protocol may be flexible while remaining validateable. There is no reason to force a client to accept unknown message traffic.
A generalized versioning change can be implemented in or after the handshake. The latter is already done on an ad-hoc basis. The former is possible as long as the peer’s version is sufficient to be aware of the behavior. This does not imply any need to send invalid messages. The verack itself can simply be extended with a matrix of feature support. There is no reason to complicate negotiation with an additional message(s).
FWIW, bip37 did this poorly, adding a feature field to the version message, resulting in bip60. Due to this design, older protocol-validating clients were broken. In this case it was message length that was presumed to not be validated.
e
> On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> This sounds like a great idea!
>
> Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each. The Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially the Bitcoin protocol had a simple numerical version field, but that is wholly impractical for any diverse network - some clients may not wish to implement every possible new relay mechanic, and why should they have to in order to use other new features?
>
> Bitcoin protocol changes have, many times in recent history, been made via new dummy "negotiation" messages, which take advantage of the fact that the Bitcoin protocol has always expected clients to ignore unknown messages. Given that pattern, it makes sense to have an explicit negotiation phase - after version and before verack, just send the list of features that you support to negotiate what the connection will be capable of. The exact way we do that doesn't matter much, and sending it as a stream of messages which each indicate support for a given protocol feature perfectly captures the pattern that has been used in several recent network upgrades, keeping consistency.
>
> Matt
>
>> On 8/14/20 3:28 PM, Suhas Daftuar via bitcoin-dev wrote:
>> Hi,
>> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding that this is the standard of how other network clients operate would be helpful.
>> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
>> Thanks,
>> Suhas Daftuar
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html>
>> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki <https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki>
>> _______________________________________________
>> 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/20200818/bf38200b/attachment-0001.html>

2023-06-07 18:26:24

- reply

📅 Original date posted:2020-08-17
📝 Original message:Hi Suhas,
It seems to me that your first two paragraphs contradict each other, so I’m not sure we have understanding. As you say in the first paragraph, a peer would never get messages that it does not understand, so there is no chance that missing a protocol change would matter.
In case it’s not understood, version negotiation provides each peer with the maximum supported protocol version of the other. Once complete both have negotiated to the highest common version. No message not supported at that version may be sent by either.
If the protocol was to accept *any* message traffic then it will cease to be a protocol. People will drop in their changes without obtaining broad support, and peers will evolve to the point of no longer being peers. They won’t speak the same language and the “network” will be little more than a broadcast transport, broadcasting all traffic to all peers, whether it’s for them or not.
People need to either build support or build a distinct network. That’s the actual coordination issue, which is inherent to protocol development.
Best,
e
> On Aug 17, 2020, at 13:40, Suhas Daftuar <sdaftuar at gmail.com> wrote:
>
> Hi Eric,
>
> Thanks for your response. If I understand correctly, you're suggesting that in the future we do the same as what was done in BIP 339, of accompanying new messages (which are optional) with a protocol version bump, so that network clients are never reading unknown messages from a peer (and can be free to disconnect a peer for sending an unknown message)?
>
> I think that works fine, so if indeed there will be software that will expect things to operate this way then I can withdraw the suggestion I've made in this thread. However I wanted to clarify that this is what you suggest, because there is another downside to this approach (beyond the sequential nature of sequence numbers that you mention) -- if a software implementation misses a proposed new protocol upgrade, and thus fails to parse (and ignore) some proposed new message, the result can be a network split down the road as incompatible clients get slowly upgraded over time.
>
> I think this coordination cost is something to be concerned about -- for instance, the lack of response to my wtxid-relay proposal made me wonder if other software would be implementing something to account for the new message that proposal introduces (for clients with version >= 70016). It's reasonable for people to be busy and miss things like this, and I think it's worth considering whether there's a safer way for us to deploy changes.
>
> That said, I don't think this coordination cost is unbearable, so as long as we have a process for making p2p protocol improvements I'm not too worried about what mechanism we use. So if this concern over coordination of changes doesn't sway you, I think we can continue to just bump protocol version at the same time as deploying new messages, as we have been doing, and hope that we don't run into problems down the road.
>
> If I have misunderstood how you think we should be making future protocol changes, please let me know.
>
> Thanks,
> Suhas
>
>
>
>> On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil <eric at voskuil.org> wrote:
>> A requirement to ignore unknown (invalid) messages is not only a protocol breaking change but poor protocol design. The purpose of version negotiation is to determine the set of valid messages. Changes to version negotiation itself are very problematic.
>>
>> The only limitation presented by versioning is that the system is sequential. As such, clients that do not wish to implement (or operators who do not wish to enable) them are faced with a problem when wanting to support later features. This is resolvable by making such features optional at the new protocol level. This allows each client to limit its communication to the negotiated protocol, and allows ignoring of known but unsupported/disabled features.
>>
>> Sorry I missed your earlier post. Been distracted for a while.
>>
>> e
>>
>>
>>>> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>
>>> Hi,
>>>
>>> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>>>
>>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>>>
>>> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>>>
>>> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding that this is the standard of how other network clients operate would be helpful.
>>>
>>> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
>>>
>>> Thanks,
>>> Suhas Daftuar
>>>
>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>>>
>>> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
>>> _______________________________________________
>>> 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/20200817/e1288ac9/attachment-0001.html>

2023-06-07 18:26:23

- reply

📅 Original date posted:2020-08-16
📝 Original message:A requirement to ignore unknown (invalid) messages is not only a protocol breaking change but poor protocol design. The purpose of version negotiation is to determine the set of valid messages. Changes to version negotiation itself are very problematic.
The only limitation presented by versioning is that the system is sequential. As such, clients that do not wish to implement (or operators who do not wish to enable) them are faced with a problem when wanting to support later features. This is resolvable by making such features optional at the new protocol level. This allows each client to limit its communication to the negotiated protocol, and allows ignoring of known but unsupported/disabled features.
Sorry I missed your earlier post. Been distracted for a while.
e
> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hi,
>
> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>
> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>
> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>
> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding that this is the standard of how other network clients operate would be helpful.
>
> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
>
> Thanks,
> Suhas Daftuar
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>
> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> 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/20200816/1813852d/attachment-0001.html>

2023-06-07 18:23:28

- reply

📅 Original date posted:2020-03-22
📝 Original message:Mining is a lottery.
e
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> There seems to be the real possibility that miners are simply trying to optimise mining profit by limiting the average hash rate during the retargeting, saving some electricity but poorly considering the overall situation where they give opportunity to other miners probably raising the hashrate for the next period. It is far more profitable for the ecosystem considering the whole to hold a lottery for minig as has been discussed elsewhere some time ago.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Sunday, 22 March 2020 6:54 PM
> To: Dave Scotese <dscotese at litmocracy.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
>
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons. I'm
> > curious to know if anyone has ideas on how this might be handled
>
> There are only two practical solutions I'm aware of:
>
> 1. Do nothing
> 2. Hard fork a difficulty reduction
>
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
>
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
>
> -Dave
> _______________________________________________
> 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/20200322/25b0e225/attachment.html>

2023-06-07 18:21:36

- reply

📅 Original date posted:2019-11-08
📝 Original message:> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev wrote:
>> In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>> insertion or erasure would result in an output that can be spent by
>> anyone. If that is considered unacceptable, it could be prevented by
>> for example outlawing v1 witness outputs of length 31 and 33.
>
> Either a consensus rule or a standardness rule[1] would require anyone
> using a bech32 library supporting v1+ segwit to upgrade their library.
> Otherwise, users of old libraries will still attempt to pay v1 witness
> outputs of length 31 or 33, causing their transactions to get rejected
> by newer nodes or get stuck on older nodes. This is basically the
> problem #15846[2] was meant to prevent.
>
> If we're going to need everyone to upgrade their bech32 libraries
> anyway, I think it's probably best that the problem is fixed in the
> bech32 algorithm rather than at the consensus/standardness layer.
As an implementer of both the address encoding and script validation, I agree.
e
> -Dave
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017444.html
> [2] https://github.com/bitcoin/bitcoin/pull/15846
>
> P.S. My thanks as well to the people who asked the question during
> review that lead to this discussion:
>
> http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html#l-88
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:21:19

- reply

📅 Original date posted:2019-10-21
📝 Original message:Hi Lucas,
You are assuming that all miners operate at equal efficiency. The least efficient miners are expected to drop offline first. Even with identical hardware and operational efficiency, the necessary variance discount and proximity premium create a profitability spread. The relation between hash rate and reward value is not only predictable, it is easily observed.
There is an error in your sold hardware scenario. When equipment is sold at a loss, the remaining operating miners have a reduced capital cost, which means, despite higher hash rate, miners are profitable. The least efficient miners have written down their expected losses and hash rate becomes consistent with market returns despite being higher.
With respect to the contract, I don’t yet see this working, but there are several gaps and I don’t want to make assumptions. More detailed specification would be helpful. Even a full scenario with numbers and justifications would be something.
e
> On Oct 20, 2019, at 14:33, Lucas H <lucash.dev at gmail.com> wrote:
>
> Sorry, Eric, but I think you're completely missing the point.
>
> It has nothing to do with sunken cost -- but the fact that the mining equipment is good for nothing else other than performing hashing operations.
> As long as someone can get paid more than they spend to keep the equipment running, i.e. P>0, it will keep running.
> Your argument only makes sense in an ASIC-free world.
>
> Let's assume you decide to just shut down your whole operation. In that scenario, it doesn't make sense *not* to sell your equipment, even at a loss. Just destroying it makes no economic sense: your loss would be much worse. So you'll sell it -- at a loss -- to someone who will buy it at a price that will make *their* ROI>0 for keeping the equipment running -- and the equipment *will* be again running, and *will* keep the hashrate high. Only consequence of you shutting down your operation is you taking a loss.
>
> Even if you sell it to someone who will run it exactly as efficiently as you, or even at lower efficiency (as long as P>0), they'll just pay less for the equipment than you did, their ROI will be >0 and you'll bear the loss. No drop in hashrate.
>
> Hashrate can only respond to mining being unprofitable in the sense "P" -- not in the sense "ROI". But a miner can still go bankrupt even if P>0.
>
> Please note that none of the above breaks the economic assumptions of the protocol. The problem I'm talking about isn't a problem in the protocol, but a problem for miners -- and it's the same as in many kinds of economic activity.
>
> Consider investing in building an oil refinery -- if the price of the refined products get lower than expected to pay for the capital, but still high enough to pay for operating costs, you'd rather keep it running (or sell to someone who will keep it running) than just sell the parts as scrap metal. In that case you might want to protect yourself against the price of the refined products going too low.
>
> Of course miners can (and maybe already do) hedge against these scenarios using other kinds of instruments -- most likely facilitated by a trusted 3rd party. I'm just interested in the possibility of a new, trustless instrument.
>
> *Anyway* I'm far more interested in the technical feasibility of the contract, given the economic assumptions, than it's economic practicality in the present.
>
>
>
>
>
>>> On Sun, Oct 20, 2019 at 1:17 PM Eric Voskuil <eric at voskuil.org> wrote:
>>> Hi Lucas,
>>>
>>> This can all be inferred from the problem statement. In other words this doesn’t change the assumptions behind my comments. However this is an unsupportable assumption:
>>>
>>> “Difficulty would only go down in this case at the end of life of these equipment, if there isn't a new wave of even more efficient equipment being adopted before that.”
>>>
>>> Operating at a loss would only be justifiable in the case of expected future returns, not due to sunk costs.
>>>
>>> e
>>>
>>>> On Oct 20, 2019, at 15:46, Lucas H <lucash.dev at gmail.com> wrote:
>>>>
>>>
>>> Hi, guys.
>>>
>>> Thanks a lot for taking the time to read and discuss my post.
>>>
>>> I definitely wasn't clear enough about the problem statement -- so let me try to clarify my thinking.
>>>
>>> First, the main uncertainty the miner is trying to protect against isn't the inefficiency of his new equipment, but how much new mining equipment is being deployed world-wide, which he can't know in advance (as the system is permissionless).
>>>
>>> Second, there are two different metrics that can mean "profitable" that I think are getting confused (probably my fault for lack of using the right terms).
>>>
>>> - Let's call it "operational profitability", and use "P" to denote it, where P = [bitcoin earned]/time - [operational cost of running equipment]/time.
>>> Obviously if P < 0, the miner will just shut down his equipment.
>>> - Return on investment (ROI). A positive ROI requires not just that P > 0, but that it is enough to compensate for the initial investment of buying or building the equipment. As long as P > 0, a miner will keep his equipment running, even at a negative ROI, as the alternative would be an even worse negative ROI. Sure he can sell it, but however buys it will also keep it running, otherwise the equipment is worthless.
>>>
>>> The instrument I describe above protects against the scenario where P > 0, but ROI < 0.
>>> (it's possible it could be useful in some cases to protect against P < 0, but that's not my main motivator and isn't an assumption)
>>>
>>> If too many miners are deploying too much new equipment at the same time, it's possible that your ROI becomes negative, while nobody shuts down their equipment and the difficulty still keeps going up. In fact, it is possible for all miners to have negative ROI for a while without a reduction in difficulty. Difficulty would only go down in this case at the end of life of these equipment, if there isn't a new wave of even more efficient equipment
>>> being adopted before that.
>>>
>>> Let's see a simplified scenario in which the insurance becomes useful. This is just one example, and other scenarios could also work.
>>>
>>> - Bitcoin price relatively constant, that is, it's not the main driver of P during this period.
>>> - Approximately constant block rewards.
>>> - New equipment comes to market with much higher efficiency than all old equipment. So the old stock of old equipment becomes irrelevant after a short while.
>>> - All miners decide to deploy new equipment, but none knows how much the others are deploying, or when, or at what price or P.
>>> - Let's just assume P>0 for all miners using the new equipment.
>>> - Let's assume every unit of the new equipment runs at the same maximum hashrate it's capable of.
>>>
>>> Let's say miner A buys Na units of the new equipment and the total number deployed by all miners is N.
>>>
>>> A's share of the block rewards will be Na / N.
>>>
>>> If N is much higher than A's initial estimate, his ROI might well become negative, and the insurance would help him prevent a loss.
>>>
>>> Hope this makes the problem a bit clearer.
>>>
>>> Thanks!
>>> @lucash-dev
>>>
>>>> On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <eric at voskuil.org> wrote:
>>>> So we are talking about a miner insuring against his own inefficiency.
>>>>
>>>> Furthermore a disproportionate increase in hash rate is based on the expectation of higher future return (investment leads returns). So the insurance could end up paying out against realized profit.
>>>>
>>>> Generally speaking, insuring investment is a zero sum game.
>>>>
>>>> e
>>>>
>>>> > On Oct 20, 2019, at 12:10, JW Weatherman <jw at mathbot.com> wrote:
>>>> >
>>>> > Oh, I see your point.
>>>> >
>>>> > However the insurance contract would protect the miner even in that case. A miner with great confidence that he is running optimal hardware and has optimal electricity and labor costs probably wouldn't be interested in purchasing insurance for a high price, but if it was cheap enough it would still be worth it. And any potential new entrants on the edge of jumping in would enter when they otherwise would not have because of the decreased costs (decreased risk).
>>>> >
>>>> > An analogy would be car insurance. If you are an excellent driver you wouldn't be willing to spend a ton of money to protect your car in the event of an accident, but if it is cheap enough you would. And there may be people that are unwilling to take the risk of a damaged car that refrain from becoming drivers until insurance allows them to lower the worst case scenario of a damaged car.
>>>> >
>>>> > -JW
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>> >> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <eric at voskuil.org> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>>> On Oct 20, 2019, at 10:10, JW Weatherman jw at mathbot.com wrote:
>>>> >>> I think the assumption is not that all miners are unprofitable, but that a single miner could make an investment that becomes unprofitable if the hash rate increases more than he expected.
>>>> >>
>>>> >> This is a restatement of the assumption I questioned. Hash rate increase does not imply unprofitability. The new rig should be profitable.
>>>> >>
>>>> >> What is being assumed is a hash rate increase without a proportional block reward value increase. In this case if the newest equipment is unprofitable, all miners are unprofitable.
>>>> >>
>>>> >>> Depending on the cost of the offered insurance it would be prudent for a miner to decrease his potential loss by buying insurance for this possibility.
>>>> >>> And the existence of attractive insurance contracts would lower the barrier to entry for new competitors in mining and this would increase bitcoins security.
>>>> >>> -JW
>>>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>> >>>
>>>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>> >>>> Hi Lucas,
>>>> >>>> I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed in the case of subsequently increasing hash rate.
>>>> >>>> The assumption of increasing hash rate implies an expectation of increasing return on investment. There are certainly speculative errors, but a loss on new equipment implies all miners are operating at a loss, which is not a sustainable situation.
>>>> >>>> If any miner is profitable it is the miner with the new equipment, and if he is not, hash rate will drop until he is. This drop is most likely to be precipitated by older equipment going offline.
>>>> >>>> Best,
>>>> >>>> Eric
>>>> >>>>
>>>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>> >>>>>> Hi,
>>>> >>>>>> This is my first post to this list -- even though I did some tiny contributions to bitcoin core I feel quite a beginner -- so if my idea is stupid, already known, or too off-topic, just let me know.
>>>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitability of a mining operation -- in case Bitcoin/hash price goes too low. It can be trustless bc we can use the assumption that the price of hashing is low to unlock funds.
>>>> >>>>>> The problem:
>>>> >>>>>> A miner invests in new mining equipment, but if the hash-rate goes up too much (the price he is paid for a hash goes down by too much) he will have a loss.
>>>> >>>>>> Solution: trustless hash-price insurance contract (or can we call it an option to sell hashes at a given price?)
>>>> >>>>>> An insurer who believes that it's unlikely the price of a hash will go down a lot negotiates a contract with the miner implemented as a Bitcoin transaction:
>>>> >>>>>> Inputs: a deposit from the insurer and a premium payment by the miner
>>>> >>>>>> Output1: simply the premium payment to the insurer
>>>> >>>>>> Output2 -- that's the actual insurance
>>>> >>>>>> There are three OR'ed conditions for paying it:
>>>> >>>>>> A. After expiry date (in blocks) insurer can spend
>>>> >>>>>> B. Both miner and insurer can spend at any time by mutual agreement
>>>> >>>>>> C. Before expiry, miner can spend by providing a pre-image that produces a hash within certain difficulty constraints
>>>> >>>>>> The thing that makes it a hash-price insurance (or option, pardon my lack of precise financial jargon), is that if hashing becomes cheap enough, it becomes profitable to spend resources finding a suitable pre-image, rather than mining Bitcoin.
>>>> >>>>>> Of course, both parties can reach an agreement that doesn't require actually spending these resources -- so the miner can still mine Bitcoin and compensate for the lower-than-expected reward with part of the insurance deposit.
>>>> >>>>>> If the price doesn't go down enough, the miner just mines Bitcoin and the insurer gets his deposit back.
>>>> >>>>>> It's basically an instrument for guaranteeing a minimum profitability of the mining operation.
>>>> >>>>>> Implementation issues: unfortunately we can't do arithmetic comparison with long integers >32bit in the script, so implementation of the difficulty requirement needs to be hacky. I think we can use the hashes of one or more pre-images with a given short length, and the miner has to provide the exact pre-images. The pre-images are chosen by the insurer, and we would need a "honesty" deposit or other mechanism to punish the insurer if he chooses a hash that doesn't correspond to any short-length pre-image. I'm not sure about this implementation though, maybe we actually need new opcodes.
>>>> >>>>>> What do you guys think?
>>>> >>>>>> Thanks for reading it all! Hope it was worth your time!
>>>> >>>>>
>>>> >>>>> 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/20191020/5b027844/attachment-0001.html>

2023-06-07 18:21:18

- reply

📅 Original date posted:2019-10-20
📝 Original message:Hi Lucas,
This can all be inferred from the problem statement. In other words this doesn’t change the assumptions behind my comments. However this is an unsupportable assumption:
“Difficulty would only go down in this case at the end of life of these equipment, if there isn't a new wave of even more efficient equipment being adopted before that.”
Operating at a loss would only be justifiable in the case of expected future returns, not due to sunk costs.
e
> On Oct 20, 2019, at 15:46, Lucas H <lucash.dev at gmail.com> wrote:
>
>
> Hi, guys.
>
> Thanks a lot for taking the time to read and discuss my post.
>
> I definitely wasn't clear enough about the problem statement -- so let me try to clarify my thinking.
>
> First, the main uncertainty the miner is trying to protect against isn't the inefficiency of his new equipment, but how much new mining equipment is being deployed world-wide, which he can't know in advance (as the system is permissionless).
>
> Second, there are two different metrics that can mean "profitable" that I think are getting confused (probably my fault for lack of using the right terms).
>
> - Let's call it "operational profitability", and use "P" to denote it, where P = [bitcoin earned]/time - [operational cost of running equipment]/time.
> Obviously if P < 0, the miner will just shut down his equipment.
> - Return on investment (ROI). A positive ROI requires not just that P > 0, but that it is enough to compensate for the initial investment of buying or building the equipment. As long as P > 0, a miner will keep his equipment running, even at a negative ROI, as the alternative would be an even worse negative ROI. Sure he can sell it, but however buys it will also keep it running, otherwise the equipment is worthless.
>
> The instrument I describe above protects against the scenario where P > 0, but ROI < 0.
> (it's possible it could be useful in some cases to protect against P < 0, but that's not my main motivator and isn't an assumption)
>
> If too many miners are deploying too much new equipment at the same time, it's possible that your ROI becomes negative, while nobody shuts down their equipment and the difficulty still keeps going up. In fact, it is possible for all miners to have negative ROI for a while without a reduction in difficulty. Difficulty would only go down in this case at the end of life of these equipment, if there isn't a new wave of even more efficient equipment
> being adopted before that.
>
> Let's see a simplified scenario in which the insurance becomes useful. This is just one example, and other scenarios could also work.
>
> - Bitcoin price relatively constant, that is, it's not the main driver of P during this period.
> - Approximately constant block rewards.
> - New equipment comes to market with much higher efficiency than all old equipment. So the old stock of old equipment becomes irrelevant after a short while.
> - All miners decide to deploy new equipment, but none knows how much the others are deploying, or when, or at what price or P.
> - Let's just assume P>0 for all miners using the new equipment.
> - Let's assume every unit of the new equipment runs at the same maximum hashrate it's capable of.
>
> Let's say miner A buys Na units of the new equipment and the total number deployed by all miners is N.
>
> A's share of the block rewards will be Na / N.
>
> If N is much higher than A's initial estimate, his ROI might well become negative, and the insurance would help him prevent a loss.
>
> Hope this makes the problem a bit clearer.
>
> Thanks!
> @lucash-dev
>
>> On Sun, Oct 20, 2019 at 9:16 AM Eric Voskuil <eric at voskuil.org> wrote:
>> So we are talking about a miner insuring against his own inefficiency.
>>
>> Furthermore a disproportionate increase in hash rate is based on the expectation of higher future return (investment leads returns). So the insurance could end up paying out against realized profit.
>>
>> Generally speaking, insuring investment is a zero sum game.
>>
>> e
>>
>> > On Oct 20, 2019, at 12:10, JW Weatherman <jw at mathbot.com> wrote:
>> >
>> > Oh, I see your point.
>> >
>> > However the insurance contract would protect the miner even in that case. A miner with great confidence that he is running optimal hardware and has optimal electricity and labor costs probably wouldn't be interested in purchasing insurance for a high price, but if it was cheap enough it would still be worth it. And any potential new entrants on the edge of jumping in would enter when they otherwise would not have because of the decreased costs (decreased risk).
>> >
>> > An analogy would be car insurance. If you are an excellent driver you wouldn't be willing to spend a ton of money to protect your car in the event of an accident, but if it is cheap enough you would. And there may be people that are unwilling to take the risk of a damaged car that refrain from becoming drivers until insurance allows them to lower the worst case scenario of a damaged car.
>> >
>> > -JW
>> >
>> >
>> >
>> >
>> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> >> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <eric at voskuil.org> wrote:
>> >>
>> >>
>> >>
>> >>>> On Oct 20, 2019, at 10:10, JW Weatherman jw at mathbot.com wrote:
>> >>> I think the assumption is not that all miners are unprofitable, but that a single miner could make an investment that becomes unprofitable if the hash rate increases more than he expected.
>> >>
>> >> This is a restatement of the assumption I questioned. Hash rate increase does not imply unprofitability. The new rig should be profitable.
>> >>
>> >> What is being assumed is a hash rate increase without a proportional block reward value increase. In this case if the newest equipment is unprofitable, all miners are unprofitable.
>> >>
>> >>> Depending on the cost of the offered insurance it would be prudent for a miner to decrease his potential loss by buying insurance for this possibility.
>> >>> And the existence of attractive insurance contracts would lower the barrier to entry for new competitors in mining and this would increase bitcoins security.
>> >>> -JW
>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> >>>
>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>> >>>> Hi Lucas,
>> >>>> I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed in the case of subsequently increasing hash rate.
>> >>>> The assumption of increasing hash rate implies an expectation of increasing return on investment. There are certainly speculative errors, but a loss on new equipment implies all miners are operating at a loss, which is not a sustainable situation.
>> >>>> If any miner is profitable it is the miner with the new equipment, and if he is not, hash rate will drop until he is. This drop is most likely to be precipitated by older equipment going offline.
>> >>>> Best,
>> >>>> Eric
>> >>>>
>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>> >>>>>> Hi,
>> >>>>>> This is my first post to this list -- even though I did some tiny contributions to bitcoin core I feel quite a beginner -- so if my idea is stupid, already known, or too off-topic, just let me know.
>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitability of a mining operation -- in case Bitcoin/hash price goes too low. It can be trustless bc we can use the assumption that the price of hashing is low to unlock funds.
>> >>>>>> The problem:
>> >>>>>> A miner invests in new mining equipment, but if the hash-rate goes up too much (the price he is paid for a hash goes down by too much) he will have a loss.
>> >>>>>> Solution: trustless hash-price insurance contract (or can we call it an option to sell hashes at a given price?)
>> >>>>>> An insurer who believes that it's unlikely the price of a hash will go down a lot negotiates a contract with the miner implemented as a Bitcoin transaction:
>> >>>>>> Inputs: a deposit from the insurer and a premium payment by the miner
>> >>>>>> Output1: simply the premium payment to the insurer
>> >>>>>> Output2 -- that's the actual insurance
>> >>>>>> There are three OR'ed conditions for paying it:
>> >>>>>> A. After expiry date (in blocks) insurer can spend
>> >>>>>> B. Both miner and insurer can spend at any time by mutual agreement
>> >>>>>> C. Before expiry, miner can spend by providing a pre-image that produces a hash within certain difficulty constraints
>> >>>>>> The thing that makes it a hash-price insurance (or option, pardon my lack of precise financial jargon), is that if hashing becomes cheap enough, it becomes profitable to spend resources finding a suitable pre-image, rather than mining Bitcoin.
>> >>>>>> Of course, both parties can reach an agreement that doesn't require actually spending these resources -- so the miner can still mine Bitcoin and compensate for the lower-than-expected reward with part of the insurance deposit.
>> >>>>>> If the price doesn't go down enough, the miner just mines Bitcoin and the insurer gets his deposit back.
>> >>>>>> It's basically an instrument for guaranteeing a minimum profitability of the mining operation.
>> >>>>>> Implementation issues: unfortunately we can't do arithmetic comparison with long integers >32bit in the script, so implementation of the difficulty requirement needs to be hacky. I think we can use the hashes of one or more pre-images with a given short length, and the miner has to provide the exact pre-images. The pre-images are chosen by the insurer, and we would need a "honesty" deposit or other mechanism to punish the insurer if he chooses a hash that doesn't correspond to any short-length pre-image. I'm not sure about this implementation though, maybe we actually need new opcodes.
>> >>>>>> What do you guys think?
>> >>>>>> Thanks for reading it all! Hope it was worth your time!
>> >>>>>
>> >>>>> 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/20191020/1a643cc1/attachment-0001.html>

2023-06-07 18:21:17

- reply

📅 Original date posted:2019-10-20
📝 Original message:So we are talking about a miner insuring against his own inefficiency.
Furthermore a disproportionate increase in hash rate is based on the expectation of higher future return (investment leads returns). So the insurance could end up paying out against realized profit.
Generally speaking, insuring investment is a zero sum game.
e
> On Oct 20, 2019, at 12:10, JW Weatherman <jw at mathbot.com> wrote:
>
> Oh, I see your point.
>
> However the insurance contract would protect the miner even in that case. A miner with great confidence that he is running optimal hardware and has optimal electricity and labor costs probably wouldn't be interested in purchasing insurance for a high price, but if it was cheap enough it would still be worth it. And any potential new entrants on the edge of jumping in would enter when they otherwise would not have because of the decreased costs (decreased risk).
>
> An analogy would be car insurance. If you are an excellent driver you wouldn't be willing to spend a ton of money to protect your car in the event of an accident, but if it is cheap enough you would. And there may be people that are unwilling to take the risk of a damaged car that refrain from becoming drivers until insurance allows them to lower the worst case scenario of a damaged car.
>
> -JW
>
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil <eric at voskuil.org> wrote:
>>
>>
>>
>>>> On Oct 20, 2019, at 10:10, JW Weatherman jw at mathbot.com wrote:
>>> I think the assumption is not that all miners are unprofitable, but that a single miner could make an investment that becomes unprofitable if the hash rate increases more than he expected.
>>
>> This is a restatement of the assumption I questioned. Hash rate increase does not imply unprofitability. The new rig should be profitable.
>>
>> What is being assumed is a hash rate increase without a proportional block reward value increase. In this case if the newest equipment is unprofitable, all miners are unprofitable.
>>
>>> Depending on the cost of the offered insurance it would be prudent for a miner to decrease his potential loss by buying insurance for this possibility.
>>> And the existence of attractive insurance contracts would lower the barrier to entry for new competitors in mining and this would increase bitcoins security.
>>> -JW
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>> Hi Lucas,
>>>> I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed in the case of subsequently increasing hash rate.
>>>> The assumption of increasing hash rate implies an expectation of increasing return on investment. There are certainly speculative errors, but a loss on new equipment implies all miners are operating at a loss, which is not a sustainable situation.
>>>> If any miner is profitable it is the miner with the new equipment, and if he is not, hash rate will drop until he is. This drop is most likely to be precipitated by older equipment going offline.
>>>> Best,
>>>> Eric
>>>>
>>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>>>>> Hi,
>>>>>> This is my first post to this list -- even though I did some tiny contributions to bitcoin core I feel quite a beginner -- so if my idea is stupid, already known, or too off-topic, just let me know.
>>>>>> TL;DR: a trustless contract that guarantees minimum profitability of a mining operation -- in case Bitcoin/hash price goes too low. It can be trustless bc we can use the assumption that the price of hashing is low to unlock funds.
>>>>>> The problem:
>>>>>> A miner invests in new mining equipment, but if the hash-rate goes up too much (the price he is paid for a hash goes down by too much) he will have a loss.
>>>>>> Solution: trustless hash-price insurance contract (or can we call it an option to sell hashes at a given price?)
>>>>>> An insurer who believes that it's unlikely the price of a hash will go down a lot negotiates a contract with the miner implemented as a Bitcoin transaction:
>>>>>> Inputs: a deposit from the insurer and a premium payment by the miner
>>>>>> Output1: simply the premium payment to the insurer
>>>>>> Output2 -- that's the actual insurance
>>>>>> There are three OR'ed conditions for paying it:
>>>>>> A. After expiry date (in blocks) insurer can spend
>>>>>> B. Both miner and insurer can spend at any time by mutual agreement
>>>>>> C. Before expiry, miner can spend by providing a pre-image that produces a hash within certain difficulty constraints
>>>>>> The thing that makes it a hash-price insurance (or option, pardon my lack of precise financial jargon), is that if hashing becomes cheap enough, it becomes profitable to spend resources finding a suitable pre-image, rather than mining Bitcoin.
>>>>>> Of course, both parties can reach an agreement that doesn't require actually spending these resources -- so the miner can still mine Bitcoin and compensate for the lower-than-expected reward with part of the insurance deposit.
>>>>>> If the price doesn't go down enough, the miner just mines Bitcoin and the insurer gets his deposit back.
>>>>>> It's basically an instrument for guaranteeing a minimum profitability of the mining operation.
>>>>>> Implementation issues: unfortunately we can't do arithmetic comparison with long integers >32bit in the script, so implementation of the difficulty requirement needs to be hacky. I think we can use the hashes of one or more pre-images with a given short length, and the miner has to provide the exact pre-images. The pre-images are chosen by the insurer, and we would need a "honesty" deposit or other mechanism to punish the insurer if he chooses a hash that doesn't correspond to any short-length pre-image. I'm not sure about this implementation though, maybe we actually need new opcodes.
>>>>>> What do you guys think?
>>>>>> Thanks for reading it all! Hope it was worth your time!
>>>>>
>>>>> 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
>
>

2023-06-07 18:21:16

- reply

📅 Original date posted:2019-10-20
📝 Original message:Hi Lucas,
I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed in the case of subsequently increasing hash rate.
The assumption of increasing hash rate implies an expectation of increasing return on investment. There are certainly speculative errors, but a loss on new equipment implies *all miners* are operating at a loss, which is not a sustainable situation.
If any miner is profitable it is the miner with the new equipment, and if he is not, hash rate will drop until he is. This drop is most likely to be precipitated by older equipment going offline.
Best,
Eric
> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hi,
>
> This is my first post to this list -- even though I did some tiny contributions to bitcoin core I feel quite a beginner -- so if my idea is stupid, already known, or too off-topic, just let me know.
>
> TL;DR: a trustless contract that guarantees minimum profitability of a mining operation -- in case Bitcoin/hash price goes too low. It can be trustless bc we can use the assumption that the price of hashing is low to unlock funds.
>
> The problem:
>
> A miner invests in new mining equipment, but if the hash-rate goes up too much (the price he is paid for a hash goes down by too much) he will have a loss.
>
> Solution: trustless hash-price insurance contract (or can we call it an option to sell hashes at a given price?)
>
> An insurer who believes that it's unlikely the price of a hash will go down a lot negotiates a contract with the miner implemented as a Bitcoin transaction:
>
> Inputs: a deposit from the insurer and a premium payment by the miner
> Output1: simply the premium payment to the insurer
> Output2 -- that's the actual insurance
> There are three OR'ed conditions for paying it:
> A. After expiry date (in blocks) insurer can spend
> B. Both miner and insurer can spend at any time by mutual agreement
> C. Before expiry, miner can spend by providing **a pre-image that produces a hash within certain difficulty constraints**
>
> The thing that makes it a hash-price insurance (or option, pardon my lack of precise financial jargon), is that if hashing becomes cheap enough, it becomes profitable to spend resources finding a suitable pre-image, rather than mining Bitcoin.
> Of course, both parties can reach an agreement that doesn't require actually spending these resources -- so the miner can still mine Bitcoin and compensate for the lower-than-expected reward with part of the insurance deposit.
> If the price doesn't go down enough, the miner just mines Bitcoin and the insurer gets his deposit back.
> It's basically an instrument for guaranteeing a minimum profitability of the mining operation.
>
> Implementation issues: unfortunately we can't do arithmetic comparison with long integers >32bit in the script, so implementation of the difficulty requirement needs to be hacky. I think we can use the hashes of one or more pre-images with a given short length, and the miner has to provide the exact pre-images. The pre-images are chosen by the insurer, and we would need a "honesty" deposit or other mechanism to punish the insurer if he chooses a hash that doesn't correspond to any short-length pre-image. I'm not sure about this implementation though, maybe we actually need new opcodes.
>
> What do you guys think?
> Thanks for reading it all! Hope it was worth your time!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:21:16

- reply

📅 Original date posted:2019-10-20
📝 Original message:> On Oct 20, 2019, at 10:10, JW Weatherman <jw at mathbot.com> wrote:
>
> I think the assumption is not that all miners are unprofitable, but that a single miner could make an investment that becomes unprofitable if the hash rate increases more than he expected.
This is a restatement of the assumption I questioned. Hash rate increase does not imply unprofitability. The new rig should be profitable.
What is being assumed is a hash rate increase *without* a proportional block reward value increase. In this case if the newest equipment is unprofitable, all miners are unprofitable.
> Depending on the cost of the offered insurance it would be prudent for a miner to decrease his potential loss by buying insurance for this possibility.
>
> And the existence of attractive insurance contracts would lower the barrier to entry for new competitors in mining and this would increase bitcoins security.
>
> -JW
>
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Lucas,
>>
>> I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed in the case of subsequently increasing hash rate.
>>
>> The assumption of increasing hash rate implies an expectation of increasing return on investment. There are certainly speculative errors, but a loss on new equipment implies all miners are operating at a loss, which is not a sustainable situation.
>>
>> If any miner is profitable it is the miner with the new equipment, and if he is not, hash rate will drop until he is. This drop is most likely to be precipitated by older equipment going offline.
>>
>> Best,
>> Eric
>>
>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>> Hi,
>>> This is my first post to this list -- even though I did some tiny contributions to bitcoin core I feel quite a beginner -- so if my idea is stupid, already known, or too off-topic, just let me know.
>>> TL;DR: a trustless contract that guarantees minimum profitability of a mining operation -- in case Bitcoin/hash price goes too low. It can be trustless bc we can use the assumption that the price of hashing is low to unlock funds.
>>> The problem:
>>> A miner invests in new mining equipment, but if the hash-rate goes up too much (the price he is paid for a hash goes down by too much) he will have a loss.
>>> Solution: trustless hash-price insurance contract (or can we call it an option to sell hashes at a given price?)
>>> An insurer who believes that it's unlikely the price of a hash will go down a lot negotiates a contract with the miner implemented as a Bitcoin transaction:
>>> Inputs: a deposit from the insurer and a premium payment by the miner
>>> Output1: simply the premium payment to the insurer
>>> Output2 -- that's the actual insurance
>>> There are three OR'ed conditions for paying it:
>>> A. After expiry date (in blocks) insurer can spend
>>> B. Both miner and insurer can spend at any time by mutual agreement
>>> C. Before expiry, miner can spend by providing a pre-image that produces a hash within certain difficulty constraints
>>> The thing that makes it a hash-price insurance (or option, pardon my lack of precise financial jargon), is that if hashing becomes cheap enough, it becomes profitable to spend resources finding a suitable pre-image, rather than mining Bitcoin.
>>> Of course, both parties can reach an agreement that doesn't require actually spending these resources -- so the miner can still mine Bitcoin and compensate for the lower-than-expected reward with part of the insurance deposit.
>>> If the price doesn't go down enough, the miner just mines Bitcoin and the insurer gets his deposit back.
>>> It's basically an instrument for guaranteeing a minimum profitability of the mining operation.
>>> Implementation issues: unfortunately we can't do arithmetic comparison with long integers >32bit in the script, so implementation of the difficulty requirement needs to be hacky. I think we can use the hashes of one or more pre-images with a given short length, and the miner has to provide the exact pre-images. The pre-images are chosen by the insurer, and we would need a "honesty" deposit or other mechanism to punish the insurer if he chooses a hash that doesn't correspond to any short-length pre-image. I'm not sure about this implementation though, maybe we actually need new opcodes.
>>> What do you guys think?
>>> Thanks for reading it all! Hope it was worth your time!
>>>
>>> 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
>
>

2023-06-07 18:21:14

- reply

📅 Original date posted:2019-10-20
📝 Original message:I agree, thanks.
FWIW I’ve never been a fan of the ‘reject’ message, or its implementation.
https://github.com/bitcoin/bips/wiki/Comments:BIP-0061
e
> On Oct 18, 2019, at 18:46, David A. Harding <dave at dtrt.org> wrote:
>
> On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-dev wrote:
>> As this is a P2P protocol change it should be exposed as a version
>> increment (and a BIP) [...]
>>
>> BIP61 is explicit:
>>
>> “All implementations of the P2P protocol version 70,002 and later
>> should support the reject message.“
>
> I don't think a new BIP or a version number increment is necessary.
>
> 1. "Should support" isn't the same as "must support". See
> https://tools.ietf.org/html/rfc2119 ; by that reading,
> implementations with protocol versions above 70,002 are not required
> to support the reject message.
>
> 2. If you don't implement a BIP, as Bitcoin Core explicitly doesn't any
> more for BIP61[1], you're not bound by its conditions.
>
> -Dave
>
> [1] https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md "BIP61
> [...] Support was removed in v0.20.0"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191020/d2498549/attachment-0001.html>

2023-06-07 18:21:13

- reply

📅 Original date posted:2019-10-17
📝 Original message:As this is a P2P protocol change it should be exposed as a version increment (and a BIP), not just as a conditional service. If the intent is to retain this protocol indefinitely, exposing it conditionally, then a service bit would make sense, but it remains a protocol change.
BIP61 is explicit:
“All implementations of the P2P protocol version 70,002 and later should support the reject message.“
e
> On Oct 17, 2019, at 12:54, Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 16/10/2019 18.43, John Newbery via bitcoin-dev wrote:
>
>> Following discussion on this mailing list, support for BIP 61 REJECT
>> messages was not removed from Bitcoin Core in V0.19. The behaviour in
>> that upcoming release is that REJECT messages are disabled by default
>> and can be enabled using the `-enablebip61` command line option.
>
> Is there a NODE_* bit we can use to pick peers that support this
> (useful!) feature?
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:20:20

- reply

📅 Original date posted:2019-08-16
📝 Original message:Thanks for adding this to the record.
And for the record I’ll reiterate here, as I did with BIP90, that this is a hard fork.
e
> On Aug 16, 2019, at 12:06, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote:
>> Once a consensus change has been activated and buried by sufficient work,
>> we consider the height of that change to be historic fact. The exact
>> activation method is no longer of practical interest. In some cases the
>> cause of activation is not even decidable. For example, we know that segwit
>> activated at height 481,824 but it's debatable whether that was due to BIP
>> 9 version bits signaling, BIP 148 UASF, or a combination of the two.
>
> I just wanted to elaborate on this excellent point:
>
> This is debatable because Bitcoin is a decentralized, soft-forks are backwards
> compatible, and it's very difficult if not impossible to measure the
> preferences of economically significant nodes. Both the BIP9 version bits
> signalling and the BIP 148 UASF had the same basic effect: enforce segwit.
> Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the BIP9
> version bits.
>
> We can observe the fact that 100% of known blocks produced after Aug 1st 2017
> have complied with segwit rules, and the BIP9 signalling protocol for segwit.
> But strictly speaking we don't really know why that happened. It's possible
> that miners were running the BIP9 signalling Bitcoin Core release around that
> time. It's also possible that miners were running UASF enforcing software.
> It's possible there was a combination of both. Or even entirely different
> software - remember that some miners produced segwit-valid blocks, but didn't
> actually mine segwit transactions. Each scenario leads to the same externally
> observable outcome.
>
> Furthermore there's the question as to why miners were producing
> segwit-compliant blocks: perhaps they thought the vast majority of economically
> significant nodes would reject their blocks? Perhaps they just wanted to
> enforce segwit?
>
> These are all questions that have plausible answers, backed by evidence and
> argument. But because Bitcoin is a decentralized network no authority can tell
> you what the answers are.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:19:23

- reply

📅 Original date posted:2019-07-19
📝 Original message:> On Jul 18, 2019, at 20:45, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Kenshiro,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Thursday, July 18, 2019 11:50 PM, Kenshiro [] <tensiam at hotmail.com> wrote:
>>
>> Hi all,
>>
>>>>> A 51% attack under proof-of-work is only possible, in general, if some singular entity were able to have physical control of almost 50%, or some such close number, of the globe, simply due to the fact that energy availability is somewhat distributed over the globe.
>>
>> Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest.
>>
>> If you look at this graph you will see that controlling 4 mining pools could be enough:
>>
>> https://www.blockchain.com/en/pools
>
> Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave.
But also long term economic power, since leaving implies a lower proportional hash power, until another comparably-sized pool exists, but this is not the case when there is a majority hash power pool, which is economically inevitable until the majority miner starts censoring.
https://github.com/libbitcoin/libbitcoin-system/wiki/Pooling-Pressure-Risk
> Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered).
> The invisible hand abides.
This is why PoW is necessary, and why fee-based confirmation is necessary. It’s the only economically-rational way that the censor can be overpowered. But keep in mind the only net cost to the censor is the *premium* on censored transactions.
https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property
> Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash.
> So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically.
While this proposal may introduce engineering improvements, it does not change any of the economic forces at work and therefore does not mitigate this issue. The pool controls the payout, and therefore retains power over tx selection regardless of who selects and grinds on them.
https://github.com/libbitcoin/libbitcoin-system/wiki/Decoupled-Mining-Fallacy
>>>>> Secondly: change of hashing algorithm is pointless in the highly unlikely case of a 51% attack, because what matters is control of energy sources.
>>
>> As far as I know, if the PoW algorithm changes to an ASIC resistant algorithm that can only run in GPUs or CPUs, the hashing power would be much more distributed at least until someone creates a new ASIC for that algorithm. There are many GPUs around the globe, but not so many ASIC miners right?
>
> GPUs still require electricity to run, and are far easier to source.
> Hash change simply means that those with control of energy sources can easily purchase the needed hardware from many sources (as opposed to ASICs which are only sourced from a few places).
> So a hash change will only affect things temporarily, and it will still settle to the existing distribution of mining hashpower.
Yes
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy
>>>>> Nothing can be more efficient than proof-of-work, and the proof-of-stake delusion is simply a perpetual motion machine that attempts to get something from nothing.
>>
>> As time passes and more PoS coins appears, including big projects like Ethereum, we will see if it's delusional or not 🙂
>>
>> I forgot one, if you do a 51% attack to a PoS coin you know that all your staking funds will be burned. In a PoW coin you don't lose your miners and can use them to mine or attack another coin with the same algorithm.
>
> I already told you that it is always possible to get around this: leverage by use of short options.
> Short the coin to attack, then perform your attack by censorship.
> Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand.
> By this, you can steal the entire marketcap of the coin.
Yes, and of course stealing the value in the chain is not the only way to profit from the destruction of its usefulness. PoS offers no defense against the primary threat to permissionless money.
https://github.com/libbitcoin/libbitcoin-system/wiki/Fedcoin-Objectives
> Then you still have the economic power (plus what you managed to steal), which you can then use to take over another proof-of-stake coin, regardless of whether it uses the same proof-of-stake algorithm or not.
>
> At least mining hardware are physical hardware and subject to deprecation over time.
Capital cost isn’t the source of this defense, it’s the ability to introduce as much power as necessary to evict the censor, paid for by the rising premium on censored txs. Without this the majority miner can mine indefinitely and be the most profitable. This is of no consequence to confirmation until censorship begins.
In PoS, once a miner achieves necessary stake (also profitably) it can censor indefinitely. It’s a big difference.
https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles
>>>>> You must understand that removing the chain tip puts the transactions in that block back in the mempool, before we ever start following the longer chain.
>>
>> Yep but it could make double spend attacks very easy. People would know what is happening and could send the money to themselves with a higher fee to recover it. Many people would lose money with that.
>>
>> To fix that problem with a PoS algorithm, some community-guided initiative could get all transactions of both chains and create a merged chain with a hard fork so double spends attacks would not be possible. This could be somewhat slow, maybe the network is stopped a few days, but in the end no one will see money disappear from their wallet, much better than pray that your payer doesn't send the money back ato himself.
>
> This happens every day in Bitcoin, and nobody particularly cares.
> You just wait for confirmations that in practice are impossible for some orphaned chain to persist.
Yes, and of course the same scenario as described above can also occur with PoW. Gather up the victims, invest in mining a stronger chain, get the profit from the mining investment, and get your money back.
>>>>> This solution is worse than the problem, and speeds up the dominance of large stakers over the coin, trivially letting someone with the largest stake in the coin grow their stake even faster.
>>
>> I think it's very evident that the rich guy earn coins faster in both algorithms.
>>
>> In PoS if you have 51% of the coins and use them to stake, you make 51% of the blocks, I don't see any problem with that. If you decide to do a 51% attack, stopping doing blocks in the main chain to force the others to follow your "private" chain, well, you know for sure your funds will be burned in the next hard fork.
>
> But your proposal of being non-linear on the size of the stake means that if you have 51% of the coins, if you put them in a single stake UTXO you potentially get 99.999% of the blocks, which is ***much worse***.
It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly something to minimize.
> Just admit that you have no real solution to knowing how much every entity controls of your coin.
>>>>> No, I think it will be very successful in ensuring that smart individuals will spend their time actually doing things that benefit the economy and technology instead of wasting their time being distracted with Ethereum and proof-of-stake.
>>
>> Ok, we the PoS advocates will let the smart people to work in more difficult issues like finding reasons to justify the energy waste and heat generation of PoW when Bitcoin price reaches 1 million dollars 😉
>
> We hope to see you back soon after having learned your lesson.
Let’s all be nice. But WRT energy waste... see last paragraph for a consideration of waste in relation to any other monetary options.
https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy
e
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190718/5897e975/attachment-0001.html>

2023-06-07 18:19:20

- reply

📅 Original date posted:2019-07-17
📝 Original message:> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi ZmnSCPxj,
>
> I'm based on the more evolved implementation of PoS that I know, which is PoS v3.0 and it's currently implemented in several coins:
>
> http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version
>
> As far as I know the grinding attack is and old issue that is fixed in PoS v3.0.
>
> >>>At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default.
>
> We don't trust the developers, the source code is public and anyone can check it. With the hardcoded checkpoints is exactly the same, they are in the source code repository and everyone can check them. The checkpoints are the easiest part to check. A user doesn't have any reason to remove the checkpoints, but as with anything in the source code, they could modify it to avoid the checkpoints (and become vulnerable to Long Range attacks doing it)
Bad precedent set by Bitcoin, just like retroactively hardcoding soft fork activation checkpoints.
> >>>Under the trust-minimization requirement of Bitcoin this is simply not acceptable.
> As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm.
That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not to change the consensus rules in the code you ship.
> The block explorer or other additional source of trust like a friend would only be required in the extreme situation that the network is under a 51% attack, and only by the nodes that are updating blocks in that moment. Updated nodes are fully protected, and under normal circumstances new nodes can just follow the longest chain as always. The other extreme situation that could cause a hard fork is that the network is splitted more than N blocks, which should require some social consensus to fix it. So N should be long enough, like a few hours of blocks or even 1 day.
Consensus rules are the social consensus. If you have an objective way to do this, write the rule.
> >>> History rewrites are not the only attack possible.
> The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks.
>
> I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people.
Censorship can steal everybody’s money.
> In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator.
Political money.
> >>> Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake.
>
> Sure, but in PoW the miners with more hash power earn more coins that can be used to purchase more miners.
True, but this is at least limited proportionally.
> There is always the privilege of the rich guy, no matter if its PoW or PoS. The point is to design a protocol that don't allow the rich to destroy the network.
The ability to introduce new power to the chain is the only way to evict a censor. In PoS a well capitalized individual or state can buy total control over the system forever at no ongoing cost. PoW allows any number of individuals to pay higher fees on censored txs and evict the censor, who must then maintain the cost of subsidizing censorship.
> Let me put it in this way: NXT is a PoS coin that uses moving checkpoints with a market cap of 21 million dollars. If the current PoS protocols are so flawed, how can you explain that a coin with this market cap is not being attacked?
The state doesn’t care because there is no material impact from it? It hasn’t started attacking Bitcoin yet either.
> https://www.coingecko.com/en/coins/nxt
>
> Another thing is that Ethereum itself is going to PoS next year, but with a different implementation that I'm proposing here.
Just another nail in the coffin.
Best,
Eric
> Regards,
>
>
> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Sent: Wednesday, July 17, 2019 1:00
> To: Kenshiro \[\]; Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
>
> Good morning Kenshiro,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hi,
> >
> > After studying several Proof of Stake implementations I think it's not only an eco-friendly (and more ethical) alternative to Proof of Work, but correctly implemented could be 100% secure against all 51% history rewrite attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required:
>
> Under the trust-minimization and uncensorability requirements that Bitcoin has, nothing is more efficient than proof-of-work.
> The very idea of proof-of-stake labors under the assumption that unencumbered free-market payment for the consumption of energy is somehow not market-efficient despite the well-known phenomenon of the invisible hand, and believes that it is possible to get something for nothing.
>
> Please re-examine your assumptions.
>
> > - Hardcoded checkpoints:each Bitcoin Core release (each few months) should include a hardcoded checkpoint with the hash of the current block height in that moment. This simple measure protects the blockchain up to the last checkpoint, and prevents any Long-Range attack.
>
> While this is a developer list and made up of developers who would be quite incentivized to agree to such a setup, note that this effectively trusts the developers.
> At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default.
>
> > This extra rule could be connecting to a block explorer to download the hash of the current block height, or ask some trusted source like a friend and enter the hash manually. After being fully updated, the user can always check that he is in the correct chain checking with a block explorer.
>
> Under the trust-minimization requirement of Bitcoin this is simply not acceptable.
> As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm.
>
> >
> > Someone could have 99% of the coins and still would be unable to use the coins to do any history rewrite attack. The attacker could only slow down the network not creating his blocks, or censor transactions in his blocks.
>
> History rewrites are not the only attack possible.
> The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks.
>
> Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation.
> By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction *does* get into the blockchain from the efforts of another block producer.
>
> This is trivial under proof-of-work, and is the cost we accept in order to achieve uncensorability, since it is non-trivial to acquire energy.
> Under proof-of-stake it is difficult to impossible to determine if some single entity controls >51% of stakeable coins, and thus has no way to protect against censorship attack.
> Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake.
>
> Depending on the PoS implementation, stake-grinding may allow a 49% staker to achieve 51% and thereby the ability to censor transactions.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20190717/8c177d01/attachment.html>

2023-06-07 18:19:15

- reply

📅 Original date posted:2019-07-06
📝 Original message:> On Jul 6, 2019, at 03:12, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
>
>> 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> 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.
No, it would not. I have seen no proposal requiring identity in the two roles, which is necessary to show that two distinct individuals operate in the roles. Furthermore, even identity would be insufficient, as two individuals can clearly collude in these roles.
> 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.
Agree, and it is the unremovable time constraint that ensures the opportunity cost. This is why in your proposal it is of no consequence that both roles can be the same person.
> Regarding burning: I think burning is unsustainable as usage of services is unlimited while coin suply is limited.
Loss is perpetual, so this implies Bitcoin is unsustainable.
>>>
>>> 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:
No, you do not. This is not the point at issue. See my previous response.
> 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.
No, it isn’t. Ownership must be perpetually (actually) transferable, not just known. The use of a covenant breaks this transferability, see previous posts.
> 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.
For the same reason this cannot work for money, it cannot work for any perpetual asset. See previous posts.
> 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.
Only if the asset expires at or before the covenant maturity.
> UTXOs with different covenants or without covenant are not fungible.
Of course.
> 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.
Only 1 satoshi is required for tracking. It is only the scarcity of a satoshi that creates this scarcity, not the covenant on it. The covenant represents only the destruction of opportunity of the value represented by the 1 satoshi, not a new system of scarcity.
> The current owner of a regular UTXO will want to be paid for temporarily giving up control, and that payment represents interest.
Yes, opportunity cost.
> Riskless, since it is certain to re-gain control.
But of no value to anyone as money.
Best,
Eric
> Regards,
>
> Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190706/99cf3765/attachment-0001.html>

2023-06-07 18:19:15

- reply

📅 Original date posted:2019-07-05
📝 Original message:> On Jul 5, 2019, at 12:27, Eric Voskuil <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.”
>
>> Similarly, an entity renting out a UTXO for an advertisement might allow for early reclamation of the UTXO in exchange for partial refund of fee; as the value in the UTXO is now freed to be spent elsewhere, the lessor can lease it to another advertiser.
>
> You appear to be proposing a design whereby either the owner or the renter (not entirely clear to me which) can spend the “locked up” coin at any time (no maturity constraint), by dropping the covenant.
>
> If the renter can do this he can simply steal the coin from the owner.
>
> If the owner can do this there is no value to the renter (or as a proof of cost), as the owner retains full control of the coin.
>
> If you mean that the age of the encumbrance is the proof of cost, this requires no covenant. I don’t believe this is what you intended, just covering all bases.
>
>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for an advertisement.
>
> And as I have shown above, nor can a “locked-up” coin be unlocked to do the same.
>
>> Similarly for miner fees.
>
> Well that’s the point, money spent is no longer under one’s control. The provable cost of this surrender was your stated objective. Renting at a fractional cost of coin face value is a non-recoverable spend by the renter to the owner. Burning or spending the same amount in a way that is provably not to one’s self achieves the exact same result.
>
>> The best that can be done would be to have the nodes of the classified ads network automatically decay the spent value of older advertisements to let them be dropped from their advertisements pool.
>
> The advertiser can presumably trade control of as space on the ad network. It’s not clear to me why this is not simply an independent chain of limited ad space ownership. It might as well be namecoin.
>
>> Less importantly, burning currently has bad resource usage for practical applications.
>> Practical burning requires spending to a provably-unspendable P2PKH or P2SH or similar output.
>> This adds UTXO entries to the UTXO database that will never be removed.
I forgot to add that it is certainly possible to burn using a nonstandard script, such as the non-zero OP_RETURN you suggested, without a consensus change. This can be, as you say, made more practical with a policy change. But such changes are up to individual node operators as they require no deviation from consensus. Yet ultimately this is a miner preference, and anyone can mine. Finally, as I pointed out, burning is not necessary. Simply spending the coin as a fee is sufficient.
> If an output is provably unspendable (burned) it is not a UTXO.
>
> It is worth noting that not all full node implementations require a store of UTXOs, this is an implementation detail. For example, libbitcoin uses a flag on each output to indicate its spentness on the strong branch. As such the store size is linear by height.
>
>> This will of course be remedied by compact UTXO representations later, but not today.
>> Similarly, it would be very nice to have non-0-amount `OP_RETURN` outputs, as `OP_RETURN` outputs are never stored in the UTXO database.
>> However, this will require a change in node relay policy, which again will take time to make possible, and would not be practical today.
>>
>> Thus I think use of UTXO is better than burning or mining-fee-spending.
>
> I don’t believe you have shown this.
>
> Best,
> Eric
>
>> Also, mostly trivia:
>> The use of UTXOs to advertise services is not original to me --- I found the LN channel gossip to be the inspiration for this.
>> Publicly-announced channels indicate the backing UTXO that funds the channel.
>> The purpose of publicly announcing the channels is to be able to provide the service, of forwarding across the Lightning Network; thus the public announcement serves as an advertisement for the service.
>> Channel closure immediately spends the UTXO, and also doubles to "revoke" the existing "advertisement".
>> I found this ability to "revoke" the advertisement appealing, and thereby designed the Bitcoin Classified Ads Network around the UTXO spentness mechanism.
>>
>> Regards,
>> ZmnSCPxj

2023-06-07 18:19:12

- reply

📅 Original date posted:2019-07-06
📝 Original message:I have published a summary here:
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/20190706/c66265a2/attachment.html>

2023-06-07 18:19:12

- reply

📅 Original date posted:2019-07-06
📝 Original message:> On Jul 6, 2019, at 06:34, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> 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.
My use of “encumbrance” in this thread has been consistently a reference to a covenant. When the covenant can be released at any time it serves no purpose whatsoever, being an encumbrance in name only.
I gave a detailed explanation of opportunity cost, and gave you a scenario where that opportunity cost could actually be used - to purchase a tracking output (i.e., a fixed term asset tracked for that term). And I have discussed at length the use of opportunity cost in the hash-cash-like anti-spam ad scenario.
So it’s not clear to me why you continue to imply that the nature of either covenants or opportunity cost is the point at issue, and by implying I don’t understand them.
**The central issue in your proposal is that constrained coins can neither be used as borrowed money nor the tracking of perpetual assets.** This conclusion is not based on a failure to understand the nature of covenants or the concept of opportunity cost. It is the necessary consequence of attempting to trade something today that will provably disappear tomorrow. The sole possible value of such an instrument is to scam the eventual bag-holders.
A secondary issue, in the valid fixed-term asset tracking scenario, is that the cost of tracking is dust (and at least one transfer fee). The cost of such tracking is a function only of the market price of a satoshi. The financial value of renting one dust output is also limited in time by economic interest (i.e., at 10% it is cheaper to buy than rent if the fixed term exceeds 7.2 years). So while valid, is not likely to be demanded until one satoshi becomes worth the overhead of renting it.
The opportunity of interest represents opportunity cost when forgone. This can be used to show proof-of-cost (ad scenario), and that level can float as a price on the anti-spam market. This is a perfectly valid scenario, as I have said.
The issue with that specific proposal is that it uses covenants in an irrational manner. The ability to release the covenant at any time eliminates the cost it would otherwise represent. One could either simply burn or spend coin outright, or use an actual encumbrance (as you propose) to “burn” (provably destroy) the opportunity, but a non-encumbrance adds nothing except complexity.
>>> 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.
Not significant, which is arbitrary, but sufficient - a result of supply and demand. Clearly my intent here is that no covenant on the UTXO is required in the scenario. As the preceding discussions conclude, without disagreement, all that is required is that the (sufficient) output remains unspent, not that it be encumbered.
>> Best,
>> Eric
>>
>>> Regards.
>>> ZmnSCPxj
>
> Best,
>
> Tamas Blummer

2023-06-07 18:19:11

- reply

📅 Original date posted:2019-07-05
📝 Original message:> On Jul 5, 2019, at 18: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.
>
>> 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.
>
> Unspentness is not actually a necessary cost (expense). All coin is always represented as UTXOs. If one has a hoard of coin there is no necessary incremental cost of identifying those coins to “back” ads.This isn’t altered by the proposed design.
>
> The only cost would be to have a hoard that one does not otherwise desire, representing an opportunity cost. Yet, as I have also pointed out, the amount of that opportunity cost can simply be spent (or burned) by the advertiser, representing the same cost. So covering the case where one cannot raise the capital to “back” one’s ad does not require rental, as the cost of the otherwise rental can just be spent outright.
>
> Presumably it would be ideal to transfer the value of those spends to people who provably present the ads for effective viewing (i.e., the AdWords business model). It is of course this market-driven cost of presenting an ad that provides the spam protection/definition for AdWords.
It’s worth pointing out at this point that this implies Google, etc. would achieve the same result by simply accepting Bitcoin for ad placement. In your model the advertiser is paying only for access to people who wish to avoid spam, not for targeted and actual placement. In other words your ad system would be directly competing with others that provide material additional value for the advertiser beyond anti-spam. If nothing else this implies the return on coin “lock-up” would be exceeded by its opportunity cost.
> Best,
> Eric
>
>> Regards.
>> ZmnSCPxj

2023-06-07 18:19:11

- reply

📅 Original date posted:2019-07-05
📝 Original message:> 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.
> 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.
Unspentness is not actually a necessary cost (expense). All coin is always represented as UTXOs. If one has a hoard of coin there is no necessary incremental cost of identifying those coins to “back” ads.This isn’t altered by the proposed design.
The only cost would be to have a hoard that one does not otherwise desire, representing an opportunity cost. Yet, as I have also pointed out, the amount of that opportunity cost can simply be spent (or burned) by the advertiser, representing the same cost. So covering the case where one cannot raise the capital to “back” one’s ad does not require rental, as the cost of the otherwise rental can just be spent outright.
Presumably it would be ideal to transfer the value of those spends to people who provably present the ads for effective viewing (i.e., the AdWords business model). It is of course this market-driven cost of presenting an ad that provides the spam protection/definition for AdWords.
Best,
Eric
> Regards.
> ZmnSCPxj

2023-06-07 18:19:10

- reply

📅 Original date posted:2019-07-05
📝 Original message:> On Jul 5, 2019, at 16: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> 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.
>
>>> Similarly, an entity renting out a UTXO for an advertisement might allow for early reclamation of the UTXO in exchange for partial refund of fee; as the value in the UTXO is now freed to be spent elsewhere, the lessor can lease it to another advertiser.
>>
>> You appear to be proposing a design whereby either the owner or the renter (not entirely clear to me which) can spend the “locked up” coin at any time (no maturity constraint), by dropping the covenant.
>>
>> If the renter can do this he can simply steal the coin from the owner.
>>
>> If the owner can do this there is no value to the renter (or as a proof of cost), as the owner retains full control of the coin.
>>
>
> Obviously this will require a 2-of-2 multisig, with an timelocked transaction that lets the owner recover at a futuredate, so that it is the agreement of *both* that is needed to perform any actions before the timelock.
> I already described this in the link I provided.
>
>
>> If you mean that the age of the encumbrance is the proof of cost, this requires no covenant. I don’t believe this is what you intended, just covering all bases.
>
> Not age of encumbrance, quite.
> Instead, it is the simple fact that the UTXO is a UTXO (and not yet spent), that validates the advertisement.
Not any UTXO then, one that with sufficient time-locked coin.
> No, it does not *require* a covenant.
> However, covenants do make it easier to use, in the sense that the renter can repurpose the UTXO (e.g. change details of advertisement) without having to contact the owner.
So how does one get the owner to sign off on the multisig release? Presumably the renter cares because he wants to recover the remaining value of rental. So he not only needs to contact the owner, he also needs to negotiate with the owner for a pro-rated refund. In other words, he must sell the remaining portion of the rental return - essentially how I described it previously. He might as well just sell the marketable ad space that he controls through the remainder of the term (the same value).
Certainly the owner could given him a partially-signed transaction, returning the coin, allowing the renter to exit at any time, but the renter has no reason to sign it without a refund, which must be pro-rated in some way, implying later contact/negotiation with the owner.
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.
>>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for an advertisement.
>>
>> 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.
I think I understand the implications of it clearly. Feel free to point out what I’m missing. But I don’t spend any time in implementation details until I can justify those implications.
A multisig doesn’t fix the central economic issue, which it is not clear that you understand. If so it hasn’t been demonstrated. A cost created by making coin unusable for a term is not an actual cost if that lock can be released at any time before maturity of that term. Furthermore, cost is most easily demonstrated by simply spending.
By analogy, proof of work is simply proof of a spend (incurred cost). Imagine if one demonstrated that cost by “locking up” coin for a year, and then after the block was accepted, he unlocked that coin after just one day.
Best,
Eric
> Regards,
> ZmnSCPxj

2023-06-07 18:19:09

- reply

📅 Original date posted:2019-07-05
📝 Original message:> 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.”
> Similarly, an entity renting out a UTXO for an advertisement might allow for early reclamation of the UTXO in exchange for partial refund of fee; as the value in the UTXO is now freed to be spent elsewhere, the lessor can lease it to another advertiser.
You appear to be proposing a design whereby either the owner or the renter (not entirely clear to me which) can spend the “locked up” coin at any time (no maturity constraint), by dropping the covenant.
If the renter can do this he can simply steal the coin from the owner.
If the owner can do this there is no value to the renter (or as a proof of cost), as the owner retains full control of the coin.
If you mean that the age of the encumbrance is the proof of cost, this requires no covenant. I don’t believe this is what you intended, just covering all bases.
> Burnt funds cannot be "un-burnt" to easily signal the end of a term for an advertisement.
And as I have shown above, nor can a “locked-up” coin be unlocked to do the same.
> Similarly for miner fees.
Well that’s the point, money spent is no longer under one’s control. The provable cost of this surrender was your stated objective. Renting at a fractional cost of coin face value is a non-recoverable spend by the renter to the owner. Burning or spending the same amount in a way that is provably not to one’s self achieves the exact same result.
> The best that can be done would be to have the nodes of the classified ads network automatically decay the spent value of older advertisements to let them be dropped from their advertisements pool.
The advertiser can presumably trade control of as space on the ad network. It’s not clear to me why this is not simply an independent chain of limited ad space ownership. It might as well be namecoin.
> Less importantly, burning currently has bad resource usage for practical applications.
> Practical burning requires spending to a provably-unspendable P2PKH or P2SH or similar output.
> This adds UTXO entries to the UTXO database that will never be removed.
If an output is provably unspendable (burned) it is not a UTXO.
It is worth noting that not all full node implementations require a store of UTXOs, this is an implementation detail. For example, libbitcoin uses a flag on each output to indicate its spentness on the strong branch. As such the store size is linear by height.
> This will of course be remedied by compact UTXO representations later, but not today.
> Similarly, it would be very nice to have non-0-amount `OP_RETURN` outputs, as `OP_RETURN` outputs are never stored in the UTXO database.
> However, this will require a change in node relay policy, which again will take time to make possible, and would not be practical today.
>
> Thus I think use of UTXO is better than burning or mining-fee-spending.
I don’t believe you have shown this.
Best,
Eric
> Also, mostly trivia:
> The use of UTXOs to advertise services is not original to me --- I found the LN channel gossip to be the inspiration for this.
> Publicly-announced channels indicate the backing UTXO that funds the channel.
> The purpose of publicly announcing the channels is to be able to provide the service, of forwarding across the Lightning Network; thus the public announcement serves as an advertisement for the service.
> Channel closure immediately spends the UTXO, and also doubles to "revoke" the existing "advertisement".
> I found this ability to "revoke" the advertisement appealing, and thereby designed the Bitcoin Classified Ads Network around the UTXO spentness mechanism.
>
> Regards,
> ZmnSCPxj

2023-06-07 18:19:08

- reply

📅 Original date posted:2019-07-04
📝 Original message:> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blummer at 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 <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
>

2023-06-07 18:19:08

- reply

📅 Original date posted:2019-07-04
📝 Original message:> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blummer at 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.
>
> - 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.
I meant to point out that a voluntarily trade cannot represent “damage” to the person making it. The person chooses the action because it is preferred over alternatives (i.e. it is beneficial). Such choices are the only objective expression of preference, a fundamental principle of praxeology.
> 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
>

2023-06-07 18:19:07

- reply

📅 Original date posted:2019-07-04
📝 Original message: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

2023-06-07 18:19:06

- reply

📅 Original date posted:2019-07-03
📝 Original message:> On Jul 2, 2019, at 00:08, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
>
>> 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.
In other words I discovered a potentially-valid use case for you. The concern I expressed was that you had not presented one.
> I am glad we are on the same side on this utility
My goal is never to discourage, but understanding of provable behavior and utility. Our space is replete with unsupportable conjecture and hyperbole. There are no sides, just discovery of truth.
> 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’ve noticed that in subsequent posts you continue to imply that there is economic value in such tracking of any asset, and of course here imply the validity of your other use case, monetary lending. This, as I have shown, is not the case. Tracking of an asset of value beyond the net compound interest cost of dust is more cheaply accomplished by burning than by renting, and as I have shown, it is not accurate to claim that the encumbered coin can be used as money (or to track any asset of perpetual value). When the coin expires the money/asset holder becomes a bag holder, invalidating any initial value apart from scamming.
In the valid use case that I have demonstrated (tracking of expiring assets), the marketable value of the rented coin is not the market price of that coin, but the price paid for it. So for example, 1 coin rented at 10% APR for one year is worth .1 coin. And when a renter resells this tracking coin it is worth the fraction of this amount for the time remaining. The coin itself (i.e. its face value) cannot be used by the renter to purchase anything.
As such this is truly not a loan in the financial or economic sense. Given an actual loan the borrower can use the full value of the amount borrowed to purchase goods that can be used in production. Subsequent generation of products and thereby revenue is the source of yield on a loan (economically equivalent to dividend on an equity contract). This allows the borrower to repay the loan with interest. Without *any* usable capital over the term of the rental, there is no investment possible and the time value of the rented coin cannot be realized by the renter.
So the one potentially-valid scenario, a fixed-term tracking rental, is entirely an *expense*, not a loan. A financial loan incurs an interest expense, but also implies the value of the amount loaned is fully usable (i.e., consumed or traded) during the term (the reason to pay interest). That is money over time, yielding the time value of money. In this case the value of the loan at any time to the renter is simply the amortized interest remaining. This implies that no income can be generated from the rental “principle” by the renter. A price is paid for the rental and that value of the rental is fully exhausted by the end of the term, with no other benefit than the tracking that was purchased.
The person renting the fixed-term tracking coin (i.e. “owner”) can earn income by selling dust+1 outputs at the cost of capital, limited to a maximum term dictated by the cost of capital and the dust limit (as shown previously). Economically speaking, all business returns gravitate toward the cost of capital, including lending, and this is no different. But it cannot be said that the owner is a financial lender. The owner is simply selling non-depreciating (from his perspective) fixed-term tracking space.
The owner can of course trade rights to the controlling output. The rental contract has been prepaid (by your design, in order to shift counterparty risk). As such the traded contract has no yield and therefore contracting for its sale is a currency future, not an interest rate future as would be implied by a debt market. Yet FX speculation already exists for Bitcoin, requiring no covenant or rental market. This would seem to undermine any secondary market for these more complex and limited currency futures.
Finally, valuation is based on the assumption of a non-zero dust+1, which BTC enforces as a 0 satoshi dust limit (i.e. 0 sats is considered dust and is not valid). Anything above this is policy-enforced only. As such a miner can undercut the cost of tracking an individual asset down to 1 sat. Given that there is no financial incentive to a higher dust limit for a miner, but a positive financial incentive to undercut the rental price for the same return, this is economically rational and therefore must be assumed.
One might argue that a lower dust policy would hurt BTC and therefore its miners collectively, creating an offsetting negative financial pressure. However given that the apparent cost is socialized in relation to individual benefit, this is not an economically rational conclusion. Furthermore, as the tracking outputs become unspendable due to the nature of the covenant, there is no actual dust accumulation (implementation dependent).
As such the return on any fixed-term tracking output, given a 10% APR, would become as low as .1 sat per year, assuming such a market could continue to function at that level. But it is also the case that a 1 sat output can be burned directly by the tracker and used indefinitely. This would presumably undermine any robust market for fixed-term tracking rental.
Best,
Eric
> 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
>

2023-06-07 18:19:03

- reply

📅 Original date posted:2019-07-01
📝 Original message:It’s an exceedingly poor example. First, value is subjective. It matters not what other people may consider, only those who act. Given that people trade them (ICO tokens), they have value to those people. Second, the scenario would not function given that the value, as with money, is based on the ability to trade perpetually.
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.
Now consider the value attributable to renting coin (e.g. to the tick issuer) in order to track the ticket. First, there is no net value in renting coin to pay confirmation (mining) fees on transfers. The cost of a fee is driven by competition and remains the same whether the coin used for payment is encumbered or not. In other words, even with value in tracking there is no *cost advantage* to renting of such coins for use as money.
But tracking an asset in this manner has required not only a fee for each trade, but also the burning of coin. By allowing the lender to recover the coin when the asset expires, this part of the cost of on-chain tracking can be time-shared (rented), and without depreciation of the coin.
In this case the lender is achieving both a time-locked hoard/speculation and a pre-paid rental return. The return to the lender would be the rental price minus the opportunity cost of not investing (ie, in production) this coin otherwise during that period. This is of course based on the economic principle that both hoarding and speculation are expected to produce no predictable return. As such the cost of the rental would be driven (by competition) toward the cost of capital (e.g. annualized 10% of the coin price) for the same period.
Depending on the term, rental will be cheaper than the outright cost of burning the same minimum amount of coin (i.e. dust+1, assuming policy compliance) as required for tracking. As soon as the rental cost exceeds the minimum tracking burn, rental becomes more expensive than just purchasing the coin. So, for example, at 10% market return on capital (rental cost), purchasing the coin is cheaper than rental at any tracking term beyond 7.2 years.
As discussed previously, there can be no monetary value of such encumbered coins. And as shown above, the non-monetary (tracking) scenario is limited to fixed-term tracking. This use of Bitcoin would of course reduce the average cost of non-monetary blockchain storage. I’m not sure that is a use people want to facilitate with a protocol change, but that’s for the community to decide.
Best,
Eric
> 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
>

2023-06-07 18:18:59

- reply

📅 Original date posted:2019-06-30
📝 Original message: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
>>>>>
>>>>>
>>>
>

2023-06-07 18:18:58

- reply

📅 Original date posted:2019-06-30
📝 Original message:Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins?
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
>>>
>>>
>

2023-06-07 18:18:57

- reply

📅 Original date posted:2019-06-30
📝 Original message:> 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.
> 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.
I was careful to point out that bitcoin is not in any way consumable. Occupying scarce land is a service to people. Units of bitcoin encumbered such that they cannot be traded for something of service to a person do not constitute property. You cannot even polish them, stack them on the floor, and roll around on them.
> 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.
Yet it has been established that these encumbered coins cannot purchase anything of value except to the extent that an imperfect market is unaware of the scam.
> 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.
Your goal is clear and not at issue.
> 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.
> 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.
Best,
Eric
> Tamas Blummer
>
>

2023-06-07 18:18:56

- reply

📅 Original date posted:2019-06-29
📝 Original message:> On Jun 28, 2019, at 12:21, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> 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.
As I implied, I am well aware of the concept of risk free rate of return, which is a hypothetical.
> The transaction I construct in the first example achives exactly this, because:
Which implies you have created an actual instance of this heretofore purely hypothetical concept.
> 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.
Why would Alice pay for this at all?
> The utility of these encumbered coins is that they prove that the loan is fully covered by reserves.
What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
Bitcoin is a money, not consumable in any way. Its utility arises strictly from the possibility of eventually being traded for something else. The only reason to accept it in trade is that expectation. Removing that possibility, even transitively and over time, removes all utility immediately. In my previous comments I described a necessary discount to NPV, but it’s safe to say that must be 100%.
> How valuable this utility is will be decided by the market
Value is of course subjective, and is determined by individual preferences. Yet what is the value one might place on something of no use? Economically speaking it must be zero, since value is a subjective evaluation of utility (i.e. service to a person).
Consider the case of the 1000 and 500 rupee demonetization. Long lines of people formed at banks to convert to notes to others of equivalent denomination.
https://en.m.wikipedia.org/wiki/2016_Indian_banknote_demonetisation
Of course, upon announcement of the demonetization, existing 1000/500 rupee notes were discounted for the cost/risk of accomplishing this conversion (several people are reported to have died in the effort). If there was no such conversion possible, making the notes worthless at the future date, the *immediate* effect would necessarily have been 100% discount.
This of course sets aside any consumable value of the “paper” notes, such as burning for heat or trading as novelties (e.g. demonetized Zimbabwean 100T notes currently trading), as Bitcoin is not capable of being consumed. It also sets aside the possibility that some people were unaware of the demonetization.
Who would accept such a note today that was known to be worthless at a future date? If they did, who would would accept it from them? It’s literally an on-chain scamcoin, where the first sucker must find another, and he another, an so on, as soon as possible, before it expires, leaving the last sucker holding the bag. Given an efficient market (i.e perfect knowledge of the scam), zero initial value is implied.
> and that value will be interest received by those who temporarily give up control. I am guess the value will be low but positive.
Giving up control of money for a period does not imply the money is useful to someone else. Bob might as well lock his coins in a time capsule, for which he has the only key, and ask Alice to pay him for it.
> Lending does not mandate fractional or full reserves.
I didn’t say that it does. Lending implies no “mandate”. But the nature of fractional reservation is inherent in every loan/investment.
> These are choices the market or regulators enforce.
Fractional reservation is not a consequence of statutory or market controls. The level of hoarding vs. lending is a consequence of individual time preference.
> 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.
I don’t believe I called full reserve a fiction. With full reserve there is no possible investment, production or products. Unlikely, and disastrous for humanity, but not provably impossible.
A hazard of viewing economic concepts through a financial lens is that those higher order concepts become obscured by a morass of economically-irrelevant regulation and implementation details.
At this point we are going to end up in a discussion on what fractional reserve actually is. I’d be happy to have a discussion on the topic, but this list is clearly not a good forum for that.
Furthermore the question of whether or not this proposal is relevant to fractional reserve is moot unless it can be shown that the assumed utility actually exists. So I suggest we take this interesting but secondary question on fractional reserve somewhere else.
> 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.
It shows the breadth of economic ignorance which is not surprising given its counterintuitive nature.
Best,
Eric
> 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
>
> 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
>
>> 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> 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
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/52c9105b/attachment-0001.html>

2023-06-07 18:18:55

- reply

📅 Original date posted:2019-06-28
📝 Original message: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> 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:17:13

- reply

📅 Original date posted:2019-03-25
📝 Original message:On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote:
> Proposal:
>
> <pre>
> BIP: ???
> Layer: Peer Services
> Title: Version 2 Peer-to-Peer Message Transport Protocol
> Author: Jonas Schnelli <dev at jonasschnelli.ch>
> Status: Draft
> Type: Standards Track
> Created: 2019-03-08
> License: PD
> </pre>
>
> == Abstract ==
>
> This BIP describes a new Bitcoin peer to peer transport protocol with
> opportunistic encryption.
>
> == Motivation ==
>
> The current peer-to-peer protocol is partially inefficient and in plaintext.
>
> With the current unencrypted message transport, BGP hijack,
> block delay attacks
> and message tempering are inexpensive and can be executed in a covert way
> (undetectable MITM)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
> Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
> Zohar, L.Vanbever]</ref>.
This proposal does not provide mitigation for BGP hijacking, message
tampering or delaying, between anonymous peers.
> Adding opportunistic encryption introduces a high risk for attackers of
> being detected. Peer operators can compare encryption session IDs
This is only possible if the peers have access to a secure/trusted side
channel between them. In other words, this does not benefit anonymous
peers. It also seems like quite a stretch to consider it creating "high
risk" for the attacker, since the chances of any given pair of peers
actually comparing session IDs over a secure channel seems extremely remote.
> or use other form of authentication schemes <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref> to identify an attack.
Authentication helps mitigate attacks by requiring the identity of the
peer (based only on the presumption that a trusted peer wouldn't
attack). This provides no benefit to anonymous peers.
Data communicated between peers is entirely public. Unlike other systems
that maintain data integrity through encryption, Bitcoin relies on
validation. Encrypting public data between anonymous peers is pointless,
and thus counterproductive from an engineering and software security
standpoint.
More importantly Bitcoin system security *requires* widespread anonymous
participation. It's generally not a good idea to implement features that
backfire if they actually get widespread use. While we cannot prevent
people from using VPNs, incorporating them into the protocol is
counterproductive from a system security standpoint.
> Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256
> checksum truncated to 4 bytes. Roughly the same amount of computation power
> would be required for encrypting and authenticating a peer-to-peer
> message with ChaCha20 & Poly1305.
The proposal overlooks the simple alternatives of (1) not validating the
checksum, which is never necessary, and (2) proposing a protocol change
to drop the checksum altogether. The former requires no protocol change
and the latter can allow the checksum to be dropped in all messages
except "version" given a simple protocol version number increment (i.e.
no need to consume a service bit), saving not only the CPU resource but
also network bandwidth.
> Additionally, this BIP describes a way how data manipulation (blocking or
> tempering commands by an intercepting TCP/IP node) would be identifiable
> by the communicating peers.
The only such method described is manual comparison of session ID's
between trusted parties over a secure side channel.
> Encrypting traffic between peers is already possible with VPN, tor,
> stunnel,
> curveCP or any other encryption mechanism on a deeper OSI level,
> however, most
> of those solutions require significant knowhow in how to setup such a
> secure
> channel and are therefore not widely deployed.
Yet this is exactly what a secure side channel is. Furthermore, being
manual, not only would it also suffer from not being widely deployed,
but also widely ignored.
> == Specification ==
>
> <blockquote>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD",
> "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are
> to be
> interpreted as described in RFC
> 2119<ref>[https://tools.ietf.org/html/rfc2119
> RFC 2119]</ref>.
> </blockquote>
>
> A peer that supports the message transport protocol as defined in this
> proposal
> MUST accept encryption requests from all peers.
>
> Both communication direction share the same shared-secret but have
> different
> symmetric cipher keys.
>
> The encryption handshake MUST happen before sending any other messages
> to the
> responding peer.
>
> If the responding peer closes the connection after sending the handshake
> request, the initiating peer MAY try to connect again with the v1
> peer-to-peer
> transport protocol. Such reconnects allow an attacker to "downgrade" the
> encryption to plaintext communication and thus, accepting v1 connections
> MUST
> not be done when the Bitcoin peer-to-peer network uses almost only v2
> communication.
>
>
> === NODE_P2P_V2 ===
>
> Peers supporting the transport protocol after this proposal MUST signal
> <code>NODE_P2P_V2</code>
> <pre>
> NODE_P2P_V2 = (1 << 11)
> </pre>
>
> A peer usually learns an address along with the expected service flags
> which
> MAY be used to filter possible outbound peers.
>
> A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted
> communication
> specified in this proposal.
>
> Peers MAY only make outbound connections to peers supporting
> <code>NODE_P2P_V2</code>.
>
> === Handshake ===
...
> ==== Short Command ID ====
The shortening of message identifiers hardly seems worth the effort.
Dropping the checksum seems a much easier way to save more on the wire
(and in the CPU).
> === Risks ===
>
> The encryption does not include an authentication scheme.
> This BIP does not
> cover a proposal to avoid MITM attacks during the encryption
> initialization.
Then to be clear it cannot prevent MITM attacks. The only actual
mitigation requires manual comparison of session IDs after each
connection (and reconnection).
> However, peers MUST show the session-id to the user on request which
> allows to identify a MITM by a manual verification on a secure channel.
This scenario presumes that the two peers are operated by individuals
who know and trust each other and have the ability to communicate over a
secure side channel, and will each extract the session ID from their
respective peers and use the side channel to compare them.
Not only does this not support anonymous peering, it's not clear what
process would exist to make this actually useful in practice.
> Optional authentication schemes may be covered by other proposals <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref>.
>
> An attacker could delay or halt v2 protocol enforcement by providing a
> reasonable amount of peers not supporting the v2 protocol.
>
> == Compatibility ==
>
> This proposal is backward compatible (as long as not enforced).
Kudos for making this second attempt backward compatible.
> Non-supporting
> peers can still use unencrypted communications.
>
> == Reference implementation ==
> * Complete Bitcoin Core implementation:
> https://github.com/bitcoin/bitcoin/pull/14032
> * Reference implementation of the AEAD in C:
> https://github.com/jonasschnelli/chacha20poly1305
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/87025ec1/attachment.sig>

2023-06-07 18:16:39

- reply

📅 Original date posted:2019-03-07
📝 Original message:>> On Mar 7, 2019, at 19:09, Wilmer Paulino via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> ...
>> Nodes on the network can not generally be trusted to send valid ("reject") messages, so this should only ever be used when connected to a trusted node.
>
> Nodes in the network generally rely on the assumption that they are connected to at least one honest peer, so we can actually converge on the set of honest peers and ban/disconnect any who send an invalid reject message for a valid transaction.
This implies the reject message is valid only when it is expected (i.e. the sender is knowingly sending invalid transactions), which is presumably useful only in a local development environment.
e

2023-06-07 18:14:32

- reply

📅 Original date posted:2018-09-03
📝 Original message:Without commenting on the other merits of either proposal, the addition of the service flag resolves bip151’s previously-discussed lack of backward compatibility.
e
> On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi
>
> During work on the implementation of BIP151 [1] I figured out that the current
> published proposal could be further optimized.
>
> I wrote an overhauled BIP151 specification with some – partially radical –
> changes.
>
> Now it’s unclear to me if this should be published under a new BIP nr. or if it
> is acceptable to change the existing 151 proposal.
> If a new BIP number would be required, I think withdrawing BIP151 should be
> done (which somehow indicates we should alter 151).
>
> The only BIP151 implementation I’m aware of is the one from Armory [2].
> BCoins implementation has been removed [3].
>
> The new proposal draft is available here:
> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
>
> Major changes
> =============
> - the encryption handshake no longer requires the v1 protocol, it’s a pure
> 32bytes-per-side „pseudorandom" key exchange that happens before anything else.
> - the multi message envelope has been removed.
> - a new NODE_ENCRYPTED service bit
> - the key derivation and what communication direction uses what key is now more
> specific
> - the length of a packet uses now a 3-byte integer with 23 available bits
> - introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result in
> some v2 messages require less bandwidth then v1
> - rekeying doesn’t require a message and can be signaled in the most
> significant bit in the packet-size field
>
>
> Points that are in discussion and may be added to the BIP (or to a new one):
>
> Hybrid NewHope key exchange
> ===========================
> The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus not
> considered quantum-safe.
> Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake
> protocol would very likely make the encryption PQ safe with little costs.
> There is also a straight forward implementation [6] from the NewHope team that
> has been submitted to NIST PQC project.
>
> Inefficiency of ChaCha20Poly1305 at openssh
> ========================================
> The proposed AEAD could eventually be further optimized.
> ChaCha20Poly1305 at openssh uses at least three rounds of ChaCha20 which
> eventually can be reduced to two (messages below <=64 bytes [inv, ping,
> pong,...] only require one round of ChaCha20, but two for the Poly1305 key and
> the message length encryption where the Poly1305 key chacha round „throws away“
> 32 bytes).
>
>
> I would suggest that we don’t rehash discussions about the general
> concept of encrypting the traffic. This has already been discussed [7][8].
>
> I hope we can limit this thread to discuss further ideas for optimisation as well as
> technical details of the published proposal or its implementation.
>
>
> [1] https://github.com/bitcoin/bitcoin/pull/14032
> [2] https://github.com/goatpig/BitcoinArmory/pull/510
> [3] https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662
> [4] https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope
> [5] https://eprint.iacr.org/2015/1092
> [6] https://github.com/newhopecrypto/newhope
>
> [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html
> [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html
>
>
> Thanks
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:14:25

- reply

📅 Original date posted:2018-09-17
📝 Original message:> Once hashrate gets large enough, no new miners (additional
hashrate) will want to join since their share of the hashrate is too
small to make a profit.
The share (hash power) of a miner is proportional to capital investment, not the newness of that investment. The efficiency of a new mine (inclusive of pooling pressures) can certainly be sufficient to outperform other miners, resulting in the departure of the latter, thus not preventing the entry of the former.
The point you should be making here is that energy consumption is regulated by the cost of capital (in addition to reward value and the cost of energy).
Note that higher efficiency mining does not reduce energy consumption, nor does variation in the necessary cost of mining hardware. The total energy cost is the control, not the hash rate. This is of course why proof-of-memory (space) is pointless. It simply shifts most of the energy cost to hardware manufacture, shipment, etc.
e
On Sep 17, 2018, at 06:18, Andrew <onelineproof at gmail.com> wrote:
>> I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
>
> In general, a target hashrate can be set by users (can be less or more
> than the peak hashrate). As long as hashrate is rising and still
> didn't reach the target, miners will incrementally get the reserve
> fees. Once the "contract" times out, the remaining part can be used as
> fees by the users who created the reserve fee "contract". So if
> hashrate remains the same or falls, then users get the reserve fees
> back.
>
> I agree that we can't stop people from being greedy. If they are not
> Bitcoin mining, they will try to put their energy to earn in some
> other way...The hashrate is related the demand for Bitcoin (price) and
> the amount of fees/subsidies the miners will get paid. For every level
> of mining rewards (based on demand) there exists a limit on the
> hashrate. Once hashrate gets large enough, no new miners (additional
> hashrate) will want to join since their share of the hashrate is too
> small to make a profit.
>
> Also with merge mining and proof of space we can be quite efficient in
> the future. But of course I sympathize with the "don't be greedy"
> philosophy, and it can be good to educate people to use less resources
> than they need, just I think it's a bit outside of the scope of what
> the Bitcoin software protocol does.

2023-06-07 18:14:24

- reply

📅 Original date posted:2018-09-17
📝 Original message:> Also with merge mining and proof of space we can be quite efficient in the future.
Proof of memory (space) is just proof of work with extra steps. It does not reduce energy consumption.
https://github.com/libbitcoin/libbitcoin/wiki/Proof-of-Memory-Facade
Merge mining is non-dedicated cost, so also does not improve energy efficiency. The irreducible *cost* is what matters.
https://github.com/libbitcoin/libbitcoin/wiki/Dedicated-Cost-Principle
e
On Sep 17, 2018, at 06:18, Andrew <onelineproof at gmail.com> wrote:
>> I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
>
> In general, a target hashrate can be set by users (can be less or more
> than the peak hashrate). As long as hashrate is rising and still
> didn't reach the target, miners will incrementally get the reserve
> fees. Once the "contract" times out, the remaining part can be used as
> fees by the users who created the reserve fee "contract". So if
> hashrate remains the same or falls, then users get the reserve fees
> back.
>
> I agree that we can't stop people from being greedy. If they are not
> Bitcoin mining, they will try to put their energy to earn in some
> other way...The hashrate is related the demand for Bitcoin (price) and
> the amount of fees/subsidies the miners will get paid. For every level
> of mining rewards (based on demand) there exists a limit on the
> hashrate. Once hashrate gets large enough, no new miners (additional
> hashrate) will want to join since their share of the hashrate is too
> small to make a profit.
>
> Also with merge mining and proof of space we can be quite efficient in
> the future. But of course I sympathize with the "don't be greedy"
> philosophy, and it can be good to educate people to use less resources
> than they need, just I think it's a bit outside of the scope of what
> the Bitcoin software protocol does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180917/8bcba278/attachment.html>

2023-06-07 18:14:22

- reply

📅 Original date posted:2018-09-16
📝 Original message:Hash rate cannot get “more uneconomical”. Mining will always seek a return equal to the cost of capital, as does all production, and the energy expended will always be fundamentally a function of the fee level and energy price. Fee level is determined by variable demand for a fixed supply of confirmation.
When you say greed you are simply referring to economically-rational behavior. It canny be eliminated, nor would that be a benefit.
WRT energy consumption, there is nothing that can be done to reduce it except for people to stop using Bitcoin or for energy to get more expensive.
e
> On Sep 15, 2018, at 15:45, Damian Williamson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
>
> I would prefer to see (not only with your proposal) greater bias toward hashrate being exponentially more uneconomical the more it rises to stifle greed. The current level of mining already greatly exceeds that necessary for the stability of the network and far lower hashrates are completely acceptible provided the network is protected from large switch-ons, which I say is achievable.
>
> I do have other thoughts to approach greed that I have not yet made formal on this list, much unrelated to your proposal, but, I see freedom of use of Bitcoin needing to be censorship resistant but not necessarily mining provided it is protected enough or free or flexible enough to allow for, say, 50k globally distributed standard mining hardware units to exist operating at any one time profitably. That said, I am PoW only and not PoS orientated.
>
> From: akaramaoun at gmail.com <akaramaoun at gmail.com> on behalf of Andrew <onelineproof at gmail.com>
> Sent: Sunday, 16 September 2018 2:01:19 AM
> To: Damian Williamson
> Cc: Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Selfish Mining Prevention
>
> @Moral Agent: No problem. I did ask in the first post what the current
> plans are for selfish miner prevention. So if anyone has any other
> relevant ideas (not just for selfish mining but for making mining more
> decentralized and competetive), then please post it, but I just prefer
> to focus on my proposal more than others.
>
> @Damian: I think you are concerned that this will incentivize more
> global resource consumption and will be detrimental to our
> environment? Personally, I believe centralization of energy does more
> harm to the environment rather than total energy consumption. If
> Bitcoin helps "power" to become more decentralized, then I wouldn't be
> surprised if total (global) energy consumption actually decreases. The
> debt based economy is forcing us to continuously grow and use up more
> resources, and collectivism is turning individuals into
> super-organisms capable of doing much more harm to the environment
> than can be done by one or a just a few individuals working
> independently. In my proposal, I actually allow for changing
> environmental conditions by measuring only the peak hashrate of the
> past year, and not the full history of blocks.
>
> On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech at live.com.au> wrote:
> >>This "reserve" part of the fee will be paid to miners if the hashrate
> >> rises.
> >
> >
> > Anticipating ongoing hashrate rise shows that you have not yet thought about
> > moving outside of the current greed model, a model wherein mining will
> > consume all available resources within the colony's objective just to spread
> > as far as possible with each new miner bringing diminishing individual
> > returns and shortening the life of Earth for no additional gain. Greed model
> > := bacteria.
> >
> > ________________________________
> > From: bitcoin-dev-bounces at lists.linuxfoundation.org
> > <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Andrew via
> > bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> > Sent: Friday, 14 September 2018 9:19:37 AM
> > To: Bitcoin Dev
> > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
> >
> > I discussed this more at bitcointalk:
> > https://bitcointalk.org/index.php?topic=4998410.0
> >
> > The attacks I'm interested in preventing are not only selfish mining
> > and collusion, but also more subtle attacks like block withholding,
> > and in general anything that aims to drive out the competition in
> > order to increase hashrate fraction. I also scrapped the idea of
> > changing the block subsidies, and I am only focuses on fees.
> >
> > You can read more about the motivation and details in the bitcointalk
> > thread, but my proposal in short would be to add the concept of
> > "reserve fees". When a user makes a transaction, for each txout
> > script, they can add parameters that specify the fraction of the total
> > fee that is held in "reserve" and the time it is held in "reserve"
> > (can set a limit of 2016 blocks). This "reserve" part of the fee will
> > be paid to miners if the hashrate rises. So if hashrate is currently h
> > and peak hashrate (from past year) is p, then for each period (1 day),
> > a new hashrate is calculated h1, and if h1 > h, then the fraction
> > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
> > released to miners for that period (spread out over the 144 blocks in
> > that period). And this will keep happening as long as hashrate keeps
> > rising, until the "contract" expires, and the leftover part can be
> > used by the owner of the unspent output, but it can only be used for
> > paying fees, not as inputs for future transactions (to save on block
> > space).
> >
> > This should incentivize miners to not drive out the competition, since
> > if they do, there will be less of these reserve fees given to miners.
> > Yes in the end the miners will get all the fees, but with rising
> > hashrate they get an unconditional subsidy that does not require
> > transactions, thus more space for transactions with fees.
> >
> > I can make a formal BIP and pull request, but I need to know if there
> > is interest in this. Now fees don't play such a large part of the
> > block reward, but they will get more important, and this change
> > wouldn't force anything (would be voluntary by each user), just miners
> > have to agree to it with a soft fork (so they don't spend from the
> > anyone-can-spend outputs used for reserve fees). Resource requirements
> > for validation are quite small I believe.
> >
> > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof at gmail.com> wrote:
> >> As I understand, selfish mining is an attack where miners collude to
> >> mine at a lower hashrate then with all miners working independently.
> >> What are the current strategies used to prevent this and what are the
> >> future plans?
> >>
> >> One idea I have is to let the block reward get "modulated" according
> >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
> >> consisting of 144 blocks, h is the hashrate of the last 144 block (1
> >> day) period, and r is the base subsidy (12.5 BTC currently). You can
> >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> >> peak you get the full reward. Otherwise you get less, down to a min of
> >> 0.5 r.
> >>
> >> If miners were to collude to mine at a lower than peak hashrate, then
> >> they may be able to do it profitably for 144 blocks, but after that,
> >> the reward would get modulated and it wouldn't be so much in their
> >> interest to continue mining at the lower hashrate.
> >>
> >> What flaws are there with this? I know it could be controversial due
> >> to easier mining present for early miners, so maybe it would have to
> >> be done in combination with a new more dynamic difficulty adjustment
> >> algorithm. But I don't see how hashrate can continue rising
> >> indefinitely, so a solution should be made for selfish mining.
> >>
> >> Also when subsidies stop and a fee market is needed, I guess a portion
> >> of the fees can be withheld for later if hashrate is not at peak.
> >>
> >>
> >> --
> >> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> >
> >
> >
> > --
> > PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> _______________________________________________
> 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/20180916/71c3ed59/attachment-0001.html>

2023-06-07 18:14:15

- reply

📅 Original date posted:2018-08-29
📝 Original message:You have created a straw man.
And light clients working against the P2P network (anonymous nodes) implies they are not fully validating, so you are contradicting yourself.
e
> On Aug 29, 2018, at 11:27, Jonas Schnelli <dev at jonasschnelli.ch> wrote:
>
>
>> The API implementation is not what is centralizing, nor is full indexation non-scalable. The centralization is in not running the API from a node under your own control. This is of course implied by the comment, “without the need for syncing”. In other words it is the deployment cost of the node that is centralizing.
>
> IMO an API that serves non verifiable data is supporting centralised validation. The „API" which supports one of the most important properties in Bitcoin – the ability to self-validate – is the data available via the p2p network.
>
>>
>> Yet if people relied only on bitcoind and never centralized services there would be *no* block explorers (and no secure light wallets), because it does not provide remote query and does not fully index.
>>
>> Block explorers and light wallets are pretty useful, so presumably some API must provide these features (ideally with reduced deployment cost). That will either be centralized or decentralized services. As such it seems wise to encourage the latter, as opposed to questioning whether there is any valid block explorer use case.
>
> Bitcoin-Core has all required features to partially „index“ data (called the wallet) and provides them via the RPC API. If you don’t need to serve thousands of wallets (which smells after centralised validation), selective indexing (wallets) are the right choice. Also, if you have a proper light client architecture, you can use Bitcoin Core in pruned mode (<10GB of data) to serve an endless amount of wallets (client/server mode, I guess that is what you are referring to with "light clients").
>
> I fail to see the use-cases where a fully index blockchain makes sense (the only one I can come up with is instant backup recovery where the transaction history needs to be preserved rather then recovering the UTXOs only).
>
> Also, the p2p protocol has built in light client support with BIP37 (bloom filters) and soon BIP158 will be available on the network which does allow privacy-preserving "light clients" in a way where no trusted layer is required (client <-> p2p network rather then client <-> API provider <-> p2p network).
>
> I don’t want to advocate against a full-index blockexplorer-like API. I just think its important to define the use case and be aware of the consequences and downsides.
>
> /jonas

2023-06-07 18:14:13

- reply

📅 Original date posted:2018-08-29
📝 Original message:The API implementation is not what is centralizing, nor is full indexation non-scalable. The centralization is in not running the API from a node under your own control. This is of course implied by the comment, “without the need for syncing”. In other words it is the deployment cost of the node that is centralizing.
Yet if people relied only on bitcoind and never centralized services there would be *no* block explorers (and no secure light wallets), because it does not provide remote query and does not fully index.
Block explorers and light wallets are pretty useful, so presumably some API must provide these features (ideally with reduced deployment cost). That will either be centralized or decentralized services. As such it seems wise to encourage the latter, as opposed to questioning whether there is any valid block explorer use case.
e
> On Aug 28, 2018, at 11:36, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi
>
> To give a critical viewpoint on a such API:
>
> Such APIs usually result in central validation, meaning that users trust API services rather the validating their own data. It break some of the fundamental properties of Bitcoin (avoid trusted third parties).
> Systems or applications depending on a full indexed blockchain (a thus such API) do usually scale pretty bad.
>
> I’d like to hear some concrete use-cases for a such block explorer(ish) API.
>
> Thanks
> —
> Jonas
>
>> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>>
>> Hello everyone,
>>
>> I am C++ & Node.js developer. I want to propose making a new Bitcoin API that supports fast quering of Bitcoin blocks and transactions without the need for syncing with all previous nodes.
>>
>> In a typical case where I want to build a full fleged Bitcoin explorer cum wallet system on my end with external APIs, I need to sync my node and then query for the information I need to show separately. I am proposing a unified method of finding/quering the blockchain data with a standardized template containing minimal information about the actual mined block or transaction yet satify the need of what I want to query.
>>
>> I am working on making a template and a support mechanism on Node.js. I want to propose it as an improvement (BIP). It will be a great help to future web developers who want to make something similar.
>>
>> Thanks
>> Sumit Lahiri.
>> _______________________________________________
>> 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