<unnamed>

Public Key

npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c

Profile Code

nprofile1qqsgygzlyuhejhvmuap80x3urx32uzzj9js5sfxr5wcp2f0m23v3v8spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqu7vu8

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:11:29 CEST

- 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-08 01:11:26 CEST

- 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-08 01:11:24 CEST

- 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-08 01:11:22 CEST

- 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-08 01:11:15 CEST

- 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-08 01:08:46 CEST

- 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-08 01:06:11 CEST

- 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-08 00:56:41 CEST

- 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-08 00:56:38 CEST

- 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-08 00:56:37 CEST

- 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-08 00:55:34 CEST

- 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-08 00:55:32 CEST

- 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-08 00:55:30 CEST

- 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-08 00:55:26 CEST

- 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-08 00:55:25 CEST

- 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-08 00:55:25 CEST

- 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-08 00:52:36 CEST

- 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 20:30:34 CEST

- 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 20:29:55 CEST

- 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 20:29:23 CEST

- 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 20:26:23 CEST

- 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 20:19:20 CEST

- 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 20:19:11 CEST

- 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 20:19:10 CEST

- 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 20:19:09 CEST

- 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 20:19:08 CEST

- 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 20:19:08 CEST

- 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 20:19:07 CEST

- 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 20:19:06 CEST

- 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 20:19:03 CEST

- 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 20:18:55 CEST

- 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 20:14:32 CEST

- 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 20:10:54 CEST

- reply

📅 Original date posted:2018-02-18
📝 Original message:As a soft fork, all preceding rules remain in effect. No rule has been “replaced”. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block.
e
> On Feb 18, 2018, at 09:04, Ryan Havar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork.
>
> So as such, there's not two separate limits or anything.
>
> P.S. what's up with your signature lol
>
>
> -Ryan
>
>
>
> -------- Original Message --------
>> On February 18, 2018 11:26 AM, CANNON via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> I have a question in reference to the increased blockspace enabled
>> by the segregated witness upgrade. Is this extra blockspace beyond
>> the legacy 1 MB limit limited to just witness data?
>>
>>
>>
>> Cannon
>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> Email: cannon at cannon-ciota.info
>>
>> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm
>> jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4
>> fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn
>> pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca
>> +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7
>> SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh
>> bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d
>> n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF
>> 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB
>> LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG
>> qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/
>> I+W6ny7qXt+pegLF4cYL
>> =YqEM
>> -----END PGP SIGNATURE-----
>>
>> 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 20:08:49 CEST

- reply

📅 Original date posted:2017-12-18
📝 Original message:How does one know what consensus has formed (around a UTXO set)?
e
> On Dec 18, 2017, at 16:27, Kalle Rosenbaum via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Mark
>
> Yes, it seems like sign-to-contract protocols, which I just now briefly read about [1][2], may need to use historic witnesses. That raises the question, what are Bitcoin witnesses for?
>
> To me it seems witnesses should be regarded as temporary. But it seems both respondents to this thread, Eric and Mark, mean that witnesses are forever. I regard witnesses as a way to authenticate updates to the UTXO set, and once buried deep enough in the blockchain, the witness is no longer needed, because consensus has formed around the UTXO set update.
>
> Suppose a transaction with an invalid witness happens to enter the blockchain and gets buried 100000 blocks down with the witness still available. Is the blockchain above it valid? I'd say the blockchain is valid and that it was a bug that the transaction made it into the blockchain. We will have to live with such bugs.
>
> Another way to put it: Suppose that all witnesses from 2017 dissappears from all nodes in 2020. Is the blockchain still valid? I think so. I would continue using it without looking back.
>
> With that approach, I think sign-to-contract protocols has to find ways to work in a witnessless environment. For example, users of such protocols can setup their own archival nodes.
>
> I'd love to hear alternative views on this.
>
> Thanks,
> /Kalle
>
> [1] https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf
> [2] https://bitcointalk.org/index.php?topic=893898.msg9861102#msg9861102
>
> 2017-12-18 18:30 GMT+01:00 Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>> Sign-to-contract enables some interesting protocols, none of which are in wide use as far as I’m aware. But if they were (and arguably this is an area that should be more developed), then SPV nodes validating these protocols will need access to witness data. If a node is performing IBD with assumevalid set to true, and is also intending to prune history, then there’s no reason to fetch those witnesses as far as I’m aware. But it would be a great disservice to the network for nodes intending to serve SPV clients to prune this portion of the block history.
>>
>>
>>> On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> You can't know (assume) a block is valid unless you have previously validated the block yourself. But in the case where you have, and then intend to rely on it in a future sync, there is no need for witness data for blocks you are not going to validate. So you can just not request it.
>>>
>>> However you will not be able to provide those blocks to nodes that *are* validating; the client is pruned and therefore not a peer (cannot reciprocate). (An SPV client is similarly not a peer; it is a more deeply pruned client than the witnessless client.)
>>>
>>> There is no other reason that a node requires witness data. SPV clients don't need it as it is neither require it to verify header commitment to transactions nor to extract payment addresses from them.
>>>
>>> The harm to the network by pruning is that eventually it can become harder and even impossible for anyone to validate the chain. But because you are fully validating you individually remain secure, so there is no individual incentive working against this system harm.
>>>
>>> e
>>>
>>>> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
>>>>
>>>> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>>>>>
>>>>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> >
>>>>> > Dear list,
>>>>> >
>>>>> > I find it hard to understand why a full node that does initial block
>>>>> > download also must download witnesses if they are going to skip verification anyway.
>>>>>
>>>>> Why run a full node if you are not going to verify the chain?
>>>>
>>>> I meant to say "I find it hard to understand why a full node that does initial block
>>>> download also must download witnesses when it is going to skip verification of the witnesses anyway."
>>>>
>>>> I'm referring to the "assumevalid" feature of Bitcoin Core that skips signature verification up to block X. Or have I misunderstood assumevalid?
>>>>
>>>> /Kalle
>>>>
>>>>>
>>>>> > If my full node skips signature verification for
>>>>> > blocks earlier than X, it seems the reasons for downloading the
>>>>> > witnesses for those blocks are:
>>>>> >
>>>>> > * to be able to send witnesses to other nodes.
>>>>> >
>>>>> > * to verify the witness root hash of the blocks
>>>>> >
>>>>> > I suppose that it's important to verify the witness root hash because
>>>>> > a bad peer may send me invalid witnesses during initial block
>>>>> > download, and if I don't verify that the witness root hash actually
>>>>> > commits to them, I will get banned by peers requesting the blocks from
>>>>> > me because I send them garbage.
>>>>> > So both the reasons above (there may be more that I don't know about)
>>>>> > are actually the same reason: To be able to send witnesses to others
>>>>> > without getting banned.
>>>>> >
>>>>> > What if a node could chose not to download witnesses and thus chose to
>>>>> > send only witnessless blocks to peers. Let's call these nodes
>>>>> > witnessless nodes. Note that witnessless nodes are only witnessless
>>>>> > for blocks up to X. Everything after X is fully verified.
>>>>> >
>>>>> > Witnessless nodes would be able to sync faster because it needs to
>>>>> > download less data to calculate their UTXO set. They would therefore
>>>>> > more quickly be able to provide full service to SPV wallets and its
>>>>> > local wallets as well as serving blocks to other witnessless nodes
>>>>> > with same or higher assumevalid block. For witnessless nodes with
>>>>> > lower assumevalid they can serve at least some blocks. It could also
>>>>> > serve blocks to non-segwit nodes.
>>>>> >
>>>>> > Do witnessless nodes risk dividing the network in two parts, one
>>>>> > witnessless and one with full nodes, with few connections between the
>>>>> > parts?
>>>>> >
>>>>> > So basically, what are the reasons not to implement witnessless
>>>>> > nodes?
>>>>> >
>>>>> > Thank you,
>>>>> > /Kalle
>>>>> > _______________________________________________
>>>>> > 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
>>
>>
>> _______________________________________________
>> 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/20171218/f9f579ba/attachment-0001.html>

2023-06-07 20:07:25 CEST

- reply

📅 Original date posted:2017-11-11
📝 Original message:> On Nov 6, 2017, at 20:38, Devrandom <c1.bitcoin at niftybox.net> wrote:
>
> A hard-fork is a situation where non-upgraded nodes reject a block mined and relayed by upgraded nodes.
As Peter pointed out, that is the case here.
> This creates a fork that cannot heal regardless of what follows.
That is not a condition of the hard fork concept.
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
Softfork
A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.
Hardfork
A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.
The essential element of a hard fork is that the new rule may cause rejection of blocks that are not rejected by old rules (thereby requiring that all users adopt the new rule in order to avoid a split). The reason a hard fork is interesting is that it can create a chain split even if it is enforced by majority hash power.
That is not the case with a soft fork and it is not the case here. A split can occur. The fact that it is possible for the split to also eventually orphan the old nodes does not make it a soft fork. A soft fork requires that a hash power majority can impose the rule. However, under the proposed new rule the hash power majority (according to the new rule) cannot impose the rule on existing nodes.
> This proposal is not a hard-fork, because the non-upgraded node *will heal* if the attack has less than 1/2 of the original-POW power in the long term.
Nothing about this proposal implies an attack. From the Motivation section:
Mitigate centralization pressures by introducing a POW that does not have economies of scale
Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
> The cost of such an attack is the cost of a normal "51%" attack, multiplied by the fractional weight of the original POW (e.g. 0.75 or 0.5).
>
> So rather than saying this is a hard-fork, I would say that this is a soft-fork with reduced security for non-upgraded nodes.
Presumably this preference exists because it implies the new rule would not cause a chain split, making it more acceptable to a risk-averse economy. This is precisely why it should be described correctly.
> I would also say that the reduction in security is proportional to the reduction in weight of the original POW at the time of attack.
>
> As mentioned before, the original-POW weight starts at 1.0 and is reduced over a long period of time. I would set up the transition curve so that all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes protecting high economic value would upgrade early.
In reality you have no way to know if/when people would adopt this rule. What matters in the proposal is that people who do adopt it are well aware of its ability to split them from the existing economy.
e
>> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.
>>
>> e
>>
>>> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> +1 to all of Peter Todd's comments
>>>
>>>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>>>
>>>> Some quick thoughts...
>>>>
>>>> > Hi all,
>>>> >
>>>> > Feedback is welcome on the draft below. In particular, I want to see if
>>>> > there is interest in further development of the idea and also interested in
>>>> > any attack vectors or undesirable dynamics.
>>>> >
>>>> > (Formatted version available here:
>>>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>>>> >
>>>> > # Soft-fork Introduction of a New POW
>>>>
>>>> First of all, I don't think you can really call this a soft-fork; I'd call it a
>>>> "pseudo-soft-fork"
>>>>
>>>> My reasoning being that after implementation, a chain with less total work than
>>>> the main chain - but more total SHA256^2 work than the main chain - might be
>>>> followed by non-supporting clients. It's got some properties of a soft-fork,
>>>> but it's security model is definitely different.
>>>>
>>>> > ### Aux POW intermediate block
>>>> >
>>>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>>>> > alternates between the two POWs.
>>>> > Each aux-POW block points to the previous normal block and contains
>>>> > transactions just like a normal block.
>>>> > Each normal block points to the previous aux-POW block and must contain all
>>>> > transactions from the aux-POW block.
>>>>
>>>> Note how you're basically proposing for the block interval to be decreased,
>>>> which has security implications due to increased orphan rates.
>>>>
>>>> > ### Heaviest chain rule change
>>>> >
>>>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>>>> > chain in case of attack. However,
>>>>
>>>> Exactly! Not really a soft-fork.
>>>>
>>>> --
>>>> 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
>> _______________________________________________
>> 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/20171111/1ce6f87b/attachment.html>

2023-06-07 20:07:24 CEST

- reply

📅 Original date posted:2017-11-06
📝 Original message:If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.
e
> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> +1 to all of Peter Todd's comments
>
>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below. In particular, I want to see if
>> > there is interest in further development of the idea and also interested in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>>
>> First of all, I don't think you can really call this a soft-fork; I'd call it a
>> "pseudo-soft-fork"
>>
>> My reasoning being that after implementation, a chain with less total work than
>> the main chain - but more total SHA256^2 work than the main chain - might be
>> followed by non-supporting clients. It's got some properties of a soft-fork,
>> but it's security model is definitely different.
>>
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain all
>> > transactions from the aux-POW block.
>>
>> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>>
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>> > chain in case of attack. However,
>>
>> Exactly! Not really a soft-fork.
>>
>> --
>> 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/20171106/08da67fe/attachment-0001.html>

2023-06-07 20:01:53 CEST

- reply

📅 Original date posted:2017-05-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Cameron,
Presumably the "very serious security vulnerability" posed is one of
increased centralization of hash power. Would this danger exist
without the patent risk?
e
On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote:
> Thank you for your reply Andreas,
>
> I can assure you that I have many motivations for activating
> SegWit.
>
> Before studding ASICBOOST I wanted to activate SegWit as it is a
wonderful upgrade for Bitcoin. It seems to me that virtually the
entire Bitcoin Ecosystem agrees with me. Except for around 67% of the
mining hash-rate who very conspicuously refuse to signal for it’s
activation.
>
> So, I started searching for the motivations of such a large amount
of the mining hash-rate holding a position that isn’t at-all
represented in the wider Bitcoin Community. My study of ASICBOOST lead
to a ‘bingo’ moment: If one assumes that the 67% of the hash rate
that refuse to signal for SegWit are using ASICBOOST. The entire
picture of this political stalemate became much more understandable.
>
> This only strengthened my resolve to activate SegWit: not only is
SegWit great, it partially mitigates a very serious security
vulnerability.
>
> This is why I call into question why you would suggest:
>
> “This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.”
>
> 1. I am not conflating the issues. I would argue that very fact
that SegWit has not been activated yet is directly because of
CVE-2017-9230.
> 2. I have no reason to believe that SegWit is contentious, except
for the attackers who it would frustrate.
> 3. I have no negative responses to my endeavours to get ASICBOOST
> as
regarded as a legitimate security vulnerability. This would suggest
that it is not contentious in the wider technical community.
>
> If SegWit is NOT contentious within the technical community and it
is NOT contentious to regard CVE-2017-9230 as a credible security
vulnerability. Then using it as partial security fix for a security
vulnerability SHOULD NOT be contentious.
>
> If you believe that SegWit is contentious within the technical
community. Or you believe CVE-2017-9230 should not be regarded as a
credible security vulnerability. Then I would logically agree with you
that we should separate the issues so that we may gain consensus.
However, I just don’t see this as the case.
>
> Cameron.
>
>
>> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos
<andreas at antonopoulos.com> wrote:
>>
>> I rarely post here, out of respect to the mailing list. But
>> since
my name was mentioned...
>>
>> I much prefer Gregory Maxwell's proposal to defuse covert
>> ASICBOOST
(only) with a segwit-like commitment to the coinbase which does not
obligate miners to signal Segwit or implement Segwit, thus disarming
any suspicion that the issue is being exploited only to activate Segwit.
>>
>> This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.
>>
>> Politicising CVE is damaging to the long term bitcoin
>> development
and to its security. Not claiming that is the intent here, but the
damage is done by the mere appearance of motive.
>>
>>
>>
>> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Hello Bitcoin-Dev,
>>
>> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a
>> severe
(3) (4) and actively exploited (5) security vulnerability.
>>
>> To learn more about this vulnerability please read Jeremy
>> Rubin’s
detailed report:
>> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>>
>> Andreas Antonopoulos has an excellent presentation on why
>> asicboost
is dangerous:
>> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>>
>> In decisions on the #bitcoin-core-dev IRC channel; It was
>> proposed,
without negative feedback, that SegWit be used as a partial-mitigation
of CVE-2017-9230.
>>
>> SegWit partially mitigates asicboost with the common reasonable
assumption that any block that doesn’t include a witness commit in
it's coinbase transaction was mined using covert asicboost. Making
the use of covert asicboost far more conspicuous.
>>
>> It was also proposed that this partial mitigation should be
>> quickly
strengthened via another soft-fork that makes the inclusion of witness
commits mandatory, without negative feedback.
>>
>> The security trade-offs of deploying a partial-mitigation to
CVE-2017-9230 quickly vs more slowly but more conservatively is under
intense debate. The author of this post has a strong preference to
the swiftest viable option.
>>
>> Cameron.
>>
>>
>> (1) CVE Entry:
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>>
>> (2) Announcement of CVE to Mailing List:
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.
html
>>
>> (3) Discussion of the perverse incentives created by 'ASICBOOST'
>> by
Ryan Grant:
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.
html
>>
>> (4) Discussion of ASICBOOST's non-independent PoW calculation by
Tier Nolan:
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.
html
>>
>> (5) Evidence of Active Exploit by Gregory Maxwell:
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/01399
6.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZJ+Q1AAoJEDzYwH8LXOFOqakH/R1YCifIGjV07vnnsxeC/77x
d6w5tBmtEd5MLzrX/6VtMoI8UzgLEcDM1WfFox3jDVz/HurkTVorliyJrr14BVsc
rL2nTbfychYh1rAdTIsNwFt15Wgjcp/5eAq7Lw5TM5OJ3YbPn2zWJY19QmjEAJ+M
kGz26R+IJL1095yed5RN2JoN8O9x+HVdtIjaHJJRJzLsy+3g22zMWgN1nZN0olhX
mFQJZbvS0gQyiRGJmNku3zP5Qg2cFzWt+VBtFrzNu1QTTkbK2e1owHOmpgfygTD3
g3F4VoDfyA7pBnpMMMjjTaCaG34Am3CvYu8iYnZXy85s2ZjC+XeKgqMkBLj4+q8=
=A3ne
-----END PGP SIGNATURE-----

2023-06-07 20:01:08 CEST

- reply

📅 Original date posted:2017-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 05/12/2017 08:54 PM, ZmnSCPxj wrote:
> Good morning,
>
>> I do not see why any person would want to pay, and then trust,
>> another to mine accordingly. Each person can mine and attain
>> their level of influence. This not only avoids the side payment,
>> but earns the person money.
>
> The problem, is that, the rate of conversion of Bitcoin-> hashrate
> is different for different people.
>
> For some, it's very cheap to convert Bitcoin -> hashrate. For
> others, it's very expensive. The reason, is the large difference
> in electricity rates depending on country.
>
> It's all very well for those who can get electricity cheaply. But,
> for some, it is not.
>
> Thus, paying someone with better Bitcoin->hashrate conversion via
> fees such as these is more economically logical, than to suffer a
> lower Bitcoin->hashrate conversion.
Despite the tedious explanation of absolute advantage, this is simply
an argument for all people to pay one person to mine, as there is
presumably always one person who will be able to mine more efficiently
than all others.
The argument fails to recognize that mining for one's self may (or may
not) result in a net loss, but donating to a miner in the hope of some
action is comparatively a total loss. One is an expense in exchange
for the intended social outcome, and the other is payment for
representative government.
And in this form of representative government that you propose, if we
assume that miners are somehow bound to honor the payments (votes),
how are the votes distributed? Is this supposed to be democratic in
the sense of one person one vote? Your argument below is clearly based
on that idea. However the result would be very different. The
wealthier would of course exert the greater influence. So the idea
fails by its own standard.
>> If a person does not want to bother then he/she clearly does not
>> have a strong opinion. As developers we should be focused on
>> reducing the complexities of mining and of validation, not
>> finding ways for people to avoid participating in these
>> necessarily distributed roles.
>
> It is also, very obviously, clear that you are operating under
> very strange assumptions, that all people are already equal
> somehow, or that someone who is paid x10 more is strictly superior,
> even though skill-wise and ability-wise, they are the same, and the
> one paid less is simply suffering due to the country where he or
> she is born in, through no fault of their own.
You are making a political argument wrapped in appeal to emotion. Both
are pointless in this context.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZFptnAAoJEDzYwH8LXOFOs34IAIciCyrn7FMq7leiQ6jAvr3g
sW9YRQ403IJd9BiBj3lI6xpsxtJ4zezkU2AFZUTf9X6AoIX/UJtPb8clb4RIpicf
ACK+iec4YM+15kgPcLyLij3aALvNNCNQ+XuXeHT1bHqfukP+bc/DBAnm48qGvW9o
ugRIFFWqtt8FB9MAh/VM6SsfaQc3D8hk6Dh3SyEVzohkrgWpRVQKNGD/FYY8odCA
8KPo/R3jrgO6JNR0EGxR3SatuKLYUgMcl3n63fanAOh8ESHGHHiP0SEpYoG3wOCt
eAyEcPI4SezJHBjJWcsPe0hhLg0HkvFaLwQe8tGHXrCzsZ18QTNBA0h9npWqqi4=
=LKcb
-----END PGP SIGNATURE-----

2023-06-07 20:01:08 CEST

- reply

📅 Original date posted:2017-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 05/12/2017 10:45 PM, Luke Dashjr wrote:
> On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote:
>> If people want to influence the decisions of miners, all they
>> need to do is mine.
>
> Most people cannot mine except at a huge expense (profit is limited
> to few people via monopoly and electric costs). But more
> importantly, the profits from every miner you buy will go to pay
> for Bitmain growing their arsenal more than enough to offset your
> influence.
You seem to be suggesting that in order to decentralize mining nobody
should mine. I'm having a hard time making sense out of that.
> Mining is simply broken at this point.
So maybe you are just saying that nobody should mine because it's a
zero sum game that one miner will always win and therefore we should
not push up the hash rate by trying to compete because the same miner
just makes more money on the hardware. Apparently it is economically
impossible for anyone else to compete in hardware as well.
I agree that there is a serious problem of mining centralization (and
economic/validation centralization). If these problems are not solved
Bitcoin will fail. It will rise again, with people a little wiser, but
the disruption will be unfortunate for many.
I don't want to see that, so I tend to not advocate for solutions that
run counter to the security model. Many people must mine, there is no
way around it. And if people want a say with respect to mining, they
should mine. As a developer I would rather work toward fixing that
problem than putting a band-aid over it that basically tells people
that the way they get their say is by donating to the big mining
personality of their choice.
>> There is nothing inherently wrong with paying people to run nodes
>> or signal "readiness", but there is no reason whatsoever to
>> consider these ideas beneficial from a personal/economic or
>> security/decentralization standpoint.
>
> Running a node and mining are two very different things.
No, really?
If it wasn't clear, I was relating two sets of proposals. One aims to
find ways to fund node operation and the other aims to fund miner
signaling. The former fails to understand the economics and security
model of full node operation and the latter fails to understand that
distributed mining is as essential to Bitcoin survival as distributed
validation.
>> The argument fails to recognize that mining for one's self may
>> (or may not) result in a net loss, but donating to a miner in the
>> hope of some action is comparatively a total loss. One is an
>> expense in exchange for the intended social outcome, and the
>> other is payment for representative government.
>>
>> And in this form of representative government that you propose,
>> if we assume that miners are somehow bound to honor the payments
>> (votes), ...
>
> First of all, this isn't donating to miners, but forbidding them
> from mining your transaction (and thereby collecting your
> transaction fee) unless they signal for the softfork.
I assumed that people understand how markets work. Miners compete for
fees. By eliminating a subset of potential sellers (currently by ~70%)
the buyer raises his own price. Presumably the price is raised even
further by increasing the size of the transaction. This is either a
donation to the cause or a purchase of the signal, depending on how
you want to describe it (all donations are purchases of a sort).
So there is a cost increase that could alternatively be incurred by
mining (i.e. assuming a lossy operation). If one is going to spend
money on influencing mining one might as well not do it in a way that
contributes to centralization while training people to rely on it.
> Secondly, your argument here assumes miners are a government or
> control Bitcoin in some way. This is not correct.
Miners absolutely "control Bitcoin in some way" - that is their
purpose. They control the ordering of transactions, and with
sufficient hash power can double-spend and therefore make the network
unusable. Why would you bother to make me type this?
> So miners are in fact already bound to honour the wishes of the
> greater economy, and their refusal to do so is an attack on the
> network.
Absolute nonsense, a miner incurs no obligation to the "greater
economy". He is offering a service in voluntary trade. He is likely to
do what it takes to spend his coinbase, assuming he wants to. This
gives the economy strong economic control over his behavior. But
nothing whatsoever obligates him to signal soft forks (or not optimize
his operations).
Double spending is an attack, on the person who has been robbed. The
state enforcing a patent is an attack, on the person against whom it
is enforced. These are called attacks **because they are actually
theft**. You are conflating normal operation (despite disagreement
with some unmeasurable "wishes") with robbery.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZFqstAAoJEDzYwH8LXOFOsvsH/2aWlsfi5hB1IrnX1UBsMJl8
+R6BZE+d5C5uNkk6/yENHqwwgTv8yhOKav2Y7xYx/DedhVftX90h9CtdeKGgCS2H
cYNtoNauAvF2nlEMGGGcinLkYbS0dyQm07zwOI8gwuzbkslFGxLFClngFlFgMF4S
4/YCWvtRJ0O5dkrAZuKwG/7JQ1JNopbDTxssirA/OzwTGjq7BUv7INyR8nBbOp6I
xcrjq2bXja6Kxo08pr3+UrWc+0LO8fvX9z3rkm6USyin7TueS85gEUsk30h1Xng3
Al1QccJ9KKJ+iQKdGozeHD2OlTFC1zW2kZaWbhgxOewDlmf7cNwZXEUwfr4C4Hs=
=j5eo
-----END PGP SIGNATURE-----

2023-06-07 20:01:07 CEST

- reply

📅 Original date posted:2017-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
If people want to influence the decisions of miners, all they need to
do is mine.
I do not see why any person would want to pay, and then trust, another
to mine accordingly. Each person can mine and attain their level of
influence. This not only avoids the side payment, but earns the person
money.
There is nothing inherently wrong with paying people to run nodes or
signal "readiness", but there is no reason whatsoever to consider
these ideas beneficial from a personal/economic or
security/decentralization standpoint.
If you are not running a node you are not part of the economic
consensus. If you are not mining you have no say in transaction
ordering. The "solution" is both obvious and necessary to secure Bitcoin
.
If a person does not want to bother then he/she clearly does not have
a strong opinion. As developers we should be focused on reducing the
complexities of mining and of validation, not finding ways for people
to avoid participating in these necessarily distributed roles.
e
On 05/12/2017 05:49 PM, Luke Dashjr via bitcoin-dev wrote:
> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
>> nVersion signaling is already technically unenforceable, in the
>> sense that we don't have good ways of ensuring miners actually
>> adopt the rules they're claiming to signal. Equally, it's users
>> who ultimately adopt rules, not miners, and attempting to pay
>> miners to signal certain bits will further confuse this point.
>
> This BIP doesn't change that. Enforcement remains primarily by
> users.
>
>> Quite likely the outcome of users trying to anonymously pay
>> anonymous miners to signal certain bits will be the complete
>> breakdown of the honesty of the nVersion signalling system,
>> currently enforced only by "gentlemans agreement".
>
> You assume users will pay for signalling of softforks prematurely.
> So long as it waits until deployment of the softfork is
> widespread, this risk is minimal. At worst, it creates risks
> similar to a UASF. So long as UASF is the alternative, this way
> seems strictly better.
>
>> Also, as an aside, this "specification" again shows the
>> inadequacy and unreadability of English language specifications.
>> I'd strongly suggest you delete it and instead mark the
>> "reference implementation" as the specification.
>
> How so?
>
> On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:
>> Minor editorial nitpick, this paragraph is repeated, maybe one of
>> these should be Testnet?
>>
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch
>> timestamp TBD).
>>
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch
>> timestamp TBD).
>
> Fixed, thanks.
>
> Luke _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJZFnzNAAoJEDzYwH8LXOFOlMsH/2Li7lDTr57EC2mSt4BuCf3Q
Q1sx21CBumm6OQKMxd207wgXTaxVJVmrGPXfJ6ZW8Bf+2tMKgc/LsZfzXdEo5+Fx
iTkdgJeW8QbKiEGzOFKMxWXH9jyCnd0WcDnKw/v7WqUhYfy2c9wz9RzCMY5iJqph
xd2+DeiEIjXIvE+l2TXGwjnB8Wp41QeY0I98kG3HHwNvNREbbGS/BjtLj5+eBygU
m+6dxkJoEttms31F47WFoZRzN7u5pe3BY5kDfZdVkbG7MOomSYwlhMvR3PtA1wrz
FeAUcHpp9MPj+qgHGwAGMfJiG/5WsVSrl/dJTm68zPOdwH60fMNNT/Srfbj1Ty8=
=9Xik
-----END PGP SIGNATURE-----

2023-06-07 19:59:48 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/08/2017 11:15 AM, praxeology_guy via bitcoin-dev wrote:
> ASICBOOST causes Bitcoin's PoW to become more memory/latency
> throttled instead of raw computation throttled.
>
> There is the equation: Power Cost + Captial Rent + Labor ~= block
> reward + fees
>
> Capital Rent is a barrier to entry, and hence in desiring a more
> distributed system, we would like to minimize the Capital Rent
> portion of the equation.
>
> Resolving memory/latency throttle requires a greater Captial Rent
> than raw computation throttle.
>
> Hence (agreeing with Luke), ASICBOOST is not desirable, even if it
> wasn't a government enforced monopoly on mining.
>
> Please let me know if I made a mistake.
Electric power is not an abstraction, it's the output of machines.
What you are referring to as Power Cost typically consists of a higher
rent component than computing hardware, where rent is the sharing of a
resource by multiple people. So by your reasoning you appear to have
drawn the wrong conclusion.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY6TEUAAoJEDzYwH8LXOFOiQIH/RN8YhLCokZtGoFZ+dOgwCxc
/ej3m9CXVGyWvcCJMQd2ZJFgpjL5mgJdcCdaWoTeZfh0Nmvc3hDex46wWpUZc/mR
NbRj56hyqe+cWAwQJJpAOWiJXjEuS3npXFvZIBpslECXCL6U+LSxdW9WSg0w+HBD
jihIlG2TeGSrMR/atKfSnVRAnz9ahPvgUwcR8l7oLsjP2JvBGl+fQHL5MwpvRg4a
sXK3eMIeH7wGJyiKOwXyMeRMfCRlwpkBCw0R+FYt2Q5l/uwkRAKuJiYUlJixFAZA
ggQth02pFn/tASB49oBKZU3QviVRGgoIQ5DFyI8OPa10FeVsxaeNeBQylwWJA3c=
=Ryo5
-----END PGP SIGNATURE-----

2023-06-07 19:59:40 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/07/2017 02:44 PM, Tomas via bitcoin-dev wrote:
> Hi Eric,
>
> On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
>> Optimization for lower memory platforms then becomes a process
>> of reducing the need for paging. This is the purpose of a cache.
>> The seam between disk and memory can be filled quite nicely by a
>> small amount of cache. On high RAM systems any cache is actually
>> a de-optimization but on low RAM systems it can prevent excessive
>> paging. This is directly analogous to a CPU cache.
>
>
> I am not entirely sure I agree with that, or understand it
> correctly.
>
> If -for example - the data of some application is a set of
> records which can be sorted from least frequently used to most
> frequently used then doing just that sort will beat any
> application-layer cache. Regardless of size of data and size of
> RAM, you simply allow the OS to use disk caching or memory map
> caching to work its magic .
It's a reasonable assumption, and given that the no-explicit-cache
implementation is a subset of the optionally-cached implementation,
was of course the initial implementation.
> In fact, I would argue that an application-layer cache *only*
> makes sense if the data model shows a *hard* distinction between
> often and not often used data. If usage-frequency is a continuous
> line, caching is best left to the OS by focussing on proper spatial
> and temporal locality of reference of your data, because the OS has
> much more information to make the right decision.
In practice this is not the case. The Bitcoin data model is neither
continuous nor strictly segregated by usage.
It is true that with sufficient RAM a cache is totally
counterproductive. It is also my experience that an independent UTXO
store is not a reasonable/necessary trade of disk space, memory
scalability, and/or code complexity in exchange for speed.
But on lower memory systems a explicit cache is beneficial. The
difference is clearly measurable in production code by simply changing
the cache limit and testing on various configurations.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY6CXnAAoJEDzYwH8LXOFOf0YH/2qk3hYC6iEDW/DWM2ffkdb9
QM7A29Pvbfw9Wjr5Xx+ugIQvlAr4T+nByOCT6AnrqNU5K3UUmbC0KIB1rEL94hsK
QYVlLs0cOrjg8qKJpck+wcgiWw3VbEa/Y44hK7NLUxoy2HsLYaxPhqFH3GGgowqR
syga626jf2YUyudZxj1gFuqn7grkwghnzdrEUJMcqQo8IvCqjftGXlKxBGyB/AIs
Dx+5EWO9Q9IxrNpg/fsKKB6xkMxkmSx2hbD7dmEBvi/afbVF66rDTinjInG/LCju
pV7kT/GAWqGQGku6sQyAOexsxVhWA8EA/QEjvbyyGb+3YnR0s6nPk+CxO+RkOgo=
=e+Pr
-----END PGP SIGNATURE-----

2023-06-07 19:59:39 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/07/2017 11:39 AM, Bram Cohen via bitcoin-dev wrote:
> Expanding on this question a bit, it's optimized for parallel
> access, but hard drive access isn't parallel and memory accesses
> are very fast, so shouldn't the target of optimization be about
> cramming as much as possible in memory and minimizing disk
> accesses?
While this may seem to be the case it is not generally optimal. The
question is overly broad as one may or may not be optimizing for any
combination of:
startup time (first usability)
warm-up time (priming)
shutdown time (flush)
fault tolerance (hard shutdown survivability)
top block validation (read speed)
full chain validation (read/write speed)
RAM consumption
Disk consumption
Query response
Servers (big RAM)
Desktops (small RAM)
Mining (fast validation)
Wallets (background performance)
SSD vs. HDD
But even limiting the question to input validation, all of these
considerations (at least) are present.
Ideally one wants the simplest implementation that is optimal under
all considerations. While this may be a unicorn, it is possible to
achieve a simple implementation (relative to alternatives) that allows
for the trade-offs necessary to be managed through configuration (by
the user and/or implementation).
Shoving the entire data set into RAM has the obvious problem of
limited RAM. Eventually the OS will be paging more of the data back to
disk (as virtual RAM). In other words this does not scale, as a change
in hardware disproportionately impacts performance. Ideally one wants
the trade between "disk" and "memory" to be made by the underlying
platform, as that is its purpose. Creating one data structure for disk
and another for memory not only increases complexity, but denies the
platform visibility into this trade-off. As such the platform
eventually ends up working directly against the optimization.
An on-disk structure that is not mapped into memory by the application
allows the operating system to maintain as much or as little state in
memory as it considers optimal, given the other tasks that the user
has given it. In the case of memory mapped files (which are optimized
by all operating systems as central to their virtual memory systems)
it is possible for everything from zero to the full store to be memory
resident.
Optimization for lower memory platforms then becomes a process of
reducing the need for paging. This is the purpose of a cache. The seam
between disk and memory can be filled quite nicely by a small amount
of cache. On high RAM systems any cache is actually a de-optimization
but on low RAM systems it can prevent excessive paging. This is
directly analogous to a CPU cache. There are clear optimal points in
terms of cache size, and the implementation and management of such a
cache can and should be internal to a store. Of course a cache cannot
provide perfect scale all the way to zero RAM, but it scales quite
well for actual systems.
While a particular drive may not support parallel operations one
should not assume that a disk-based store does not benefit from
parallelism. Simply refer to the model described above and you will
see that with enough memory the entire blockchain can be
memory-resident, and for high performance operations a fraction of
that is sufficient for a high degree of parallelism.
In practice a cache of about 10k transactions worth of outputs is
optimal for 8GB RAM. This requires just a few blocks for warm-up,
which can be primed in inconsequential time at startup. Fault
tolerance can be managed by flushing after all writes, which also
reduces shutdown time to zero. For higher performance systems,
flushing can be disabled entirely, increasing shutdown time but also
dramatically increasing write performance. Given that the blockchain
is a cache, this is a very reasonable trade-off in some scenarios. The
model works just as well with HDD as SSD, although certainly SSD
performs better overall.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY5+7GAAoJEDzYwH8LXOFOsAsH/3QK55aWH6sAi6OsTwV1FLZV
Y/2SSjwn1vUh55MDkPpCxDwV99JqVwpk0vGM8mGg5s4ZS8sxOPqwGiBz/SZWbF9v
oStJS0DjUPnbYtI/mrC30GuAYVcKnc5DFDHvjX6f0xrLIzViFR7eiW0npUH6Xipt
RI9Mockaf1CqqGExtbIqWal0YDEQGH0ekXRp7uEjh8nPUoKqTVvxDCgqVooQfvfx
EeKX9ruSv/r91EM1JQuH8HBBF7+R24tmMtwbpGx0zrDg5ytpIyrRzVH/ze1Mj2a3
ZxThvofGzhKcDiTPWiJI11DBYUvhSH4Kx0uWLzFUA0gxPfWkZQKJWNDl2CEwljk=
=C7rD
-----END PGP SIGNATURE-----

2023-06-07 19:59:36 CEST

- reply

📅 Original date posted:2017-04-11
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/11/2017 01:43 AM, Tomas wrote:
> Splitting transactions only happens *on storage* and is just a
> minor optimization compared to storing them in full.
Ok
> Sure, we can still call switching tips a "reorg". And it is indeed
> a trade off as orphan blocks are stored, but a block in the spend
> tree takes only ~12kb and contains the required state information.
>
It's not the headers/tx-hashes of the blocks that I'm referring to, it
is the confirmation and spend information relative to all txs and all
outputs for each branch. This reverse navigation (i.e. utxo
information) is essential, must be persistent and is branch-relative.
> The blockchain is - by design - only eventually consistent across
> nodes. Even if nodes would use the same "tip-selection" rules, you
> cannot rely on all blocks being propagated and hence each
> transaction having the same number of confirmations across all
> nodes.
>
> As a simpler example, if two miners both mine a block at
> approximately the same time and send it to each other, then surely
> they would want to continue mining on their own block. Otherwise
> they would be throwing away their own reward.
That's not your concurrent validation scenario. In the scenario you
described, the person chooses the weaker block of two that require
validation because it's better somehow, not because it's his own
(which does not require validation).
> And yes, this can also happen over multiple blocks, but the chances
> of consistency are vastly increased with each confirmation.
Consistency is reached, despite seeing things at different times,
because people use the same rules. If the economy ran on arbitrary
block preference consistency would be elusive.
> I am not talking about rejecting blocks, I am only talking choosing
> on which tip to mine.
This line of reasoning has me a bit baffled. Yet as I said, it's not
important to the question at hand. It is not likely to be optimal to
validate concurrently even if you consider selection of a weaker block
advantageous.
>> If you intend this to be useful it has to help build the chain,
>> not just rely on hardwiring checkpoints once rule changes are
>> presumed to be buried deeply enough to do so (as the result of
>> other implementations ).
>>
>> I understand this approach, it was ours at one time. There is a
>> significant difference, and your design is to some degree based
>> on a failure to fully consider this. I encourage you to not
>> assume any consensus-related detail is too small.
>
> I am not failing to consider this, and I don't consider this too
> small . But ensuring contextual transaction validity by "validate
> => valid with rules X,Y,Z" and then checking the active rules
> (softfork activation) on order validation, will give logically the
> same results as "validate with X,Y,Z => valid". This is not
> "hardwiring checkpoints" at all.
Storing the validation flags with each tx is exactly what libbitcoin
does (otherwise pre-validation would be infeasible). But that was not
the full point. You said on this in response previously:
>>> ...height-based compliance as meta data of validation seems to
>>> be
adequate and safe.
I read this as encoding the height at which a fork historically
activated. If you intend to track activation for each branch that will
not be "height-based" it will be history based.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY7KTHAAoJEDzYwH8LXOFOI+QH/RzX++1TNLC9DEMWioE7SmMj
yKOrP8WEkOnnrZdFKxVmwV9oZBekEvDABMnJmFiW5TMjsmPz7XwKAYzV0Y5L5oGU
fZYo3IOPyr0dA9TcpP15gNziR6pFUBq/QTYB6BcbUvvlkJv6xjgIdedgDMEyREWU
Hm/JU5g7gQUQd6MIDWbQ9FbYjtPuNSRQi851YfIn5mDivT4HuidaqQYMd9t5yS2Z
FuoQBI6L5GTJIqml1bTwJ0wsA7+ZseBEgMn1TT1ehy2v1FFJTojTpzIwG+m3eiXg
TxN3U/+fNAj+sKBb8Hq+nb7DvgjvKHyHuyRryBju7yq5d5rsb6meXcoiOtAznP8=
=fRXf
-----END PGP SIGNATURE-----

2023-06-07 19:59:35 CEST

- reply

📅 Original date posted:2017-04-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/08/2017 04:58 PM, Tomas wrote:
> You seem to ignore here the difference between base load and peak
> load. If Compact blocks/XThin with further optimizations can
> presync nearly 100% of the transactions, and nodes can do as much
> as possible when a transaction comes in, the time spent when a
> block comes in can be minimized and a lot more transactions can be
> handled with the same resources.
Maybe it's an issue of terminology. I have never used the terms
base/peak load. However I've been trying to get across, poorly I
suppose, that this is actually implemented in libbitcoin. I generally
refer to it as tx pre-validation. I've also tried to relate that you
are unnecessarily relating pre-validation to compactness. These are
unrelated ideas and better considered independently. One can get
nearly all of the benefit of pre-validation while still receiving
blocks (vs. compact blocks). The advantage of compactness is reduced
latency of the block announcement. The reason for pre-validation is
amortization of the validation and/or storage cost of a block.
> The reason for "splitting" is that for an incoming transaction the
> spent-state of the outputs being spent isn't particularly
> relevant as you seem to acknowledge. When the block comes in, the
> actual output data isn't relevant.
As I understand it you would split tx inputs and outputs and send them
independently, and that you intend this to be a P2P network
optimization - not a consensus rule change. So my comments are based
on those inferences. If we are talking about consensus changes this
conversation will end up in an entirely different place.
I don't agree with the input/output relevance statements above. When a
tx is announced the entire tx is relevant. It cannot be validated as
outputs only. If it cannot be validated it cannot be stored by the
node. Validating the outputs only would require the node store invalid
transactions.
I do accept that a double-spend detection is not an optimal criteria
by which to discard a tx. One also needs fee information. But without
double-spend knowledge the node has no rational way to defend itself
against an infinity of transactions that spend the minimal fee but
also have conflicting inputs (i.e. risking the fee only once). So tx
(pool) validation requires double-spend knowledge and at least a
summary from outputs.
> The *only* thing that needs to be checked when a block comes in is
> the order, and the spend-tree approach absolves the need to access
> outputs here.
Inputs that are already valid against prevouts remain valid assuming
consensus rules have not changed. But any input that spends a coinbase
must be validated for prevout height once there is a block context for
validation. Additionally the set of txs must be validated for total
size, sigops, and fee claim. So it's not true that conflict detection
alone is sufficient. Yet one can cache a tx's size, sigops, fee and
minimum height in a graph so that when a block appears that contains
that tx the input validation can be skipped.
Ignoring the (actual) requirement for the full tx on the pool
validation, the required "order" validation at (compact or other)
block arrival basically consists of traversing each tx, ensuring none
are confirmed in a block below the fork point; traversing each each of
its confirmed inputs, ensuring that none are spent in a block below
the fork point; and ensuring the block's set of transactions do not
contain missing inputs and do not double spend internal to the block.
This and the above-mentioned other required per-transaction block
validation data can be cached to an in-memory structure as a potential
optimization over navigating the store, and as you say, does not
therefore require the actual outputs (script/value). But the original
issue of needing full transactions for independent transaction
validation remains.
> As it also absolves the need for reorgs this greatly simplifies the
> design.
A reorg is conceptual and cannot be engineered out. What you are
referring to is a restructuring of stored information as a consequence
of a reorg. I don't see this as related to the above. The ability to
perform reorganization via a branch pointer swap is based not on the
order or factoring of validation but instead on the amount of
information stored. It requires more information to maintain multiple
branches.
Transactions have confirmation states, validation contexts and spender
heights for potentially each branch of an unbounded number of
branches. It is this requirement to maintain that state for each
branch that makes this design goal a very costly trade-off of space
and complexity for reorg speed. As I mentioned earlier, it's the
optimization for this scenario that I find questionable.
> I am not sure why you say that a one-step approach is more
> "test-friendly" as this seems to be unrelated.
Full separation of concerns allows all validation to be performed in
isolation from the store. As such validation state can be faked and
provided to a tx, block or chain, for the purpose of test. Validation
that interacts with a complex store during validation is harder to
fake and tests can be hard to verify.
It's not really the "one-step" approach that make this possible. In
fact that's not an accurate description. Validation and storage of txs
and blocks consists of four steps:
(1) context free
(2) contextual (chain-based)
(3) expensive (script eval)
(4) storage and notification
So we have:
tx.check()
tx.accept(state)
tx.connect(state)
chain.organize(tx)
block.check()
block.accept(state)
block.connect(state)
chain.organize(block)
...where "chain" is the store, from which "state" is derived. The
state for an unconfirmed tx is based on the presumption that the tx
would be mined in the next block. If that is not the case then its
pre-validation can become invalidated. So from my perspective, this
discussion is all about populating state. Anything that cannot be
placed into that pattern would complicate both the conceptual model
and testing. We've also seen that this isolation also has performance
advantages, as it facilitates optimizations that are otherwise
challenging.
>> Despite the site's explanation I cannot think of any reason to
>> ever validate two blocks at the same time. You would always
>> prioritize the block with the greatest PoW. Doing otherwise just
>> slows down the net validation in all but the pathological case
>> where a miner has produced an *invalid* block with *more* PoW
>> than another valid block which arrived at the node within the
>> same second. Rejecting a *valid* block with more PoW in favor of
>> one with *less* "processing" is a hard fork, so you probably
>> wouldn't want to do that either. But with compact block
>> validation times approaching 25ms it's hard to justify stopping
>> a block validation for any reason.
>
> I don't get what you are saying. Why pick the greatest PoW of two
> competing blocks?
Because choosing the lesser amount of work is non-consensus behavior.
Under the same circumstances (i.e. having seen the same set of blocks)
two nodes will disagree on whether there is one confirmation or no
confirmations for a given tx. This disagreement will persist (i.e. why
take the weaker block only to turn around and replace it with the
stronger block that arrives a few seconds or minutes later). It stands
to reason that if one rejects a stronger block under a race condition,
one would reorg out a stronger block when a weaker block arrives a
little after the stronger block. Does this "optimization" then apply
to chains of blocks too?
> If two blocks come in, an implementation is free to choose
> whichever block to build on.
Implementations are free to choose no blocks. That's not really the issu
e.
> Choosing so is not a "hardfork".
Accepting a block that all previous implementations would have
rejected under the same circumstance could be considered a hard fork,
but you may be right.
Yet the classification is not essential to my point. Nor is any
material change required to validate blocks in parallel. We can do it
using current design, but it doesn't make sense to do so.
> Parallel validation simply makes it easier to make an optimal
> choice, for if two blocks come in, the one that is validated
> fastest can be build upon without the risk of validationless
> mining.
This is not an optimization, since it should always be optimal to
validate blocks independently. Performing multiple together inherently
slows both of them. And the advantage to not validating *either* would
remain.
>> I am also interested in your previous comments about soft forks.
>> These are material considerations that Greg touched on but it
>> doesn't sound like you fully appreciate just yet. When a tx is
>> pre-validated the rules applied must be the same rules as those
>> of some future block. Yet a tx can be included in more than one
>> block (different branches). Across branches and even in one
>> branch, validation rules change, and can change back. The
>> changes are based on accumulated branch history. Pre-validation
>> can later become invalidated, and differently in different
>> branches. And maintaining proper context requires either storing
>> state that you are apparently not storing, or invalidating
>> optimizations. Based on your comments you do not seem to be
>> accounting for this in your storage assumptions or in your
>> results. A recent post by Greg highlights the complexity and
>> consensus criticality of these considerations.
>
> Frankly, I think this is a bit of an exaggeration. Soft forks are
> counted on a hand, and I don't think there are many - if any -
> transactions in the current chain that have changed compliance
> based on height.
Hope is a bug.
> This makes this a compliance issue and not a performance issue
You cannot have a useful performance measure without full compliance.
> and the solution I have explained, to add height-based compliance
> as meta data of validation seems to be adequate and safe.
If you intend this to be useful it has to help build the chain, not
just rely on hardwiring checkpoints once rule changes are presumed to
be buried deeply enough to do so (as the result of other implementations
).
I understand this approach, it was ours at one time. There is a
significant difference, and your design is to some degree based on a
failure to fully consider this. I encourage you to not assume any
consensus-related detail is too small.
>> The hash table store that I described can fully navigate the
>> block tree and transaction DAG, since the stored tx, parent and
>> point hashes are also natural keys and each link is navigable in
>> constant time. It is also lock-free, can concurrently write any
>> number of blocks during initial block download and supports
>> read/write concurrency. It has successfully indexed and stored
>> the entire blockchain from the P2P network in 16 minutes
>> (locally). It also stores both confirmed and unconfirmed
>> transactions in the same store, so there is nothing to write
>> when a block is confirmed except for the block header/hashes and
>> updates to spender heights for any output spent by the new
>> block's txs. It is similarly capable of storage in the block
>> table of weak chain blocks...
>
> I think I get the gist of your approach and it sounds very
> interesting and I will definitely dive in deeper.
It's worth noting that many of your stated objectives, including
modularity, developer platform, store isolation, consensus rule
isolation (including optional use of libbitcoinconsensus) are implemente
d.
It seems like you are doing some good work and it's not my intent to
discourage that. Libbitcoin is open source, I don't get paid and I'm
not selling anything. But if you are going down this path you should
be aware of it and may benefit from our successes as well as some of
the other stuff :). And hopefully we can get the benefit of your
insights as well.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY7DUUAAoJEDzYwH8LXOFOTB0H/jDtfnC6B9CtGrCTPtET+dDx
r0uQ0SXo40AUTplyKQ228rVkjmZyczTOtIP5uNvKpvlr9wW8TyYzFzNW4RNCNtdP
xZ9OjrfC24J2n+m1b9z9+CA85qAQxzLztBybDYzXCJG/dQ+y++7BR+rILGiRWUhs
lROeaEMqlDl0fy5J3dlpe0RGZJPSRqlxW7EBNHYc3IEDNL+j5m80/tWb6H5a3Mv8
7GTr6ulZef/04u/hRTXQ0ONy0MAIoi63HNHQuR0wF70ewGVmtFY4RHXEnNi+ucIG
w3QZuNTPtjqIS+ZbpFuqBop+L3CtId9+jxaBAao2tEieoIUl/faLjdTPP+r0n6A=
=5mz8
-----END PGP SIGNATURE-----

2023-06-07 19:59:33 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/06/2017 05:17 PM, Tomas wrote:
> Thanks, but I get the impression that the similarity is rather
> superficial.
My point was that "Using a storage engine without UTXO-index" has been
done, and may be a useful reference, not that implementation details
are the same.
> To address your points:
Below you addressed two points I made regarding the downside of the
original libbitcoin implementation. These were initial learnings that
informed future implementations (also without a UTXO index). These
were not comparisons to your implementation.
>> (1) higher than necessary storage space requirement due to
>> storing the indexing data required for correlate the spends, and
>
> Hmm. No. Spends are simply scanned in the spend-tree (full tree,
> prunable, fully 5.6gb), or caught by the spend-index (bit index,
> non-prunable, fully 180mb). Neither impose significant storage
> requirements.
>
>> 2) higher than necessary validation complexity and cost in terms
>> of computing the spent-ness (including spender height) of an
>> output.
>>
>> With the exception of de-linking (not deleted) in the case of
>> reorgs, the entire store is append only, implemented in a small
>> set of memory mapped file
>
> I guess this is the key difference. As the spend-tree stores the
> spend information in a tree structure, no reorgs are required, and
> the resulting code is actually much less complex.
The references to "higher than necessary storage" and "higher than
necessary validation cost" are explicitly relative statements,
comparing earlier and later libbitcoin implementations.
It is not clear to me how you are relating both the storage cost
("Hmm. No. ... Neither impose significant storage requirements.") and
code complexity ("... resulting code is actually much less complex")
of your tx ordering software to my statements. Do you think I am wrong
and libbitcoin v3 is not actually more space and code efficient than
libbitcoin v2?
But given that you have thrown some numbers and ideas out in a request
for feedback, I'm happy to give you some based on several years of
experience working closely with these issues.
First, I remain confused on your comments pertaining to UTXO growth
and network protocol. I followed your conversation with Greg and it
remains unclear to me. From what I understand you have isolated order
(double spend) from script validation. I think we all understand that
script validation requires inputs and outputs while double spend
detection requires correlation of inputs. What I do not understand is
your choice of optimization axis.
Detection of double spend is not useful in isolation. One must also
validate scripts, which requires outputs. I can see that there is an
opportunity to reject blocks (within the same branch) faster by
validating for double spends before validating script. But unconfirmed
transactions do not exist in a branch, and are therefore not truly
conflicting, until they are mined. And even after they are mined
conflicting txs remain potentially valid in other branches. So
rejecting txs due to conflict comes down to a denial of service
policy, which ultimately must be based on fee increment (e.g. RBF).
But fees are based on the amount of the output value that remains
unspent in the transaction. So this in turn requires the retrieval of
outputs.
And yet the remaining scenario of fast rejection of invalid blocks is
not a meaningful optimization. Optimizing for the case where a block
has valid and sufficient PoW and yet is invalid (for double spend) is
counterproductive. And even so, the txs within the invalid block may
be entirely valid independent of the block, so you are back to looking
up their outputs to obtain fees in the case of a double spend or to
validate script otherwise. In all cases you need to get the outputs.
> Bitcrust simply scans the tree. Although earlier designs used a
> skip-list, it turns out that accompanied by a spent-index lagging a
> few blocks behind, raw scanning is faster then anything even though
> it needs to scan ~5 blocks times ~4000 inputs before reaching the
> first spent-index, the actual scan is highly cache efficient and
> little more then a "REP SCASQ", reaching sub-microsecond per input
> on each core *including* the lookup in the spend index.
I realize that you see the implementation of the ordering validation
as interesting detail, but I find it hard to justify contemplating the
implementation in isolation from the output lookup requirement. And if
one must looking up both outputs and spends for each validation, it
makes more sense to co-locate that data.
Recovering in one step all data necessary to validate a tx has real
advantages over either interleaving queries and validation or
splitting input vs. output validation queries into two steps. It is a
significantly more test-friendly approach, has better performance
characteristics, and simplifies code. I cannot see any reason to
perform the data read for double spend validation in isolation of that
for script validation.
>> I don't follow this part, maybe you could clarify. A spends
>> index grows with the size of the spend set (forever) as it cannot
>> be pruned, which certainly exceeds the size of the UTXO set
>> (unless nothing is spent). The advantage is that you don't have
>> to keep rewriting the store when you use a spends set (because
>> the store can be append only).
>
> My point is, that the spend tree grows per *input* of a
> transaction instead of per *output* of a transaction, because this
> is what is scanned on order validation.
I think the conversation with Greg resolved my questions in this area.
What I find interesting is the reliance on Core's UTXO store to
implement script validation. This is not, "a storage engine without a
UTXO-index" as it has a dependency on Core's UTXO index.
On the other hand the initial libbitcoin implementation that I
described to you is *actually* a bitcoin store with no UTXO index. The
current implementation is as well, however it is implemented
differently and is much more efficient than the original. How it
compares to your design is not really the point and impossible to
measure until you have production code.
I can say however that your assumptions about the storage (and
performance) superiority of the design, or at least its
implementation, seem unfounded. If you are storing more index data
(5.6gb) than 32 bits per output, you are using more space than
production implementations. As for complexity, I don't think you'll
get any simpler than a loop to populate spend heights from a hash
table and a loop to test their integer values.
> The spend tree can be pruned because the spend index (~200mb)
> catches early spends.
>
> Disregarding the baseload script validation, the peak load order
> validation of bitcrust is more negatively effected by a transaction
> with many inputs than by a transaction of many outputs.
>
> I encourage you to check out the results at https://bitcrust.org
If by results you are referring to performance numbers, it's very hard
to draw any conclusions without a full benchmark. It's great that if
you are able to boost Core, but from my perspective the numbers aren't
especially compelling.
As for some of the site's comments, these again cause me to question
the optimization choices:
"Blocks can be verified in parallel..."
Despite the site's explanation I cannot think of any reason to ever
validate two blocks at the same time. You would always prioritize the
block with the greatest PoW. Doing otherwise just slows down the net
validation in all but the pathological case where a miner has produced
an *invalid* block with *more* PoW than another valid block which
arrived at the node within the same second. Rejecting a *valid* block
with more PoW in favor of one with *less* "processing" is a hard fork,
so you probably wouldn't want to do that either. But with compact
block validation times approaching 25ms it's hard to justify stopping
a block validation for any reason.
That's not to say parallel block validation difficult to do. If you
can validate one block's full set of inputs in parallel (which is not
novel) doing the same with additional blocks has trivial additional
complexity.
"The storage engine is optimized from ground up for
xthin/compact-block synchronization. This ensures that when the
majority of transactions are already synced, incoming blocks can be
verified at minimal resources using order-validation only."
There are two distinct considerations here. One is pre-validation of
txs and the other is compact announcements. Just to be clear, the
former does not require the latter. Libbitcoin for example fully
exploits the former, independent of compactness. With a low min fee
setting and a few peers it is typical for the node to have
pre-validated 100% of non-coinbase txs. Averages at 1 satoshi per byte
are about 99.9%, effectively amortizing all script validation cost. So
this optimization is neither novel nor limited to compactness (which
is about reducing latency).
I am also interested in your previous comments about soft forks. These
are material considerations that Greg touched on but it doesn't sound
like you fully appreciate just yet. When a tx is pre-validated the
rules applied must be the same rules as those of some future block.
Yet a tx can be included in more than one block (different branches).
Across branches and even in one branch, validation rules change, and
can change back. The changes are based on accumulated branch history.
Pre-validation can later become invalidated, and differently in
different branches. And maintaining proper context requires either
storing state that you are apparently not storing, or invalidating
optimizations. Based on your comments you do not seem to be accounting
for this in your storage assumptions or in your results. A recent post
by Greg highlights the complexity and consensus criticality of these
considerations.
By "order-validation only" I believe you are referring to a
determination of whether the txs organized into a candidate block
double spend internal to the block or in the ancestry. Assuming that
one recovers outputs at the same time (and presumably from the same
location) as spender height (which is required both for validating
spends of a coinbase and for determination of whether the spend is
above the fork point), this determination is straightforward. One
simply loops over the spender records and invalidates a tx that has a
spender height not above the fork point (while also validating
coinbase maturity using the same height). A loop over the set of
in-memory spend heights of each output a tx is certainly fast enough
to not be worthy of any further optimization. And as previously
discussed, the population of the spender heights is not even a
material additional cost over obtaining the (necessary) output scripts.
The hash table store that I described can fully navigate the block
tree and transaction DAG, since the stored tx, parent and point hashes
are also natural keys and each link is navigable in constant time. It
is also lock-free, can concurrently write any number of blocks during
initial block download and supports read/write concurrency. It has
successfully indexed and stored the entire blockchain from the P2P
network in 16 minutes (locally). It also stores both confirmed and
unconfirmed transactions in the same store, so there is nothing to
write when a block is confirmed except for the block header/hashes and
updates to spender heights for any output spent by the new block's
txs. It is similarly capable of storage in the block table of weak
chain blocks...
But one thing it does *not* do is maintain spender and fork state for
multiple branches. In other words it is optimized for one long chain,
not multiple long branches. Your approach has a limited (in terms of
double spend identification) optimization for reorganization (i.e. a
change to the strong chain identity). However, applying that
optimization to the full store and supportive of soft forks, as
opposed to just input ordering, is a much larger task than it appears
you have attempted. I know, as I created a design for that approach
and after some time scrapped it. The cost of performing the
reorganization in the above store is low enough and very long reorgs
infrequent enough, for the optimization to be counterproductive. It's
elegant in theory, but in practice it increases storage requirements,
impacts general performance and significantly increases complexity.
Bitcoin's data model pushes one away from a tree design in that it is
always pruning the tree. Having the tree is necessary, but it's not
something to optimize for.
e
> Regards, Tomas
>
> On Fri, Apr 7, 2017, at 01:38, Eric Voskuil wrote: On 04/06/2017
> 03:12 PM, Tomas via bitcoin-dev wrote:
>
> Hi Tomas,
>
>>>> I have been working on a bitcoin implementation that uses a
>>>> different approach to indexing for verifying the order of
>>>> transactions. Instead of using an index of unspent outputs,
>>>> double spends are verified by using a spend-tree where spends
>>>> are scanned against spent outputs instead of unspent
>>>> outputs.
>
> This is the approach that genjix used in libbitcoin version2. With
> the exception of de-linking (not deleted) in the case of reorgs,
> the entire store is append only, implemented in a small set of
> memory mapped files. The downsides to the approach are:
>
> (1) higher than necessary storage space requirement due to storing
> the indexing data required for correlate the spends, and
>
> (2) higher than necessary validation complexity and cost in terms
> of computing the spent-ness (including spender height) of an
> output.
>
> His implementation used a hash table, so performance-wise it did
> quite well and would theoretically outperform a tree, O(1) vs.
> O(log2(N)).
>
>>>> This allows for much better concurrency, as not only blocks,
>>>> but also individual inputs can be verified fully in
>>>> parallel.
>
> I was successful in parallelizing input validation (across the
> inputs of an unconfirmed tx and across the set of all inputs in a
> block) using the v2 store. However, it is not the case that the
> spends approach is necessary for concurrency.
>
> To resolve the above two problems the version3 store does not use
> a spends table/index. Nor does it store any table of UTXOs. Yet
> validation is highly parallelized. Instead of additional indexes
> it uses the tx hash table, augmented with 32 bits per output for
> spender height. So there is a O(1) cost of finding the tx and a
> O(N) cost of finding the spender height where N is the number of
> outputs in the tx. But because the number of outputs in a tx is
> bounded (by block size) this is constant time in the number of
> transactions.
>
> This works out much faster than the spends table, and without the
> storage cost or complexity disadvantages. It also scales with
> available hardware, as the memory mapped files become in-memory
> hash tables. For low memory machines we found it was important to
> implement an opaque UTXO cache to limit paging, but for higher end
> systems zero cache is optimal.
>
>>>> I am sharing this not only to ask for your feedback, but also
>>>> to call for a clear separation of protocol and
>>>> implementations: As this solution, reversing the costs of
>>>> outputs and inputs, seems to have excellent performance
>>>> characteristics (as shown in the test results), updates to
>>>> the protocol addressing the UTXO growth, might not be worth
>>>> considering *protocol improvements* and it might be best to
>>>> address these concerns as implementation details.
>
> I don't follow this part, maybe you could clarify. A spends index
> grows with the size of the spend set (forever) as it cannot be
> pruned, which certainly exceeds the size of the UTXO set (unless
> nothing is spent). The advantage is that you don't have to keep
> rewriting the store when you use a spends set (because the store
> can be append only).
>
> Feel free to message me if you'd like to discuss in more detail, or
> to continue on the libbitcoin mailing list (copied).
>
> e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY6WY4AAoJEDzYwH8LXOFO+wwH/1uE/+P1+KLJWTkcttVWsO//
QAlikqg0HLFDtkd5jaYsBtx6op/Uz2o53ohZwVJt71ITCjQQI+yYK2RjBX92xIhd
K0rE901Np4PfMFbDA60LB0c/65aPlkUCr3f2PYIlizJs4Qq5Kn2sIpC5v9T3B7H4
MPq5UJwoPP+m3RZ9TSsVyee3ejHYXM7y2VNNnnWD3edIioA3cLh+y6sczpco2Hpa
P+GSDnv2cwV6FA22Is1Z15tpfLyQnPrrGJ9QEJJ15vnhCTxZe0j1PQ4y+OOZh5Iq
mqBkGRNPeUnPAPDM+/qvhr2kUyxFbaJNtwg5HDGHWFOq5B/YeKxVk8Qjnk+9epA=
=XRKl
-----END PGP SIGNATURE-----

2023-06-07 19:59:33 CEST

- reply

📅 Original date posted:2017-04-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/06/2017 03:12 PM, Tomas via bitcoin-dev wrote:
Hi Tomas,
> I have been working on a bitcoin implementation that uses a
> different approach to indexing for verifying the order of
> transactions. Instead of using an index of unspent outputs, double
> spends are verified by using a spend-tree where spends are scanned
> against spent outputs instead of unspent outputs.
This is the approach that genjix used in libbitcoin version2. With the
exception of de-linking (not deleted) in the case of reorgs, the
entire store is append only, implemented in a small set of memory
mapped files. The downsides to the approach are:
(1) higher than necessary storage space requirement due to storing the
indexing data required for correlate the spends, and
(2) higher than necessary validation complexity and cost in terms of
computing the spent-ness (including spender height) of an output.
His implementation used a hash table, so performance-wise it did quite
well and would theoretically outperform a tree, O(1) vs. O(log2(N)).
> This allows for much better concurrency, as not only blocks, but
> also individual inputs can be verified fully in parallel.
I was successful in parallelizing input validation (across the inputs
of an unconfirmed tx and across the set of all inputs in a block)
using the v2 store. However, it is not the case that the spends
approach is necessary for concurrency.
To resolve the above two problems the version3 store does not use a
spends table/index. Nor does it store any table of UTXOs. Yet
validation is highly parallelized. Instead of additional indexes it
uses the tx hash table, augmented with 32 bits per output for spender
height. So there is a O(1) cost of finding the tx and a O(N) cost of
finding the spender height where N is the number of outputs in the tx.
But because the number of outputs in a tx is bounded (by block size)
this is constant time in the number of transactions.
This works out much faster than the spends table, and without the
storage cost or complexity disadvantages. It also scales with
available hardware, as the memory mapped files become in-memory hash
tables. For low memory machines we found it was important to implement
an opaque UTXO cache to limit paging, but for higher end systems zero
cache is optimal.
> I am sharing this not only to ask for your feedback, but also to
> call for a clear separation of protocol and implementations: As
> this solution, reversing the costs of outputs and inputs, seems to
> have excellent performance characteristics (as shown in the test
> results), updates to the protocol addressing the UTXO growth, might
> not be worth considering *protocol improvements* and it might be
> best to address these concerns as implementation details.
I don't follow this part, maybe you could clarify. A spends index
grows with the size of the spend set (forever) as it cannot be pruned,
which certainly exceeds the size of the UTXO set (unless nothing is
spent). The advantage is that you don't have to keep rewriting the
store when you use a spends set (because the store can be append only).
Feel free to message me if you'd like to discuss in more detail, or to
continue on the libbitcoin mailing list (copied).
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY5tFpAAoJEDzYwH8LXOFOcMgH/2mw5iOvUYNwvZ2z0KKTSUOA
Pd8d5mKoWvd94QxhQ+RyTbkEkMhHl75+zcBgRsfUTtZlBIe/Z0+OgVIN6ibEw+WD
w7k3HqgQi9gLgydEelxTAX+z3dJ24n4kCCdKAmZbBuK+Yr/7AViugbEqYemKepku
pRWZZS74MUvrYesc0xPn4Ao3DTzMjjY0K2mkuqV8jlwdfZjlAQX9pTx+iSCuMhkd
HJ8w7s8QnjVnUeOlLe29mZwaFJPyOTLJMqgDE6s2sXacAy5QQbVCatygvDQ8A/wC
ktBnKPFb2lGX3bGKu/KwABegBy/hyec+NP0wFR+0MVivCwTK1+SjeHu5MNOSVlM=
=tfVj
-----END PGP SIGNATURE-----

2023-06-07 19:58:42 CEST

- reply

📅 Original date posted:2017-04-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/31/2017 11:18 PM, Jared Lee Richardson wrote:
>> If a typical personal computer cannot run a node there is no
>> security.
>
> If you can't describe an attack that is made possible when typical
> personal computers can't run nodes, this kind of logic has no place
> in this discussion.
"Governments are good at cutting off the heads of a centrally
controlled networks..."
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY31m0AAoJEDzYwH8LXOFOayIH/0DcWukHZUVTV8952mkWnqjS
RCM8StQOuuTQ/2elvKoZa/nEv1PvpOQEO/AxJDEdIKOqjdXoc/QdZT/Qj834yyFi
mmNLm3x8voO7rTFEVtBrXQ4VYO7Zj5gVy6nRyMrhSGtzg4XqYiyGVoijiumfXOvq
ejLwyWJEf8klBwegIPkX4XX6UYjNyBt+E32Je7NxUbi54EPDRszWpEGGKfJrWiCQ
JO2jqB3O2RbMd0J1onBt2AGsjeQSE3HO0EBQSkdGQZ7PVSdE3I49uT2aAaScnPOt
ymbNz4QtlUWWpUgEI6VSjxHCGjX4+Vrn3HLRwjLe4nS2EX3mOVNY8MHMvbCeAuY=
=tD9k
-----END PGP SIGNATURE-----

2023-06-07 19:57:03 CEST

- reply

📅 Original date posted:2017-03-05
📝 Original message:There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large consensus is more secure in that it is more resistant to change (forks) than a system with a small consensus.
The fact that mining is highly centralized makes it relatively easy to enforce a fork via miner collaboration, and hard to do so without it.
So clearly the other option, as being discussed here, is to enforce a fork via the economy. Given the highly centralized nature of the economy, described below as "economic hubs", it is also relatively easy as well.
Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has been done) and negotiate a change to any rule, Bitcoin is a purely political money.
If "we" can do this, so can "they".
e
> On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I also think that the UASF is a good idea. Hashrate follows coin price. If the UASF has the higher coin price, the other chain will be annihilated. If the UASF has a lower coin price, the user activated chain can still exist (though their coins can be trivially stolen on the majority chain).
>
> The success of the UASF depends entirely on the price. And actually, the price is easy to manipulate. If you, as an economically active full node, refuse to acknowledge the old chain and demand that incoming coins arrive over the UASF chain. In doing so, you drive down the utility of the old chain and drive up the utility of the new chain. This ultimately impacts the price.
>
> I think it would be pretty easy to get high confidence of the success of a UASF. Basically you need all the major economic hubs to agree to upgrade and then exclusively accept UASF coins. I don't have a comprehensive list, but if we could sign on 75% of the major exchanges and payment processors, and get 75% of the wallets to upgrade, then the UASF would be very likely to successfully obliterate the old rules, as miners would be unable to sell their coins or pay their bills by stubbornly sticking to the old chain. It's less risky than a hard fork by far, because there is zero risk of coin split if the UASF has majority hashrate, which will follow majority economic value.
>
> A serious proposal I think would get all the code ready and merged, but without setting a flag day. Then we would get signatures from the major institutions promising to use the software and saying that they are ready for a flag day. After that, you release a patch with a flag day 12 months in the future. People can upgrade immediately, and have a full year to transition.
>
> That gives tons of time for people to upgrade, and tons of confidence that the UASF will end up as the majority chain.
>
> If we cannot get enough major exchanges, payment processors, and other economic hubs to upgrade, the flag day should remain upset, as the risk of coin split will be non-zero.
>
> I would suggest that a carefully executed UASF is much riskier than a soft fork, but far, far less risky than a hard fork.
>
>
> _______________________________________________
> 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/20170305/2631a5b3/attachment.html>

2023-06-07 19:55:10 CEST

- reply

📅 Original date posted:2017-01-05
📝 Original message:On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
> On 1/3/17, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> There are plenty, more sane options. If you can't run your own full-node
>> as a merchant (trivial), maybe co-use a wallet-service with centralized
>> verification (maybe use two of them), I guess Copay would be one of
>> those wallets (as an example). Use them in watch-only mode.
>
> The best way is to connect to the mempool of each miner and check to
> see if they have your txid in their mempool.
>
> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> https://bw.com/api/is_in_mempool?txid=334847bb...
> https://bitfury.com/api/is_in_mempool?txid=334847bb...
> https://btcc.com/api/is_in_mempool?txid=334847bb...
>
> If each of these services return "True", and you know those services
> so not engage in RBF, then you can assume with great confidence that
> your transaction will be in the next block, or in a block very soon.
> If any one of those services return "False", then you must assume that
> it is possible that there is a double spend floating around, and that
> you should wait to see if that tx gets confirmed. The problem is that
> not every pool runs such a service to check the contents of their
> mempool...
>
> This is an example of mining centralization increasing the security of
> zero confirm.
A world connected up to a few web services to determine payment validity
is an example of a bitcoin security catastrophe.
e
-------------- 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/20170104/4df3d1a9/attachment.sig>

2023-06-07 19:55:06 CEST

- reply

📅 Original date posted:2017-01-04
📝 Original message:Credit card reversals involve an escrow agent with control over the entire network and with a strong interest in preserving the network. A better analogy would be blind acceptance of any slip of paper under the assumption that it is sufficient currency. It may or may not be so, but you are on your own in either case.
e
> On Jan 3, 2017, at 4:36 PM, Aaron Voisine via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Knowing that a transaction is property formatted and that it has been broadcast to the gossip network is useful in many situations. You're only thinking about whether you can know a transaction is valid and/or settled. This is not the only possible useful information in actual real world use. Any situation where credit card transactions are accepted today for instance, it is useful to know that a transaction has been initiated, even though it can be reversed at any time up to 60 days later.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet
>
>> On Tue, Jan 3, 2017 at 4:10 PM, <bfd at cock.lu> wrote:
>> Unfortunately a non validating SPV wallet has absolutely no idea if
>> the information about an unconfirmed transaction they are seeing is
>> anything but properly formatted. They are connecting to an easily
>> manipulated, sybil attacked, and untrusted network and then asking
>> them for financial information. Seeing an unconfirmed transaction in a
>> wallet that's not also fully validating is at best meaningless.
>>
>>
>>> On 2017-01-03 15:46, Aaron Voisine wrote:
>>> If the sender doesn't control the receiver's network connection, then
>>> the information the receiver gains by watching the mempool is if the
>>> transaction has propagated across the bitcoin network. This is useful
>>> to know in all kinds of situations.
>>>
>>> Aaron Voisine
>>> co-founder and CEO
>>> breadwallet [2]
>>>
>>> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx at awsomnet.org> wrote:
>>>
>>>> Mempool transactions have their place, but "unconfirmed" and "SPV"
>>>> don't belong together. Only a full node can tell if a transaction
>>>> may get confirmed, or is nonsense. Unfortunately all the light /
>>>> SPV wallets I know of show mempool transactions, which makes it hard
>>>> to go back... (e.g. "why doesn't your software show 0-conf! your
>>>> wallet is broken!", somewhat akin to people complaining about RBF)
>>>>
>>>> So, this is easy, just don't worry about mempool filtering. Why are
>>>> light clients looking at the mempool anyway? Maybe if there were
>>>> some way to provide SPV proofs of all inputs, but that's a bit of a
>>>> mess for full nodes to do.
>>>>
>>>> Without mempool filtering, I think the committed bloom filters would
>>>> be a great improvement over the current bloom filter setup,
>>>> especially for lightning network use cases (with lightning, not
>>>> finding out about a transaction can make you lose money). I want to
>>>> work on it and may be able to at some point as it's somewhat related
>>>> to lightning.
>>>>
>>>> Also, if you're running a light client, and storing the filters the
>>>> way you store block headers, there's really no reason to go all the
>>>> way back to height 0. You can start grabbing headers at some point
>>>> a while ago, before your set of keys was generated. I think it'd be
>>>> very worth it even with GB-scale disk usage.
>>>>
>>>> -Tadge
>>>>
>>>> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> Unconfirmed transactions are incredibly important for real world
>>>> use. Merchants for instance are willing to accept credit card
>>>> payments of thousands of dollars and ship the goods despite the fact
>>>> that the transaction can be reversed up to 60 days later. There is a
>>>> very large cost to losing the ability to have instant transactions
>>>> in many or even most situations. This cost is typically well above
>>>> the fraud risk.
>>>>
>>>> It's important to recognize that bitcoin serves a wide variety of
>>>> use cases with different profiles for time sensitivity and fraud
>>>> risk.
>>>>
>>>> Aaron
>>>>
>>>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> The concept combined with the weak blocks system where miners commit
>>>>
>>>> to potential transaction inclusion with fractional difficulty blocks
>>>>
>>>> is possible. I'm not personally convinced that unconfirmed
>>>> transaction
>>>>
>>>> display in a wallet is worth the privacy trade-off. The user has
>>>> very
>>>>
>>>> little to gain from this knowledge until the txn is in a block.
>>>>
>>>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>>>
>>>>> Hi
>>>>
>>>>>> We introduce several concepts that rework the lightweight Bitcoin
>>>>
>>>>>> client model in a manner which is secure, efficient and privacy
>>>>
>>>>>> compatible.
>>>>
>>>>>>
>>>>
>>>>>> The BFD can be used verbatim in replacement of BIP37, where the
>>>> filter
>>>>
>>>>>> can be cached between clients without needing to be recomputed.
>>>> It can
>>>>
>>>>>> also be used by normal pruned nodes to do re-scans locally of
>>>> their
>>>>
>>>>>> wallet without needing to have the block data available to scan,
>>>> or
>>>>
>>>>>> without reading the entire block chain from disk.
>>>>
>>>>> I started exploring the potential of BFD after this specification.
>>>>
>>>>>
>>>>
>>>>> What would be the preferred/recommended way to handle
>>>> 0-conf/mempool
>>>>
>>>>> filtering – if & once BDF would have been deployed (any type,
>>>>
>>>>> semi-trusted oracles or protocol-level/softfork)?
>>>>
>>>>>
>>>>
>>>>> From the user-experience perspective, this is probably pretty
>>>> important
>>>>
>>>>> (otherwise the experience will be that incoming funds can take
>>>> serval
>>>>
>>>>> minutes to hours until they appear).
>>>>
>>>>> Using BIP37 bloom filters just for mempool filtering would
>>>> obviously
>>>>
>>>>> result in the same unwanted privacy-setup.
>>>>
>>>>>
>>>>
>>>>> </jonas>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> _______________________________________________
>>>>
>>>>> bitcoin-dev mailing list
>>>>
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>>>
>>>> _______________________________________________
>>>>
>>>> bitcoin-dev mailing list
>>>>
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> [2] http://breadwallet.com
>
> _______________________________________________
> 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/20170103/0950eb13/attachment-0001.html>

2023-06-07 19:54:21 CEST

- reply

📅 Original date posted:2016-11-16
📝 Original message:On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote:
> On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> BIP30 actually was given similar treatment after a reasonable amount of time
>> had passed.
>> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
>
> This is not really the same. BIP30 is not validated after BIP34 is
> active because blocks complying with BIP34 will always necessarily
> comply with BIP30 (ie coinbases cannot be duplicated after they
> include the block height).
This is a misinterpretation of BIP30. Duplicate transaction hashes can
and will happen and are perfectly valid in Bitcoin. BIP34 does not
prevent this.
e
-------------- 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/20161116/b8912894/attachment.sig>

2023-06-07 19:54:18 CEST

- reply

📅 Original date posted:2016-11-16
📝 Original message:This sort of statement represents one consequence of the aforementioned bad precedent.
Are checkpoints good now? Are hard forks okay now?
What is the maximum depth of a reorg allowed by this non-machine consensus?
Shouldn't we just define a max depth so that all cruft deeper than that can just be discarded on a regular basis?
Why are there activation heights defined by this hard fork if it's not possible to reorg back to them?
The "BIP" is neither a Proposal (it's been decided, just documenting for posterity), nor an Improvement (there is no actual benefit, just some tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has been CoreCoin).
e
> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>
> Since "buried deployments" are specifically in reference to historical consensus changes, I think the question is more one of human consensus than machine consensus. Is there any disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66 activated at block 363725? Somehow I doubt it.
>
> It seems to me that this change is merely cementing into place a few attributes of the blockchain's history that are not in dispute.
>
> - Jameson
>
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Actually this does nothing to provide justification for this consensus rule change. It is just an attempt to deflect criticism from the fact that it is such a change.
>>
>> e
>>
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on top of
>> > it. The occurrence of such a reorg that would cause the activating
>> > block to be disconnected would raise fundamental concerns about the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> NACK
>> >>
>> >> Horrible precedent (hardcoding rule changes based on the assumption that
>> >> large forks indicate a catastrophic failure), extremely poor process
>> >> (already shipped, now the discussion), and not even a material performance
>> >> optimization (the checks are avoidable once activated until a sufficiently
>> >> deep reorg deactivates them).
>> >>
>> >> e
>> >>
>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Recently Bitcoin Core merged a simplification to the consensus rules
>> >> surrounding deployment of BIPs 34, 66, and 65
>> >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
>> >> minor one, I thought it was worth documenting the rationale in a BIP for
>> >> posterity.
>> >>
>> >> Here's the abstract:
>> >>
>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
>> >> signaling in block version numbers. Now that the chain has long since passed
>> >> the blocks at which those consensus rules have triggered, we can (as a
>> >> simplification and optimization) replace the trigger mechanism by caching
>> >> the block heights at which those consensus rules became enforced.
>> >>
>> >> The full draft can be found here:
>> >>
>> >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.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
>> >>
>> _______________________________________________
>> 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/20161116/9709e645/attachment-0001.html>

2023-06-07 19:54:17 CEST

- reply

📅 Original date posted:2016-11-15
📝 Original message:Actually this does nothing to provide justification for this consensus rule change. It is just an attempt to deflect criticism from the fact that it is such a change.
e
> On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com> wrote:
>
> I think this is already covered in the BIP text:-
>
> "As of November 2016, the most recent of these changes (BIP 65,
> enforced since December 2015) has nearly 50,000 blocks built on top of
> it. The occurrence of such a reorg that would cause the activating
> block to be disconnected would raise fundamental concerns about the
> security assumptions of Bitcoin, a far bigger issue than any
> non-backwards compatible change.
>
> So while this proposal could theoretically result in a consensus
> split, it is extremely unlikely, and in particular any such
> circumstances would be sufficiently damaging to the Bitcoin network to
> dwarf any concerns about the effects of this proposed change."
>
>
> On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> NACK
>>
>> Horrible precedent (hardcoding rule changes based on the assumption that
>> large forks indicate a catastrophic failure), extremely poor process
>> (already shipped, now the discussion), and not even a material performance
>> optimization (the checks are avoidable once activated until a sufficiently
>> deep reorg deactivates them).
>>
>> e
>>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi,
>>
>> Recently Bitcoin Core merged a simplification to the consensus rules
>> surrounding deployment of BIPs 34, 66, and 65
>> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
>> minor one, I thought it was worth documenting the rationale in a BIP for
>> posterity.
>>
>> Here's the abstract:
>>
>> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
>> signaling in block version numbers. Now that the chain has long since passed
>> the blocks at which those consensus rules have triggered, we can (as a
>> simplification and optimization) replace the trigger mechanism by caching
>> the block heights at which those consensus rules became enforced.
>>
>> The full draft can be found here:
>>
>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.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 19:54:16 CEST

- reply

📅 Original date posted:2016-11-14
📝 Original message:NACK
Horrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a sufficiently deep reorg deactivates them).
e
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a minor one, I thought it was worth documenting the rationale in a BIP for posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification and optimization) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.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/20161114/03f1190e/attachment.html>

2023-06-07 19:54:01 CEST

- reply

📅 Original date posted:2016-10-16
📝 Original message:If somebody is not "running their own validation code" then they aren't actually using Bitcoin, so their ease in transition is irrelevant. For all they know they are accepting random numbers.
e
> On Oct 16, 2016, at 9:35 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The fallow period sounds waaaay to short. I suggest 2 months at minimum
>> since anyone that wants to be safe needs to upgrade.
>
> I asked a lot of businesses and individuals how long it would take them to upgrade to a new release over the last year or two.
>
> Nobody said it would take them more than two weeks.
>
> If somebody is running their own validation code... then we should assume they're sophisticated enough to figure out how to mitigate any risks associated with segwit activation on their own.
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> 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/20161016/57ac3ff7/attachment-0001.html>

2023-06-07 19:53:17 CEST

- reply

📅 Original date posted:2016-09-09
📝 Original message:ACK
libbitcoin defines the message and includes the public key but only for completeness and reference purposes. It has never been used in the node.
e
> On Sep 9, 2016, at 5:42 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
>
> It has been removed completely in Bitcoin Core after being disabled for a while.
>
> While the system had some potential uses, there were a number of
> problems with it.
>
> The alert system was a frequent source of misunderstanding about the
> security model and 'effective governance', for example a years ago a
> BitcoinJ developer wanted it to be used to control fee levels on the
> network and few months back one of Bloq's staff was pushing for a
> scheme where "the developers" would use it to remotely change the
> difficulty-- apparently with no idea how abhorrent others would find
> it.
>
> The system also had a problem of not being scalable to different
> software vendors-- it didn't really make sense that core would have
> that facility but armory had to do something different (nor would it
> really make sense to constantly have to maintain some list of keys in
> the node software).
>
> It also had the problem of being unaccountable. No one can tell which
> of the key holders created a message. This creates a risk of misuse
> with a false origin to attack someone's reputation.
>
> Finally, there is good reason to believe that the key has been
> compromised-- It was provided to MTGox by a developer and MTGox's
> systems' were compromised and later their CEO's equipment taken by the
> Japanese police.
>
> In any case, it's gone now in Core and most other current software--
> and I think it's time to fully deactivate it.
>
> I've spent some time going around the internet looking for all
> software that contains this key (which included a few altcoins) and
> asked them to remove it. I will continue to do that.
>
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
>
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
>
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
>
> Cheers,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:51:45 CEST

- reply

📅 Original date posted:2016-06-30
📝 Original message:> On Jun 30, 2016, at 9:06 PM, Peter Todd <pete at petertodd.org> wrote:
>
> On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote:
>>> To be clear, are you against Bitcoin Core's tor support?
>>>
>>> Because node-to-node connections over tor are encrypted, and make use of onion
>>> addresses, which are self-authenticated in the exact same way as BIP151 proposes.
>>
>> BIP151 is self-admittedly insufficient to protect against a MITM attack. It proposes node identity to close this hole (future BIP required). The yet-to-be-specified requirement for node identity is the basis of my primary concern. This is not self-authentication.
>>
>>> And we're shipping that in production as of 0.12.0, and by default Tor onion support is enabled and will be automatically setup if you have a recent version of Tor installed.
>>>
>>> Does that "create pressure to expand node identity"?
>>
>> The orthogonal question of whether Tor is safe for use with the Bitcoin P2P protocol is a matter of existing research.
>
> I don't think you answered my question.
>
> Again, we _already have_ the equivalent of BIP151 functionality in Bitcoin
> Core, shipping in production, but implemented with a Tor dependency.
>
> BIP151 removes that dependency on Tor, enabling encrypted connections
> regardless of whether or not you have Tor installed.
>
> So any arguments against BIP151 being implemented, are equally arguments
> against our existing Tor onion support. Are you against that support? Because
> if you aren't, you can't have any objections to BIP151 being implemented
Neither Tor nor Bitcoin Core are part of this BIP (or its proposed dependency on node identity).
But again, given that node identity is not part of the Bitcoin Core Tor integration, my objection to the presumption of node identity by BIP151 is unrelated to Bitcoin Core's Tor integration.
e

2023-06-07 19:51:44 CEST

- reply

📅 Original date posted:2016-06-30
📝 Original message:> On Jun 30, 2016, at 6:52 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote:
>>
>>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev at jonasschnelli.ch> wrote:
>>>
>>>>>> The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker.
>>>>>
>>>>> BIP151 would increase the risks for MITM attackers.
>>>>> What are the benefits for Mallory of he can't be sure Alice and Bob may
>>>>> know that he is intercepting the channel?
>>>>
>>>> It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.
>>>
>>> If Mallory has substituted the ephemeral keys in both directions, at the
>>> point where Alice and Bob will do an authentication, they can be sure
>>> Mallory is listening.
>>
>> I understand the mechanics of a tunnel between trusting parties that have a secure side channel. But this assumes that no other peer can connect to these two nodes. How then do they maintain the chain?
>>
>> The "middle" in this sense does not have to be the wire directly between these two peers. It can be between either of them and any anonymous connection they (must) allow.
>>
>> Of course this creates pressure to expand their tunnel. Hence the problem of expanding node identity in an effort to preserve privacy. The protection will remain weak until the entire network is "secure". At that point it would necessarily be a private network.
>>
>> As Pieter rightly observes, there are and always will be tunnels between trusting nodes. Often these are groups of nodes that are in collaboration, so logically they are one node from a system security standpoint. But if people become generally reliant on good node registration, it will become the registrar who controls access to the network. So my concern rests I this proposal becoming widely adopted.
>
> To be clear, are you against Bitcoin Core's tor support?
>
> Because node-to-node connections over tor are encrypted, and make use of onion
> addresses, which are self-authenticated in the exact same way as BIP151 proposes.
BIP151 is self-admittedly insufficient to protect against a MITM attack. It proposes node identity to close this hole (future BIP required). The yet-to-be-specified requirement for node identity is the basis of my primary concern. This is not self-authentication.
> And we're shipping that in production as of 0.12.0, and by default Tor onion support is enabled and will be automatically setup if you have a recent version of Tor installed.
>
> Does that "create pressure to expand node identity"?
The orthogonal question of whether Tor is safe for use with the Bitcoin P2P protocol is a matter of existing research.
e

2023-06-07 19:51:43 CEST

- reply

📅 Original date posted:2016-06-30
📝 Original message:> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli <dev at jonasschnelli.ch> wrote:
>
>
>> Yes, this is exactly what I meant. The complexity of the proposed construction is comparable to that of Bitcoin itself. This is not itself prohibitive, but it is clearly worthy of consideration.
>>
>> A question we should ask is whether decentralized anonymous credentials is applicable to the authentication problem posed by BIP151. I propose that it is not.
>>
>> The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker.
>
> BIP151 would increase the risks for MITM attackers.
> What are the benefits for Mallory of he can't be sure Alice and Bob may
> know that he is intercepting the channel?
It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.
> MITM is possible today, it would still be possible (though under higher
> costs) with BIP151.
>
> With BIP151 we would have the basic tool-set to effectively reduce the
> risks of being MITMled.
>
> IMO we should focus on the risks and benefits of BIP151 and not drag
> this discussion into the realm of authentication. This can and should be
> done once we have proposals for authentication (and I'm sure this will
> be a heated debate).
>
> The only valid risk I have on my list from you, Eric, is the false sense
> of security.
>
> My countermeasure for that would be...
> - deploy BIP151 together with the simplest form of authentication
> (know_hosts / authorized_keys file, no TOFU only editable "by hand")
> - make it more clear (in the BIP151 MOTIVATION text) that it won't solve
> the privacy/MITM problem without additional authentication.
>
> Or could you elaborate again – without stepping into the realm of
> authentication/MITM (which is not part of the BIP or possible already
> today) – why BIP151 would make things worse?
>
> </jonas>
>

2023-06-07 19:51:42 CEST

- reply

📅 Original date posted:2016-06-30
📝 Original message:Hi Alfie,
Yes, this is exactly what I meant. The complexity of the proposed construction is comparable to that of Bitcoin itself. This is not itself prohibitive, but it is clearly worthy of consideration.
A question we should ask is whether decentralized anonymous credentials is applicable to the authentication problem posed by BIP151. I propose that it is not.
The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker.
Authentication of an anonymous peer cannot achieve this objective, since the peer may be anyone and an attack on privacy can be undetectable. The identity of a peer must be known to the relying peer, either directly or transitively.
DAC is applicable in cases where identity is never required. The prime example in the paper is that of first-come-first-served name registration. No identity is required in that scenario, just proof that a party in question is the original registrant. All participants are presumed to be "good".
I believe that a distributed anonymous system is fundamentally at odds with isolation of "good" vs. "bad" participants who comply with protocol rules (DoS considerations aside), and that any attempt to resolve this conflict will result in the system no longer allowing anonymous participation.
I may be mistaken, but I haven't found a way out of this realization.
e
> On Jun 29, 2016, at 1:17 PM, Alfie John <alfie at alfie.wtf> wrote:
>
> On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote:
>>> then we should definitively use a form of end-to-end encryption between
>>> nodes. Built into the network layer.
>>
>> Widespread application of this model is potentially problematic. It is a
>> non-trivial problem to design a distributed system that requires authentication
>> but without identity and without central control. In fact this may be more
>> challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this
>> problem.
>
> Maybe the following paper can feed into this discussion:
>
> "Decentralized Anonymous Credentials" by Christina Garman, Matthew Green, Ian Miers
> https://eprint.iacr.org/2013/622.pdf
>
> Alfie
>
> --
> Alfie John
> https://www.alfie.wtf

2023-06-07 19:51:41 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:On Jun 28, 2016, at 10:06 PM, Jonas Schnelli <dev at jonasschnelli.ch> wrote:
>>> In my opinion, the question should be "why would you _not_ encrypt".
>>
>> 1) creation of a false sense of security
>
> False sense of security is mostly a communication issue.
> BIP151 does focus on encryption (not trust).
>
> Are users aware of the fact that ISP/WiFi-Providers can track their
> bitcoin spending (if they use SPV+BF) and link it with other internet
> traffic or sell the data to anyone who is interested to do correlation?
The relevant question would be to ask whether encryption would prevent an ISP from doing so (which it would not). This is a good example of false sense of security.
> Are node operators aware of the possibilities that ISPs/Data-Centers,
> etc. can hold back peers, etc.?
>
> If there is a false sense of security/anonymity, then we are already
> deep into this territory.
> BIP151 was designed as a puzzle-pice towards better security and better
> censorship resistance. You shouldn't project all sorts of "false sense
> of security" into BIP151. Is a stepping stone towards greater security.
FWIW I was just answering your question comprehensively. Relationship to BIP151 is incidental (though apparently applicable).
Keep in mind my specific concern is not with the design of BIP151, it is with the implication of its dependency on an unspecified authentication proposal.
>> 2) as a tradeoff against anonymity
>
> Can you point out the tradeoffs?
> BIP151 does not introduce fingerprinting possibilities.
The security tradeoff would arise from widespread deployment of authentication - which is necessary to make encryption useful against envisioned MITM attacks. See my previous discussion of trust zones below.
>> 3) benefit does not justify cost
>
> Can you elaborate the costs?
> [Extremely simplified]: we need 300 lines of code from openssh
> (ChaCha20-Poly1305 at openssl) and some ECDH magic (already in
> Bitcoin-Cores codebase) together with two or three (maybe payed)
> cryptoanalysis once the implementation is done.
Simply put, any code that is unnecessary does not justify its cost.
>>> There are plenty of other options to solve this problem. stunnel,
>>> Bernsteins CurveCP, VPN, etc. which are available since years.
>>> But the reality has shown that most bitcoin traffic is still unencrypted.
>>
>> The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.
>>
>> As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).
>>
>> Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.
>
> Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO
> it does not cover "trust" (It just encrypt all traffic).
TOFU (trust on first use) was a reference to what was discussed on IRC as a potential solution to the (deferred) authentication problem. I didn't mean to imply that it was part of BIP151.
> Imaging Bip151 together with a simple form of preshared EC key
> authentication (nonce signing or similar). You could drastically
> increase the security/censor-resistance-properties between nodes where
> owners have preshared identity keys (with nodes I also mean SPV/wallet
> nodes).
This is a restatement of what I have accepted as a premise - that authentication, and as such, key distribution, will be a necessary part of making any encryption scheme effective. "Preshared" implies a secure side channel for key distribution.
> And I guess there are plenty of awesome identity management system ideas
> tied or not tied to the Bitcoin blockchain out there.
> This is also a reason to not cover trust/authentication/identity in BIP151.
> It is possible to have multiple authentication schemes.
Whether or not there are multiple schemes is not relevant to the point I have raised. The issue is that authentication is necessary.
>> In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).
>
> Yes. I think nobody have started implementing BIP151. It's a draft BIP
> and I think it's still okay and great that we have this discussion.
>
> BIP151 hopefully has started some brainwork in how encryption and
> authentication could work in Bitcoin and I'm happy to deprecate BIP151 if we have found a better solution or if we come to a point where we agree that BIP151 does make the network security worse.
We should contemplate what the distributed permissionless network of anonymous peers looks like once every node authenticates every one of its peers using one or more key distribution side channels.
>>> Example: IIRC non of the available SPV wallets can "speak" on of the
>>> possible encryption techniques. Encrypting traffic below the application
>>> layer is extremely hard to set up for non-experienced users.
>>
>> Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.
>
> If we assume increasing amount of novice users starting with Bitcoin every day, how should these users run wallets without increasing centralization by using webwallets or client/central-server wallets?
> (which is OT, but an interesting question)
I fully appreciate the significant security risk arising from the proliferation of web wallets. This can only be resolved by people validating using code under their own control.
Encryption/authentication are orthogonal to this question, assuming people have wallets directly attached to full nodes. Remoting a wallet from a full node does not require use of the P2P protocol, and can use encryption/authentication without the concerns I've raised. It properly places the trust boundary around a wallet and its trusted node(s), as opposed to spanning (independent) nodes.
>>> On top of that, encryption allows us to drop the SHA256 checksum per p2p
>>> message which should result in a better performance on the network layer
>>> once BIP151 is deployed.
>>
>> I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.
>>
>>> I agree that BIP151 _must_ be deployed together with an authentication
>>> scheme (I'm working on that) to protect again MITM during encryption
>>> initialization.
>>
>> At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.
>
> I think BIP151 does what it says: encryption and laying groundwork for authentication.
> You wouldn't probably say BIP32 is incomplete because it does not cover
> a scheme how to recover funds (or BIP141 [SW consensus] is incomplete
> because it does not cover p2p [BIP144]).
This is an unfair statement. You have acknowledged that BIP151 requires authentication to accomplish its sole objective.
> The missing MITM protection (solvable over auth) is prominent mentioned in the BIP [1].
As I pointed out.
> (from your other mail):
>>> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
>>
>> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
>> The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.
>
> I agree that the secure trusted 2nd channel key-sharing problem can be significant for large networks and/or connecting to unknown identities.
>
> But as said, there could be multiple ways of sharing identity keys.
> If you want to connect your node to serval other trusted nodes, you can simply physically preshare keys or do it over GPG / Signal App, etc..
Again, it's the fact that authentication is required that produces the issue, not that there are multiple ways to implement it.
> And if I have followed the news correctly, there are some clever guys
> working on various internet of trust 2.0 proposals...
I don't see how this is relevant.
>>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>>> (only ephemeral keys).
>>
>> BIP 151 is incomplete without authentication.
>
> I would agree if you would say, _trusted encryption_ is incomplete with
> authentication. But IMO BIP151 is complete and should be deployed together with one or multiple authentication schemes.
It seems that we are talking past each other. You haven't yet addressed the issue that I have raised.
It is the requirement for authentication of any node that any other node may wish to connect to that is the issue. We end up with something that looks like WoT or PKI. And if not fully controlled by PKI (so using WoT) we will have hybrid nodes that accept untrusted connections and propagate information between trusted and untrusted nodes.
> [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks
>

2023-06-07 19:51:40 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell <greg at xiph.org> wrote:
>
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> An "out of band key check" is not part of BIP151.
>
> It has a session ID for this purpose.
Passing the session ID out of band is authentication. As this is explicitly not part of BIP151 it cannot be that BIP151 provides the tools to detect a attack (the point at issue).
>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>
> One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA.
The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated.
It doesn't matter who I am, maybe I am the NSA. I don't argue from a position of authority. Signing my emails while traveling on holiday with only my phone gets a little tedious.
The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario.
The possibility that authentication may become required to participate in this trustless network is a legitimate concern, and one that has not been addressed.
e

2023-06-07 19:51:39 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:Hi Cameron, good to hear from you!
> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>
> Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker.
This is not really the case with Bitcoin. A MITM attack does not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.
> Stopping passive attacks is the low hanging fruit. This should be taken first.
>
> Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science.
>
> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication.
It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.
> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
>
> Sent from my iPhone
>
>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> An "out of band key check" is not part of BIP151.
>>
>> It has a session ID for this purpose.
>>
>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>
>> One might wonder how you ever use a Bitcoin address, or even why we
>> might guess these emails from "you" aren't actually coming from the
>> NSA.
>> _______________________________________________
>> 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/20160629/5fb01d58/attachment.html>

2023-06-07 19:51:38 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:> On Jun 28, 2016, at 10:36 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote:
>>
>>
>>>> On Jun 28, 2016, at 10:14 PM, Peter Todd <pete at petertodd.org> wrote:
>>>>
>>>> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:
>>>> Hi Peter,
>>>>
>>>> What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected?
>>>
>>> BIP151 gives users the tools to detect a MITM attack.
>>>
>>> It's kinda like PGP in that way: lots of PGP users don't properly check keys,
>>
>> PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel.
>>
>> All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks.
>
> Easy: anonymous peers aren't always actually anonymous.
>
> A MITM attacker can't easily distinguish communications between two nodes that
> randomly picked their peers, and nodes that are connected because their operators manually used -addnode to peer; in the latter case the operators can
> check whether or not they're being attacked with an out-of-band key check.
An "out of band key check" is not part of BIP151. It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
e

2023-06-07 19:51:37 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:Hi Peter,
What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected?
e
> On Jun 28, 2016, at 8:22 PM, Peter Todd <pete at petertodd.org> wrote:
>
> On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote:
>>> 1) Transaction censorship
>>> ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
>>> transactions. Regardless if you are a miner or a validation/wallet node.
>>>
>>> 2) Peer censorship
>>> MITM can remove or add entries from a "addr" message.
>>>
>>> 3) Fingerprinting
>>> ISPs or any other MITM can intercept/inject fingerprinting relevant
>>> messages like "mempool" to analyze the bitcoin network.
>>
>> Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply).
>
> Being able to easily detect MITM attacks is a _huge_ step forward that
> shouldn't be underestimated; even if 99% of users aren't in a position to
> detect the MITM you only need a small subset of users that do the necessary
> checks to alert the wider community, who can then respond with stronger
> security measures. Those measures are likely to be more costly - authenticated
> systems are significantly harder than not - so better to save your efforts
> until the need for them is more obvious.
>
> Also the fact that an attack has a reasonable probability of detection is a big
> disincentive for many types of attackers - note how one of the things revealed
> in the Snowden leaks was the fact that the NSA generally tries quite hard to
> avoid tipping off targets to the fact that they're being surveilled, with a
> myriad of carefully scripted policies to control when and how exploits are used
> against targets.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 19:51:37 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:> On Jun 28, 2016, at 10:14 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:
>> Hi Peter,
>>
>> What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected?
>
> BIP151 gives users the tools to detect a MITM attack.
>
> It's kinda like PGP in that way: lots of PGP users don't properly check keys,
PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel.
All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks.
> so an attacker won't have a hard time MITM attacking those users. But some
> users do check keys, a labor intensive manual process, but not a process that
> requires any real cryptographic sophistication, let alone writing any code.
> It's very difficult for widescale attackers to distinguish the users who do
> check keys from the ones that don't, so if you MITM attack _any_ user you run
> the risk of running into one of the few that does check, and those users can
> alert everyone else.
>
> The key thing, is we need to get everyones communications encrypted first: if
> we don't the MITM attacker can intercept 99% of the communications with 0% risk
> of detection, because the non-sophisticated users are trivially distinguishable from the sophisticated users: just find the users with unencrypted
> communications!
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 19:51:36 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:Hi Jonas, I'll follow up in your second reply as well. Responses inline:
> On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Eric
>
>> I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it.
>>
>> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
>>
>> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
>>
>> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.
> In my opinion, the question should be "why would you _not_ encrypt".
1) creation of a false sense of security
2) as a tradeoff against anonymity
3) benefit does not justify cost
> 1) Transaction censorship
> ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
> transactions. Regardless if you are a miner or a validation/wallet node.
>
> 2) Peer censorship
> MITM can remove or add entries from a "addr" message.
>
> 3) Fingerprinting
> ISPs or any other MITM can intercept/inject fingerprinting relevant
> messages like "mempool" to analyze the bitcoin network.
Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply).
> 4) SPV
> For obvious reasons regarding BF (see BIP or above).
>
> 5) Goundwork for a "client-server" model over the P2P channel
> Fee estimation, bloom-filters, or any other message type that requires
> authentication.
I do not challenge the usefulness and appropriateness of encryption with authentication in a client-server blockchain protocol.
> I would not reduce BIP151 to only solve the BF privacy/censorship problem.
>
> If we agree that censorship-resistance is one of the main properties of Bitcoin,
We do.
> then we should definitively use a form of end-to-end encryption between nodes. Built into the network layer.
This is the assumption that I'm questioning.
> There are plenty of other options to solve this problem. stunnel,
> Bernsteins CurveCP, VPN, etc. which are available since years.
> But the reality has shown that most bitcoin traffic is still unencrypted.
The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.
As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).
Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.
In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).
> Example: IIRC non of the available SPV wallets can "speak" on of the
> possible encryption techniques. Encrypting traffic below the application
> layer is extremely hard to set up for non-experienced users.
Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.
> On top of that, encryption allows us to drop the SHA256 checksum per p2p
> message which should result in a better performance on the network layer
> once BIP151 is deployed.
I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.
> I agree that BIP151 _must_ be deployed together with an authentication
> scheme (I'm working on that) to protect again MITM during encryption
> initialization.
At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.
I'll respond to the question of authentication in your follow-up post.
e
> ---
> </jonas>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:51:36 CEST

- reply

📅 Original date posted:2016-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it.
I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.
e
-----BEGIN PGP SIGNATURE-----
Version: oPenGP 6.0 on iOS
iQEVAwUBV3IkYjzYwH8LXOFOAQg+iggAkFShi/ibZXiVv3A3z1a1SMd+4ar0kiZk
mCkBBZaatoW8tXVZmuv5xzLnj3ali9Y4jp/3h2nUJ1B4ov2kcB0kZIKE/a1DTFwb
4X3uSzgu0lEAqSZormOvt7Op46NPn6KJ+/wTtP4lUFU72lSd7qrVKMlCVc88VE7/
pMloKSc69nAeFIkyWbOUi/zDzefu/5tarfif85jumooYjPmAwJnkgiPCqpqBbuga
5lBdS1r47KK+SaDFl6Cbn4i/c6tBPLTnu+TR7TEKOW5vwVA7eUqb6SOK7pETWJGK
0Ii4ZWYt7MOPSEda381CMjWEwtsCNp0eI4GPZAAz+jNLo4G1+PAbaw==
=Balw
-----END PGP SIGNATURE-----

2023-06-07 19:49:31 CEST

- reply

📅 Original date posted:2016-03-03
📝 Original message:On 03/02/2016 03:02 PM, Peter Todd wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev wrote:
>>> A 6 month investment with 3 months on the high subsidy and 3 months on low subsidy would not be made…
>>
>> Yes, this is the essential point. All capital investments are made based on expectations of future returns. To the extent that futures are perfectly knowable, they can be perfectly factored in. This is why inflation in Bitcoin is not a tax, it’s a cost. These step functions are made continuous by their predictability, removing that predictability will make them -- unpredictable.
>
> You know, I do agree with you.
>
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same
> UTXO set as Bitcoin as a means of initial coin distribution.
>
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those
> coins. We may choose not to, but if 95% of the hashing power decides to
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
I agree, this is a perfectly rational interpretation. I also agree that
this particular instance is academic. But I see more to this than
accepting what is possible.
In the case of Federal Reserve Notes the gold obligation was abrogated.
This was (at least) a contract default, implemented by force of arms.
This contentious hard fork was clearly an attack.
But in a system with no authority and in which nobody has formed a
contractual obligation with anyone else, what would constitute an attack
on the money? There is no difference between state attacks on (or
collusion with) miners and miners acting on self interest.
One answer is that nothing is an attack, it's up to the market to
decide. But to the extent that there can be an attack on the money, the
attempt to move the value of the coin to an altcoin (hard fork) is it.
Though the choice of the term "attack" isn't essential.
The importance of recognizing an attack is that it affords one the
opportunity to defend against it. People holding "dollars" in 1933 were
ill equipped to defend against a system level attack (monetary policy),
in part because many did not recognize it as such, and in part because
there was insufficient preparation by those who did.
I see us building the tools and awareness necessary for defense. As you
say, nobody has to buy into an altcoin forked from their coin. This much
is simple to achieve. The more difficult problem is preserving the
utility of the original coin. Clearly the purpose of a hard fork (as
opposed to a new coin) is to transfer this value.
We've all seen arguments for contentious hard fork deployment that
explicitly depend on the fear of monetary loss to drag people to
acceptance. While this may be the nature of the technology, it's
important that we develop effective defense against it.
Ultimately the only defense is individual validation. The collusion of
banks (web wallets) with miners in attacking consensus is obvious. But
even without active collusion, the surrender of validation leaves people
just as defenseless as *being* unarmed while retaining a right to
*become* armed.
Even if every person mines at the same level, the system amounts to
little more than majority rule if validation is not decentralized. There
are people perfectly willing to exploit this weakness.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160303/10b4501e/attachment.sig>

2023-06-07 19:49:30 CEST

- reply

📅 Original date posted:2016-03-02
📝 Original message:> A 6 month investment with 3 months on the high subsidy and 3 months on low subsidy would not be made…
Yes, this is the essential point. All capital investments are made based on expectations of future returns. To the extent that futures are perfectly knowable, they can be perfectly factored in. This is why inflation in Bitcoin is not a tax, it’s a cost. These step functions are made continuous by their predictability, removing that predictability will make them -- unpredictable.
Changing these futures punishes those who have planned properly and favors those who have not. Sort of like a Bitcoin bail-in; are some miners are too big to fail? It also creates the expectation that it may happen again. This infects the money with the sort of uncertainty that Bitcoin is designed to prevent.
e
From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Wednesday, March 2, 2016 10:08 AM
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
For example, it is theoretically possible that 100% of miners (not 50%
or 10%) will shut off their hardware. This is because it is revenue
which ~halves, not profit.
It depends on how much is sunk costs and how much is marginal costs too.
If hashing costs are 50% capital and 50% marginal, then the entire network will be able to absorb a 50% drop in subsidy.
50% capital costs means that the cost of the loan to buy the hardware represents half the cost.
Assume that for every $100 of income, you have to pay $49 for the loan and $49 for electricity giving 2% profit. If the subsidy halves, then you only get $50 of income, so lose $48.
But if the bank repossesses the operation, they might as well keep things running for the $1 in marginal profit (or sell on the hardware to someone who will keep using it).
Since this drop in revenue is well known in advance, businesses will spend less on capital. That means that there should be less mining hardware than otherwise.
A 6 month investment with 3 months on the high subsidy and 3 months on low subsidy would not be made if it only generated a small profit for the first 3 and then massive losses for the 2nd period of 3 months. For it to be made, there needs to be large profit during the first period to compensate for the losses in the 2nd period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/0439b647/attachment.html>

2023-06-07 19:40:31 CEST

- reply

📅 Original date posted:2015-09-19
📝 Original message:On 09/19/2015 12:57 AM, NxtChg wrote:>
>> Your vision of censorship resistance is to become such a strong
>> central authority that you can resist it in direct physical
>> confrontation. If you succeed at this, you are the threat.
>
> My vision is a strong _decentralized_ system, which is:
>
> a) too important to close,
Your argument is that the state is not a threat to a system designed to
deprive the state of seigniorage, because the state will see that system
as too important?
Bitcoin cannot be both decentralized and reliant on being, "too
important to close". If it can be closed there is insufficient
decentralization.
I was concerned that this was going off topic for a technical forum.
However this is the central technical issue of Bitcoin. If one does not
understand the threat then one cannot model it or design systems to
defend against it. On the other hand, this is unfortunately not new
territory, so I'll leave it at this, which is also not news to most of us...
> b) able to provide adequate response to governments, like EFF or
Google do.
"The National Security Agency paid millions of dollars to cover the
costs of major internet companies involved in the Prism surveillance
program after a court ruled that some of the agency's activities were
unconstitutional, according to top-secret material passed to the Guardian.
The technology companies, which the NSA says includes Google..."
http://www.theguardian.com/world/2013/aug/23/nsa-prism-costs-tech-companies-paid
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/9fb0d870/attachment.sig>

2023-06-07 19:40:30 CEST

- reply

📅 Original date posted:2015-09-19
📝 Original message:On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote:
>> While to many of us that sounds crazy, if you're threat model assumes
>> Bitcoin is a legal/regulated service provided by a highly trusted
>> mining community it's a reasonable design.
>
> There is a large, grey area all the way to "legal/regulated service
> provided by a highly trusted mining community". Painting the worst
> looking picture is either a defect in thinking or intentional FUD.
The state is the threat in the Bitcoin threat model. You comments below
acknowledge it. The assumption of hostile state actors is the only
rational starting point. That which is regulated (and regulatable) in
Bitcoin is the attack surface.
While of course there are various degrees of weakness, the reference to
"legal/regulated service provided by a highly trusted mining" as the
threat is by no means irrational or misdirecting. This threat represents
the difference between Bitcoin and Fedcoin.
I found Mike's threat model downright disturbing. All benefits of
Bitcoin arise from its resistance to this threat. Anyone investor in
this space should be paying attention... the apparent benefits of
Bitcoin will vaporize with regulation.
>> Mike Hearn recently posted his threat model, which specifically
>> argues we should assume governments are not a threat.
>
> There are two ways to fight governments:
>
> 1. either you become too big to close, so political repercussions
> become unacceptable
This is extremely naive. At a minimum, getting popular/successful (and
regulated) is the formula for regulatory capture.
> 2. or you become too tiny to hunt, in which case you are much better
> off with a specialized alt-coin, designed specifically for that
> purpose.
I assume you are referring some marginal and largely irrelevant effort.
False dichotomy.
[cross-posted to libbitcoin]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/ca1214fd/attachment.sig>

2023-06-07 19:40:30 CEST

- reply

📅 Original date posted:2015-09-19
📝 Original message:On 09/19/2015 12:27 AM, NxtChg wrote:
>> This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture.
>
> Let me give you an example.
>
> Suppose you are a regular guy, say Peter Todd, and you are faced with 10 policemen in anti-riot gear.
>
> You can fight them in two ways:
>
> 1. become stronger, so you could provide an adequate response, either by turning into Hulk or by getting another 30-50 Peter Todds.
Your vision of censorship resistance is to become such a strong central
authority that you can resist it in direct physical confrontation. If
you succeed at this, you are the threat.
> 2. lose some fat, learn a few parkour tricks and move around mostly by night behind dumpsters.
And your alternative is to lurk in dark corners.
The inability to see another option is the inability to understand what
Satoshi created.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/5262f3ce/attachment.sig>

2023-06-07 19:35:55 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On 08/19/2015 04:27 PM, Jorge Timón wrote:
> On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric at voskuil.org> wrote:
>> [cross-posted to libbitcoin]
>>
>> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
>> 19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>> But the consensus code should NOT be subject to the same commit
>> policies…and we should make an effort to separate the two clearly. And
>> we should find a way to communicate the difference succinctly and
>> clearly to laypeople (which is something I think the XT opponents have
>> been horrible at doing so far).
>>>
>>> I think that effort is in progress (again, much slower that I would
>>> like it to be) and it's called libconsensus.
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation (even if it is the reference one) and it's not "the
>>> specification of the consensus rules" which is a "privileged" position
>>> that brings all sorts of misunderstandings and problems (the block
>>> size debate is just one example).
>>
>> Jorge,
>>
>> I applaud your efforts and objectives WRT libconsensus independence. But
>> as you know I differ with you on this point:
>>
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation
>>
>> I do not consider Bitcoin Core just another implementation as long as
>> libconsensus is built directly out of the bitcoind repository. It's a
>> finer point, but an important one. Eric makes this point emphatically as
>> well:
>>
>>>> But the consensus code should NOT be subject to the same commit
>> policies...and we should make an effort to separate the two clearly.
>>
>> As you have implied, it's not likely to happen in the Bitcoin Core repo.
>> Taking a dependency on Bitcoin Core is a metaphorical deal with the
>> devil from our perspective. So my question is, how do you expect other
>> implementations to transition off of that repository (and commit
>> policies)? Or do you expect the dependency to be perpetual?
>
> No, as previously explained, once libconsensus is complete it can be
> moved to a separate repository like libsecp256k1.
I don't see this happening any time soon, and I'm not sure why we should
wait for it.
> At first it will need to be a subtree/subrepository of Bitcoin Core
> (like libsecp256k1 currently is), but I still don't undesrtand how
> that can possibly be a problem for alternative implementations (they
> can use a subtree as well if they want to). Depending on a separated
> libconsensus doesn't "make Bitcoin Core a dependency" more than
> depending on libsecp256k1 currently does.
>
>> In our discussion leading up to libbitcoin building libbitcoin-consensus
>> we disagreed on whether intentional hard forks would (or even could)
>> happen. I think that issue is now settled. So my question remains how do
>> stakeholders (users/miners) maintain consensus when it's their
>> individual intent (the first objective of libconsensus), and diverge
>> when intended (which a direct dependency on libconsensus makes harder)?
>> IMO it's unreasonable to operate as if this won't happen, given that it has.
>
> I believe the simplest option...
You might consider this as feedback from your customer base.
> would be to fork the libconsensus
> project and do the schism/controversial/contentious hardfork there.
> But of course modifying libconsensus will be much easier than
> modifying Bitcoin Core (if anything, because the amount of code is
> much smaller).
That's a false dichotomy. We never would have considered forking Bitcoin
Core, and still wouldn't. Why would we set ourselves up for this
disruption, which would inevitably lead to us factoring the consensus
portions of libconsensus out of /bitcoin at the 11th hour?
We have to operate as if it can happen at any time. Otherwise we have
relinquished control of this vote and failed our users. Given that
operating assumption, it is much safer for us to have already done this
work (which we did). [It also provides a forcing function for us to
review in detail any consensus changes that get pushed out.]
My question is why you would not embrace an independent consensus
repository? Your work to evolve it doesn't change.
>> There are a very small number of implementations that rely on consensus
>> (fewer that aren't also forks of Bitcoin Core). I think it's time we
>> discuss how to work together to achieve our mutual goal. I assume you
>> have been in contact with all of us. If you would like to facilitate
>> this I'd be happy to join in an offline discussion.
>
> Unfortunately I only directly contacted libbitcoin because I was
> subscribed to the list at the time (maybe I'm still subscribed, not
> really sure).
> The other attempts to get feedback from other alternative
> implementations have been just mostly-ignored threads in bitcoin-dev.
> So, no, I cannot facilitate such a discussion, but I'm more than happy
> to collaborate to achieve our mutual goal.
OK
e

2023-06-07 19:35:53 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>> But the consensus code should NOT be subject to the same commit
policies…and we should make an effort to separate the two clearly. And
we should find a way to communicate the difference succinctly and
clearly to laypeople (which is something I think the XT opponents have
been horrible at doing so far).
>
> I think that effort is in progress (again, much slower that I would
> like it to be) and it's called libconsensus.
> Once we have libconsensus Bitcoin Core it's just another
> implementation (even if it is the reference one) and it's not "the
> specification of the consensus rules" which is a "privileged" position
> that brings all sorts of misunderstandings and problems (the block
> size debate is just one example).
Jorge,
I applaud your efforts and objectives WRT libconsensus independence. But
as you know I differ with you on this point:
> Once we have libconsensus Bitcoin Core it's just another
> implementation
I do not consider Bitcoin Core just another implementation as long as
libconsensus is built directly out of the bitcoind repository. It's a
finer point, but an important one. Eric makes this point emphatically as
well:
>> But the consensus code should NOT be subject to the same commit
policies...and we should make an effort to separate the two clearly.
As you have implied, it's not likely to happen in the Bitcoin Core repo.
Taking a dependency on Bitcoin Core is a metaphorical deal with the
devil from our perspective. So my question is, how do you expect other
implementations to transition off of that repository (and commit
policies)? Or do you expect the dependency to be perpetual?
In our discussion leading up to libbitcoin building libbitcoin-consensus
we disagreed on whether intentional hard forks would (or even could)
happen. I think that issue is now settled. So my question remains how do
stakeholders (users/miners) maintain consensus when it's their
individual intent (the first objective of libconsensus), and diverge
when intended (which a direct dependency on libconsensus makes harder)?
IMO it's unreasonable to operate as if this won't happen, given that it has.
There are a very small number of implementations that rely on consensus
(fewer that aren't also forks of Bitcoin Core). I think it's time we
discuss how to work together to achieve our mutual goal. I assume you
have been in contact with all of us. If you would like to facilitate
this I'd be happy to join in an offline discussion.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/091d7e5f/attachment.sig>

2023-06-07 19:35:27 CEST

- reply

📅 Original date posted:2015-08-16
📝 Original message:[cross-posted to libbitcoin]
I applaud this effort not for the merits of the hard fork but on the
effects of the code fork. We have been witnessing the self-destruction
of Bitcoin's central authority. This is a necessary outcome.
Understandably, many are concerned that if consensus settles on a larger
block size Bitcoin will suffer greater centralization. The point of
Bitcoin however is that nobody is in control of consensus. If a
consensus decision leads to centralization, the consensus will move.
Yes, when this happens people who bet on the losing fork will lose
money. This is how Bitcoin works. One bets not on personal desires but
on what others will accept. That is how consensus is built.
Some fret that if this process evolves Bitcoin will suffer a
catastrophic loss of "value" and not recover. This may come to pass, but
there is no avoiding the possibility.
The ease with which consensus can move when it wants to is important. In
other words, friction is weakness and a single overly complex codebase
is high friction.
Amir saw this coming before most. While we are posting manifestos, I
thought it more than appropriate to quote from the libbitcoin manifesto:
> If development is too centralised, with a small core infrastructure,
> then businesses will put real pressure to have features that destroy
> the integrity of the Bitcoin network.
> ...
> The possible malicious scenarios are endless....At the other end of
> the spectrum, is putting development effort into diversifying the
> ecosystem to protect against censorship... That's where developers
> who believe in Bitcoin should devote time to.
> ...
> A diversified Bitcoin of many wallets and implementations is a strong
> and pure Bitcoin. To protect the integrity of the network, we need to
> eliminate single points of failure. An inbred Bitcoin with the same
> software code everywhere shares the same weaknesses, and is
> susceptible to the same attacks...
>
> The implications of a diversified Bitcoin is a Bitcoin difficult to
> control. It also sets the protocol in stone, as nobody has sole power
> over the standard. Consensus from many parties is the way forwards.
>...
> Viewed over a longer time period, extra or unnecessary features seem
> to creep into the system beyond the initial goals and the small code
> of 15,000 lines set by Satoshi. The result will be a Bitcoin that
> becomes increasingly difficult to understand or implement without a
> huge initial investment of resources, time and people. No single
> person will fully understand Bitcoin anymore, and development
> monopolies will be further enforced.
http://libbitcoin.dyne.org/libbitcoin-manifesto.pdf
e
On 08/15/2015 10:02 AM, Mike Hearn via bitcoin-dev wrote:
> Hello,
>
> As promised, we have released Bitcoin XT 0.11A which includes the bigger
> blocks patch set. You can get it from
>
> https://bitcoinxt.software/
>
> I feel sad that it's come to this, but there is no other way. The
> Bitcoin Core project has drifted so far from the principles myself and
> many others feel are important, that a fork is the only way to fix things.
>
> Forking is a natural thing in the open source community, Bitcoin is not
> the first and won't be the last project to go through this. Often in
> forks, people say there was insufficient communication. So to ensure
> everything is crystal clear I've written a blog post and a kind of
> "manifesto" to describe why this is happening and how XT plans to be
> different from Core (assuming adoption, of course).
>
> The article is here:
>
> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>
> It makes no attempt to be neutral: this explains things from our point
> of view.
>
> The manifesto is on the website.
>
> I say to all developers on this list: if you also feel that Core is no
> longer serving the interests of Bitcoin users, come join us. We don't bite.
> ________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/3390a5eb/attachment.sig>

2023-06-07 19:33:53 CEST

- reply

📅 Original date posted:2015-08-11
📝 Original message:Hi Michael,
> One of the key characteristics toward that is Bitcoin being
> inexpensive to transact.
What you seem to be missing is *why* bitcoin is better money. Have you
considered why is it comparatively inexpensive to transact in a medium
that is based on such a highly inefficient technology?
You might want to consider that these two considerations are not
independent. The reduced cost of transacting (and carrying) Bitcoin is a
direct consequence of its trustless nature. Any compromise in that
nature will eliminate that advantage, and therefore Bitcoin.
Bitcoin is designed to solve only one problem that other systems do not.
To accomplish this it makes significant compromises in other areas. The
benefit of this solution is that it cannot be effectively controlled by
the state. As a result, all of the associated overhead is eliminated.
Hence the net cost benefit despite high technical costs.
So this is a case where you should be careful what you wish for.
e
On 08/11/2015 02:18 PM, Michael Naber via bitcoin-dev wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the
> only reason why we're all even here on this mailing list talking about
> this, is because Bitcoin is growing, since it's "better money than other
> money". One of the key characteristics toward that is Bitcoin being
> inexpensive to transact. If that characteristic is no longer true, then
> Bitcoin isn't going to grow, and in fact Bitcoin itself will be replaced
> by better money that is less expensive to transfer.
>
> So the importance of this issue cannot be overstated -- it's compete or
> die for Bitcoin -- because people want to transact with global consensus
> at high volume, and because technology exists to service that want, then
> it's going to be met. This is basic rules of demand and supply. I don't
> necessarily disagree with your position on only wanting to support
> uncontroversial commits, but I think it's important to get consensus on
> the criticality of the block size issue: do you agree, disagree, or not
> take a side, and why?

2023-06-07 17:45:58 CEST

- reply

2023-06-07 17:43:10 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote:
> Only being partly serious - I strongly am in favor of a sufficiently
modularized codebase that swapping out consensus rules is fairly
straightforward and easy to test...
We (libbitcoin) have taken the time to publish and maintain bitcoind's
"libbitcoinconsensus" source files as an independent C++ library (with
Java and Python bindings).
https://en.bitcoin.it/wiki/Libbitcoin_Consensus
It can be easily verified against bitcoind sources and in builds of
libbitcoin-blockchain it can be swapped out for libbitcoin's native
consensus checks.
https://en.bitcoin.it/wiki/Libbitcoin_Blockchain#Consensus_Validation
So there is really no reason to consider the original client synonymous
with consensus. I initially argued for this library to be natively
isolated from bitcoind, but that didn't seem to be in the cards so we
did it independently.
In any case I agree with your stated need for this isolation (if not the
means) for the reasons you state. The community needs to move beyond a
largely singular and monolithic codebase that is holding that position
in part due to fear about consensus bug forks.
To make choice regarding consensus an actual choice (and thereby actual
consensus) the modularity you suggest is essential. One must be able to
take new developments without having to take consensus changes. The
option to fork the codebase is not reasonable for most people. At this
point there is no defensible reason for coupling consensus checks with
other features.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/3bf1af8a/attachment.sig>

2023-06-07 17:42:44 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:I should add that the obvious resolution to this set of problems is to
use a distinct Tor route for each Bitcoin address, not to reinvent Tor
and reproduce its community. So ultimately this is easy to implement,
but the downside is performance.
But it's important to keep in mind that poor-performing perfect privacy
for address monitoring is trivial to achieve - just sync the full
blockchain.
Presumably if you don't trust a server to protect your privacy, you also
don't trust it with your money. So any robust privacy optimization would
at least be designed to support partial (SPV) chain clients. It would
also need to support wallet restoration from backup.
The level of privacy will always be a performance trade-off. The ideal
solution would allow a client to balance privacy against performance.
e
On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> Hi Thomas,
>
> The scheme is essentially onion routing. The set of {M} are entry nodes
> and the set of {S} are exit nodes. The weaknesses are as you would see
> in an analogous TOR implementation:
>
> (1) The lack of relay nodes {R} make collaboration between any subset of
> {M} and {S} trivial.
>
> (2) OR is a mixnet, so the size of the network matters a lot.
>
> (3) The directory is a perpetual weakness.
>
> (4) Content is visible to the exit node (or the final service). This
> means each address must be passed via a distinct route to prevent
> correlation.
>
> e
>
> On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
>> Hello,
>>
>> Although Electrum clients connect to several servers in order to fetch
>> block headers, they typically request address balances and address
>> histories from a single server. This means that the chosen server knows
>> that a given set of addresses belong to the same wallet. That is true
>> even if Electrum is used over TOR.
>>
>> There have been various proposals to improve on that, but none of them
>> really convinced me so far. One recurrent proposal has been to create
>> subsets of wallet addresses, and to send them to separate servers. In my
>> opinion, this does not really improve anonymity, because it requires
>> trusting more servers.
>>
>> Here is an idea, inspired by TOR, on which I would like to have some
>> feedback: We create an anonymous routing layer between Electrum servers
>> and clients.
>>
>> * Each server S publishes a RSA public key, KS
>> * Each client receives a list of available servers and their pubkeys
>> * For each wallet address, addr_i, a client chooses a server S_i, and a
>> RSA keypair (K_addr_i, k_addr_i)
>> * The client creates a list of encrypted requests. Each request contains
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
>> * The client chooses a main server M, and sends the list of encrypted
>> requests to M
>> * M dispatches the client's requests to the corresponding servers S_i
>> (without the client's IP address.)
>> * Each server decrypts the requests it receives, performs the request,
>> and encrypts the result with K_addr_i
>> * M receives encrypted responses, and forwards them to the client.
>> * The client decrypts the encrypted response with k_addr_i
>>
>> What do you think? What are the costs and benefits of such an approach?
>>
>> (Note: this will not work if all servers, or a large fraction of them,
>> are controlled by the same entity that controls M)
>>
>>
>> Thomas
>> _______________________________________________
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/bba8ae1a/attachment.sig>

2023-06-07 17:31:10 CEST

- reply

📅 Original date posted:2015-02-22
📝 Original message:Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the "r"
and "payment_url" parameters makes sense, with only the potential
backward compat issue on payment_url.
> TBIP75 furthermore proposes to include an additional 'h' parameter
> which would be a hash of the BIP70 payment request, preventing a MITM
> attack on the Bluetooth channel even if the BIP70 payment request
> isn't signed. This would have also been my suggestion, although I
> know that Mike Hearn has raised concerns about this approach. One
> being, that one needs to finalize the BIP70 payment request at the
> time the QR code and NFC URI is generated.
> ...
> 3) Are there other comments regarding 'h' parameter as per TBIP75?
Yes, this design is problematic from a privacy standpoint. Anyone within
the rather significant range of the Bluetooth terminal is able to
capture payment requests and correlate them to people. In other words it
can be used to automate tainting.
The problem is easily resolved by recognizing that, in the envisioned
face-to-face trade, proximity is the source of trust. Even in the above
proposal the "h" parameter is trusted because it was obtained by
proximity to the NFC terminal. The presumption is that this proximity
produces a private channel.
As such the "tap" should transfer a session key used for symmetric block
cipher over the Bluetooth channel. This also resolves the issue of
needing to formulate the payment request before the NFC.
As an aside, in other scenarios, such as an automated dispenser, this
presumption does not hold. The merchant is not present to guard against
device tampering. Those scenarios can be secured using BIP70, but cannot
guarantee privacy.
The other differences I have with the proposal pertain to efficiency,
not privacy or integrity of the transaction:
The proposed resource name is redundant with any unique identifier for
the session. For example, the "h" parameter is sufficient. But with the
establishment of a session key both as I propose above, the parties can
derive a sufficiently unique public resource name from a hash of the
key. An additional advantage is that the resource name can be
fixed-length, simplifying the encoding/decoding.
The MAC address (and resource name) should be encoded using base58. This
is shorter than base16, is often shorter than base64, better
standardized and does not require URI encoding, and is generally
available to implementers.
There is no need for the establishment of two Bluetooth services.
I would change the payment_url recommendation so that the list order
represents a recommended ordering provided by the terminal for the wallet.
I wrote up my thoughts on these considerations last year and recently
revised it by adding a section at the end to incorporate the "r" and
"payment_url" generalizations from Andreas and Andy.
https://github.com/evoskuil/bips/tree/master/docs
e
On 02/22/2015 11:08 AM, Jan Vornberger wrote:
> Hi everyone,
>
> I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
> displays QR codes, but also provides payment requests via NFC. It can optionally
> receive the sender's transaction via Bluetooth, so if the sender wallet
> supports it, the sender can be completely offline. Only the terminal needs an
> internet connection.
>
> Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch
> in the future) on the NFC pad, confirms the transaction on their phone
> (or smartwatch) and the transaction completes via Bluetooth and/or the phone's
> internet connection.
>
> You can see a prototype in action here:
>
> https://www.youtube.com/watch?v=P7vKHMoapr8
>
> The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
> works as shown today. However, some parts - especially the Bluetooth stuff - are
> custom extensions of Schildbach's wallet which are not yet standard.
>
> I'm writing this post to document my experience implementing NFC and offline
> payments and hope to move the discussion forward around standardizing some of
> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
> relevant here as well.
>
>
> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>
> Before I get into the implementation details, a few words for why I decided to
> go with the combination of NFC and Bluetooth:
>
> Doing everything via NFC is an interesting option to keep things simple, but the
> issue is, that one usually can't maintain the connection while the user confirms
> the transaction (as they take the device back to press a button or maybe enter a
> PIN). So there are three options:
>
> 1. Do a "double tap": User taps, takes the device back, confirms, then taps
> again to transmit the transaction. (I think Google Wallet does something like
> this.)
>
> 2. Confirm beforehand: User confirms, then taps and everything can happen in one
> go. The disadvantage is, that you confirm the transaction before you have seen
> the details. (I believe Google Wallet can also work this way.)
>
> 3. Tap the phone, then establish a Bluetooth connection which allows you to do
> all necessary communication even if the user takes the device back.
>
> I feel that option 3 is the nicest UX, so that is what I am focusing on right
> now, but there are pros and cons to all options. One disadvantage of option 3 in
> practice is, that many users - in my experience - have Bluetooth turned off, so
> it can result in additional UI dialogs popping up, asking the user to turn on
> Bluetooth.
>
> Regarding doing everything via Bluetooth or maybe BLE: I have been following the
> work that Airbitz has done around that, but personally I prefer the NFC
> interaction of "I touch what I want to pay" rather than "a payment request comes
> to me through the air and I figure out whether it is meant for me/is legitimate".
>
>
> ## NFC data formats ##
>
> A bit of background for those who are not that familiar with NFC: Most Bitcoin
> wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I
> am aware (with CoinBlesk being an exception, which uses host-based card
> emulation, if I understand it correctly). NDEF defines a number of record types,
> among them 'URI' and 'Mime Type'.
>
> A common way of using NFC with Bitcoin is to create a URI record that contains a
> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support
> the mime type record, which is then set to 'application/bitcoin-paymentrequest'
> and the rest of the NFC data is a complete BIP70 payment request.
>
>
> ## Implementation ##
>
> To structure the discussion a little bit, I have listed a number of scenarios to
> consider below. Not every possible combination is listed, but it should cover a
> bit of everything.
>
> Scenarios:
>
> 1) Scan QR code, transmit transaction via Bitcoin network
> Example QR code: bitcoin:1asdf...?amount=42
>
> 2) Touch NFC pad, transmit transaction via Bitcoin network
> Example NFC URI: bitcoin:1asdf...?amount=42
>
> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
> Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>
> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
> Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>
> 5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP
> Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request
>
> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
> Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
> Payment request has 'payment_url' set to 'bt:1234567890AB'
>
> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
> Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
> Payment request has 'payment_url' set to 'bt:1234567890AB'
>
> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just
> listing them here for comparison. Scenario 3 is what is often in use now, for
> example when using a checkout screen by BitPay or Coinbase.
>
> I played around with both scenarios 4 and 5, trying to decide whether I should
> use an NFC URI record or already provide the complete BIP70 payment request via
> NFC.
>
> My experience here has been, that the latter was fairly fragile in my setup
> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried
> with signed payment requests that were around 4k to 5k and the transfer would
> often not complete if I didn't hold the phone perfectly in place. So I quickly
> switched to using the NFC URI record instead and have the phone fetch the BIP70
> payment request via Bluetooth afterwards. Using this approach the amount of data
> is small enough that it's usually 'all or nothing' and that seems more robust to
> me.
>
> That said, I continue to have problems with the NFC stack that I'm using, so it
> might just be my NFC setup that is causing these problems. I will probably give
> the NXP NFC library a try next (which I believe is also the stack that is used
> by Android). Maybe I have more luck with that approach and could then switch to
> scenario 5.
>
> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is
> the non-standard extension of Andreas' wallet that I was mentioning. TBIP75
> proposes to change 'bt' into 'r1' as part of a more generic approach of
> numbering different sources for the BIP70 payment request. I think that is a
> good idea and would express my vote for this proposal. So the QR code or NFC URI
> would then look something like this:
>
> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource
>
> In addition the payment request would need to list additional 'payment_url's. My
> proposal would be to do something like this:
>
> message PaymentDetails {
> ...
> optional string payment_url = 6;
> optional bytes merchant_data = 7;
> repeated string additional_payment_urls = 8;
> // ^-- new; to hold things like 'bt:1234567890AB'
> }
>
> TBIP75 proposes to just change 'optional string payment_url' into 'repeated
> string payment_url'. If this isn't causing any problems (and hopefully not too
> much confusion?) I guess that would be fine too.
>
> In my opinion a wallet should then actually attempt all or multiple of the
> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via
> both HTTP and Bluetooth) and go with whatever completes first. But that is of
> course up to each wallet to decide how to handle.
>
> TBIP75 furthermore proposes to include an additional 'h' parameter which would
> be a hash of the BIP70 payment request, preventing a MITM attack on the
> Bluetooth channel even if the BIP70 payment request isn't signed. This would
> have also been my suggestion, although I know that Mike Hearn has raised
> concerns about this approach. One being, that one needs to finalize the BIP70
> payment request at the time the QR code and NFC URI is generated.
>
>
> ## Questions ##
>
> My questions to the list:
>
> 1) Do you prefer changing 'optional string payment_url' into 'repeated string
> payment_url' or would you rather introduce a new field 'additional_payment_urls'?
>
> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?
>
> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>
> 4) General comments, advice, feedback?
>
> I appreciate your input! :-)
>
> Cheers,
> Jan
>
> [1] http://andyschroder.com/BitcoinFluidDispenser/
> [2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/0c4aac73/attachment.sig>

2023-06-07 17:31:07 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:On 02/23/2015 03:11 PM, Mike Hearn wrote:
>> I don't see how you propose to treat the bitcoin address as a
>> secp256k1 public key, or do you mean something else?
>
> Sorry, I skipped a step. I shouldn't make assumptions about what's
> obvious.
No problem, we don't all have the same context. I may have missed prior
discussion.
> The server would provide the public key and the client would
> convert it to address form then match against the URI it has scanned.
> If it didn't match, stop at that point.
Does this not also require the BT publication of the script for a P2SH
address?
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/d33deef7/attachment.sig>

2023-06-07 17:31:06 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:Mike,
Before addressing other issues I could use some clarification on your
intent.
In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):
> doing ECDH over secp256k1 to derive a session key means we can reuse
> the address that was put in the URI already for pre-BIP70 wallets
In another statement you refer to derivation of a session key from a
public key (passed via BT):
> The public key can then be provided in full in the clear over the
> Bluetooth connection and the session key derived.
I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?
e
On 02/23/2015 02:58 AM, Mike Hearn wrote:
> DHKE will not improve the situation. Either we use a simple method to
> transfer a session key or a complex method.
>
> You're right that just sending the session key is simpler. I originally
> suggested doing ECDHE to set up an encrypted channel for the following
> reasons:
>
> 1. URIs are put in QR codes more often than NFC tags. QR codes have
> limited space. The more stuff you pack into them, the slower and
> flakier the scanning process becomes.
>
> For normal wallets, doing ECDH over secp256k1 to derive a session
> key means we can reuse the address that was put in the URI already
> for pre-BIP70 wallets, thus we don't have to expand the URI at all
> except perhaps to flag that crypted Bluetooth connections are
> supported. Win!
>
> 2. If the wallet is a watching wallet, this won't work and in that case
> you would need to put a separate key into the URI. However, this key
> is ephemeral and does not need to be very strong. So we can generate
> a regular secp256k1 key and then put say 5-8 prefix bytes into the
> URI as a new parameter. The public key can then be provided in full
> in the clear over the Bluetooth connection and the session key
> derived. If we put the session key into the URI in full, then we
> could not use this trick. Win!
>
> 3. It's quite common in low tech scenarios like little coffee shops to
> just print a QR code and put it in the menu, or sticky tape it to
> the back wall of the shop.
>
> In these cases, it's possible that the device is actually hanging
> around in the shop somewhere but having the QR code somewhere larger
> and more accessible than the shop devices screen is highly
> convenient. However it means the data is entirely static.
>
> Putting/reusing an identity key from the URI means the session keys
> are always unique and known only to both devices, even though the
> bootstrap data is public.
>
> 4. Doing ECDHE to derive the keys means we can derive a MAC key as well
> as an AES key. Otherwise you have the issue of exchanging both,
> which again uses up valuable bootstrap space.
>
> So for a small increase in session setup complexity we potentially avoid
> troubling problems down the line where people the same functionality
> from NFC and QR code based bootstrap, but we can't provide it.
>
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
>
> Re: the h= parameter. I only objected to requiring this when the payment
> request is also signed. It adds complexity, uses space, and the
> rationale was "the PKI can't be trusted" even though it's been used to
> protect credit card payments for 20 years without any issues. In the
> case of unsigned payment requests, sure ... but with a proper
> implementation of an encrypted Bluetooth channel it'd be unnecessary as
> the channel establishment process would guarantee authenticity anyway.
>
> But don't let me hold you guys back! I'd rather see something that works
> than an endless debate about the perfect arrangement of hashes and URI
> parameters :)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/ec6fbecf/attachment.sig>

2023-06-07 17:31:05 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:On 02/23/2015 01:49 AM, Andreas Schildbach wrote:
> I think at this point I'd like to bring back my original suggestion of
> using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
> transmit some secret that could be eavesdropped,
Hi Andreas,
DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.
> but at least the session could not be decrypted from recordings.
DHKE doesn't offer greater forward secrecy than private transfer of a
session key, in fact it's lesser.
> Anyway, establishing a "mostly secure" session is clearly an improvement
> to no protection at all. If we can't find a solution to the dilemma of
> how to exchange the secret, I suggest going ahead with what we have and
> make the best from it.
I don't see that there is a dilemma. The current proposal has a
significant privacy problem that can be easily resolved, and the
resolution actually makes the implementation simpler.
e
> On 02/23/2015 08:36 AM, Andy Schroder wrote:
>> I agree that NFC is the best we have as far as a trust anchor that you
>> are paying the right person. The thing I am worried about is the privacy
>> loss that could happen if there is someone passively monitoring the
>> connection. So, in response to some of your comments below and also in
>> response to some of Eric Voskuil's comments in another recent e-mail:
>>
>> Consider some cases:
>>
>> If NFC is assumed private, then sending the session key over the NFC
>> connection gives the payer and the payee assumed confidence that that a
>> private bluetooth connection can be created.
>>
>> If the NFC actually isn't private, then by sending the session key over
>> it means the bluetooth connection is not private. An eavesdropper can
>> listen to all communication and possibly modify the communication, but
>> the payer and payee won't necessarily know if eavesdropping occurs
>> unless communication is also modified (which could be difficult to do
>> for a really low range communication).
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> unmodified but actually monitored by an eavesdropper) and use that
>> public key received via NFC to encrypt a session key and send it back
>> via bluetooth, to then initiate an encrypted bluetooth connection using
>> that session key for the remaining communication, then the payee still
>> receives payment as expected and the payer sends the payment they
>> expected, and the eavesdropper doesn't see anything.
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> actually modified by an eavesdropper) and use that public key received
>> via NFC to encrypt a session key and send it back via bluetooth, to then
>> initiate an encrypted bluetooth connection using that session key for
>> the remaining communication, then the payee receives no payment and the
>> attack is quickly identified because the customer receives no product
>> for their payment and they notify the payee, and hopefully the problem
>> remedied and no further customers are affected. The privacy loss will be
>> significantly reduced and the motive for such attacks will be reduced.
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays to
>> each party (without them knowing or any glitches detected), but I guess
>> I'm not sure how easy that would be on such a close proximity device?
>>
>> Erick Voskuil mentioned this same problem would even occur if you had a
>> hardwired connection to the payment terminal and those wires were
>> compromised. I guess I still think what I am saying would be better in
>> that case. There is also more obvious physical tampering required to
>> mess with wires.
>>
>> I'm not sure if there is any trust anchor required of the payer by the
>> payee, is there? Eric also mentioned a need for this. Why does the payer
>> care who they are as long as they get a payment received? Just to avoid
>> a sophisticated modification" that I mention above? I can see how this
>> could be the case for a longer range communication (like over the
>> internet), but I'm not convinced it will be easy on really short ranges?
>> It's almost like the attacker would be better off to just replace the
>> entire POS internals than mess with an attack like that, in which case
>> everything we could do locally (other than the payment request signing
>> using PKI), is useless.
>>
>> I'm not a cryptography expert so I apologize if there is something
>> rudimentary that I am missing here.
>>
>> Andy Schroder
>>
>> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>>> I guess we need to decide whether we want to consider NFC communication
>>>> private or not. I don't know that I think it can be. An eavesdropper can
>>>> place a tiny snooping device near and read the communication. If it is
>>>> just passive, then the merchant/operator won't realize it's there. So, I
>>>> don't know if I like your idea (mentioned in your other reply) of
>>>> putting the session key in the URL is a good idea?
>>> I think the "trust by proximity" is the best we've got. If we don't
>>> trust the NFC link (or the QR code scan), what other options have we
>>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>>> as well of course.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/9e32d1cc/attachment.sig>

2023-06-07 17:31:02 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:On 02/22/2015 11:36 PM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection.
We have the same objective. Privacy loss is my primary concern with the
existing proposal.
> So, in response to some of your comments below and also in
> response to some of Eric Voskuil's comments in another recent e-mail:
>
> Consider some cases:
>
> If NFC is assumed private, then sending the session key over the NFC
> connection gives the payer and the payee assumed confidence that that a
> private bluetooth connection can be created.
>
> If the NFC actually isn't private, then by sending the session key over
> it means the bluetooth connection is not private. An eavesdropper can
> listen to all communication and possibly modify the communication, but
> the payer and payee won't necessarily know if eavesdropping occurs
> unless communication is also modified (which could be difficult to do
> for a really low range communication).
I realize you are postulating a situation where an interloper monitors
but doesn't substitute the NFC communication. But clearly if you can do
one you have the potential to do the other, so if one is going to rely
on the assumption that the NFC tap can be monitored one must also accept
that it can be modified. Once one accepts this premise there is no point
in using NFC.
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> unmodified but actually monitored by an eavesdropper) and use that
> public key received via NFC to encrypt a session key and send it back
> via bluetooth, to then initiate an encrypted bluetooth connection using
> that session key for the remaining communication, then the payee still
> receives payment as expected and the payer sends the payment they
> expected, and the eavesdropper doesn't see anything.
You can send a public cert over a public channel but before it can be
used it must be validated and verified to belong to the party that you
intend to communicate with privately. Otherwise the interloper can
substitute a public cert and subvert the payment process.
The reduces to the system requiring PKI just to establish private
communication. One might argue that BIP-70 already contemplates PKI.
However the above approach is significantly different in that it would
*require* all NFC/BT communication to use PKI just to be private.
Furthermore, to establish a private channel between *both* intended
parities, public certs must be exchanged in both directions. Otherwise,
if the customer isn't validated by the merchant, a distant interloper
can trivially use the merchant's public cert to obtain the payment
request from the Bluetooth terminal. This is the privacy breach that we
are trying to prevent in the first place.
Any requirement for PKI, in either direction, itself creates privacy
problems. But a requirement for customer certificates really gets hairy.
The PKI requirement can be dropped by instead exchanging self-generated
public keys, in the RedPhone model. However that requires out-of-band
secure communication of a common derived value by the parties. This
could be as simple as a number on each screen that one or both of the
parties compares. But this requires no private communication, and
therefore NFC is entirely unnecessary. This is in fact what I would
recommend for the BT-only scenario.
The value added by NFC is that proximity can be used to establish trust.
If that does not meet one's threshold for privacy then the parties need
to establish this trust through some presumably more private channel
(such as visual or voice confirmation).
Note that payment integrity can be reasonably ensured by relying on PKI
as established by BIP-70 (which also offers the seller non-repudiation
benefit). So this question is strictly about privacy.
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> actually modified by an eavesdropper) and use that public key received
> via NFC to encrypt a session key and send it back via bluetooth, to then
> initiate an encrypted bluetooth connection using that session key for
> the remaining communication, then the payee receives no payment and the
> attack is quickly identified because the customer receives no product
> for their payment and they notify the payee, and hopefully the problem
> remedied and no further customers are affected.
In this case the attacker hijacks the subsequent BT connection, sends a
payment request and gets paid. The only thing to prevent it would be
BIP-70/PKI, as mentioned above.
In a more complex attack the interloper can sit in the middle of all
communications between payer and receiver. Since the payer is not
validated by the receiver the interloper can impersonate the payer in
all communication with the receiver. As such he can also impersonate the
receiver in all communications with the payer. If the NFC communication
is compromized there is no saving privacy without an alternate private
channel.
> The privacy loss will be
> significantly reduced and the motive for such attacks will be reduced.
The motive and privacy loss remain unchanged.
> It's possible a really sophisticated modification could be done where
> the attacker encrypts and decrypts the communication and then relays to
> each party (without them knowing or any glitches detected), but I guess
> I'm not sure how easy that would be on such a close proximity device?
If the NFC tap is sufficiently private, privacy is easy to achieve for
the subsequent communication. If it is not, privacy can be completely
compromised. The question is only how much more difficult is the attack.
With the public cert tap, the level of difficulty is much lower for
capturing selected payment requests. The interloper no longer needs to
invade the space of the NFC terminal and can instead impersonate the
payer from a safe distance. Nobody gets paid, but privacy is compromised.
The level of difficulty in the case where the interloper wants to taint
transactions may appear lower, but it is not:
With the session key tap the interloper must compromise the NFC location
and then monitor the BT traffic. Monitoring BT traffic without being
party to the connection is presumably not rocket surgery, but not
standard BT design either.
With the public cert tap the interloper must also compromise the NFC
location and communicate over BT. Therefore the hardware and physical
attack requirements are similar. The only added difficulty is that the
attack on the NFC terminal attack is active (modifying the MAC address
directing the payer to the BT service).
However impersonating the payer is just a matter of software - no more
difficult than the session key attack. In fact it may be much easier to
implement, as the attack can use supported BT features because the
attacker has directed the payer to connect to him and is connecting to
the receiver as if he was a payer.
But it gets worse for the public cert tap, since a more sophisticated
attacker can set himself up in the same position without subverting the
NFC terminal at all. By broadcasting a more powerful BT service on the
same advertised MAC address, the attacker can capture traffic and relay
it to the intended service.
So in sum, reliance on a public cert makes the communication less
private under the same physical set of constraints. The difference
results from the receiver allowing non-proximate payers to impersonate
proximate payers from a distance by generating their own session keys
and submitting them over BT.
> Erick Voskuil mentioned this same problem would even occur if you had a
> hardwired connection to the payment terminal and those wires were
> compromised. I guess I still think what I am saying would be better in
> that case. There is also more obvious physical tampering required to
> mess with wires.
Attacks against wires do not require tampering with (as in damaging)
wires. The distinction between a wired connection and a wireless
connection is in many ways imaginary.
> I'm not sure if there is any trust anchor required of the payer by the
> payee, is there? Eric also mentioned a need for this. Why does the payer
> care who they are as long as they get a payment received? Just to avoid
> a sophisticated modification" that I mention above? I can see how this
> could be the case for a longer range communication (like over the
> internet), but I'm not convinced it will be easy on really short ranges?
I think I addressed this above but let me know if not.
> It's almost like the attacker would be better off to just replace the
> entire POS internals than mess with an attack like that, in which case
> everything we could do locally (other than the payment request signing
> using PKI), is useless.
Yes, ultimately both endpoints must be secured. My point is that (when
intended) NFC is practically the equivalent of a wired connection.
Baseband attacks against buyers' phones or subversion of the entire POS
terminal may be easier than interloping on a monitored NFC terminal. But
that's the point, once the attack is easier at the endpoints that is
where it will go. Further attempts to secure the gap between the devices
will not help after that point.
> I'm not a cryptography expert so I apologize if there is something
> rudimentary that I am missing here.
No need for apology, it's a good discussion, and there are precious few
experts here.
This discussion should make people very wary of any terminal system that
doesn't use signed payment requests :).
e
> Andy Schroder
>
> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>> I guess we need to decide whether we want to consider NFC communication
>>> private or not. I don't know that I think it can be. An eavesdropper can
>>> place a tiny snooping device near and read the communication. If it is
>>> just passive, then the merchant/operator won't realize it's there. So, I
>>> don't know if I like your idea (mentioned in your other reply) of
>>> putting the session key in the URL is a good idea?
>> I think the "trust by proximity" is the best we've got. If we don't
>> trust the NFC link (or the QR code scan), what other options have we
>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>> as well of course.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/e131bcbc/attachment.sig>

2023-06-07 17:31:00 CEST

- reply

📅 Original date posted:2015-02-22
📝 Original message:On 02/22/2015 03:32 PM, Andy Schroder wrote:
> On 02/22/2015 06:06 PM, Eric Voskuil wrote:
>> On 02/22/2015 02:37 PM, Andy Schroder wrote:
>>> I'd like to see some discussion too about securing the bluetooth
>>> connection. Right now it is possible for an eavesdropper to monitor the
>>> data transferred.
>> Yes, this should be a prerequisite issue to all others.
>>
>>> I'd personally like to see if wrapping the current
>>> connection with SSL works or if we can run https over a bluetooth
>>> socket.
>> There is no reason to add this significant complexity. The purpose of
>> SSL/TLS is to establish privacy over a *public* channel. But to do so
>> requires verification by the user of the merchant's public certificate.
>> Once we rely on the channel being *private*, the entire SSL process is
>> unnecessary.
>
>
> I guess we need to decide whether we want to consider NFC communication
> private or not. I don't know that I think it can be.
If the NFC communication is not private then there is no reason to use it.
> An eavesdropper can
> place a tiny snooping device near and read the communication. If it is
> just passive, then the merchant/operator won't realize it's there.
See my comments on an unmonitored terminal.
> So, I
> don't know if I like your idea (mentioned in your other reply) of
> putting the session key in the URL is a good idea?
My point is that you are not solving that problem by creating a more
complex system. Either you establish trust via proximity or you don't.
If you don't, it's a public network. If you do, then keep it simple.
There's nothing holy about a session key in this scenario. It's not
derived from long-lived keys and is itself used only once. There is
nothing wrong with the URL carrying the secret. If you want to secure
this channel without manual intervention, there is ultimately no other
option.
>> Presumably we would not want to require PKI for privacy, since that's a
>> bit of a contradiction. But if one wants to do this NFC is not required,
>> since the private session can be established over the public (Bluetooth)
>> network.
>>
>>> There was some criticism of this, but I don't think it has been
>>> tested to know if it is really a problem or not. If we just run https
>>> over bluetooth, then a lot of my concerns about the message header
>>> inconsistencies will go away and the connection will also be secure. We
>>> don't have to reinvent anything.
>>>
>>>
>>>
>>> Andy Schroder
>>>
>>> On 02/22/2015 02:08 PM, Jan Vornberger wrote:
>>>> Hi everyone,
>>>>
>>>> I am working on a Bitcoin point of sale terminal based on a Raspberry
>>>> Pi, which
>>>> displays QR codes, but also provides payment requests via NFC. It can
>>>> optionally
>>>> receive the sender's transaction via Bluetooth, so if the sender wallet
>>>> supports it, the sender can be completely offline. Only the terminal
>>>> needs an
>>>> internet connection.
>>>>
>>>> Typical scenario envisioned: Customer taps their smartphone (or maybe
>>>> smartwatch
>>>> in the future) on the NFC pad, confirms the transaction on their phone
>>>> (or smartwatch) and the transaction completes via Bluetooth and/or the
>>>> phone's
>>>> internet connection.
>>>>
>>>> You can see a prototype in action here:
>>>>
>>>> https://www.youtube.com/watch?v=P7vKHMoapr8
>>>>
>>>> The above demo uses a release version of Schildbach's Bitcoin Wallet,
>>>> so it
>>>> works as shown today. However, some parts - especially the Bluetooth
>>>> stuff - are
>>>> custom extensions of Schildbach's wallet which are not yet standard.
>>>>
>>>> I'm writing this post to document my experience implementing NFC and
>>>> offline
>>>> payments and hope to move the discussion forward around standardizing
>>>> some of
>>>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser
>>>> [1,2]
>>>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75
>>>> [4] are
>>>> relevant here as well.
>>>>
>>>>
>>>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>>>
>>>> Before I get into the implementation details, a few words for why I
>>>> decided to
>>>> go with the combination of NFC and Bluetooth:
>>>>
>>>> Doing everything via NFC is an interesting option to keep things
>>>> simple, but the
>>>> issue is, that one usually can't maintain the connection while the
>>>> user confirms
>>>> the transaction (as they take the device back to press a button or
>>>> maybe enter a
>>>> PIN). So there are three options:
>>>>
>>>> 1. Do a "double tap": User taps, takes the device back, confirms, then
>>>> taps
>>>> again to transmit the transaction. (I think Google Wallet does
>>>> something like
>>>> this.)
>>>>
>>>> 2. Confirm beforehand: User confirms, then taps and everything can
>>>> happen in one
>>>> go. The disadvantage is, that you confirm the transaction before you
>>>> have seen
>>>> the details. (I believe Google Wallet can also work this way.)
>>>>
>>>> 3. Tap the phone, then establish a Bluetooth connection which allows
>>>> you to do
>>>> all necessary communication even if the user takes the device back.
>>>>
>>>> I feel that option 3 is the nicest UX, so that is what I am focusing
>>>> on right
>>>> now, but there are pros and cons to all options. One disadvantage of
>>>> option 3 in
>>>> practice is, that many users - in my experience - have Bluetooth
>>>> turned off, so
>>>> it can result in additional UI dialogs popping up, asking the user to
>>>> turn on
>>>> Bluetooth.
>>>>
>>>> Regarding doing everything via Bluetooth or maybe BLE: I have been
>>>> following the
>>>> work that Airbitz has done around that, but personally I prefer the NFC
>>>> interaction of "I touch what I want to pay" rather than "a payment
>>>> request comes
>>>> to me through the air and I figure out whether it is meant for me/is
>>>> legitimate".
>>>>
>>>>
>>>> ## NFC data formats ##
>>>>
>>>> A bit of background for those who are not that familiar with NFC: Most
>>>> Bitcoin
>>>> wallets with NFC support make use of NDEF (NFC Data Exchange Format)
>>>> as far as I
>>>> am aware (with CoinBlesk being an exception, which uses host-based card
>>>> emulation, if I understand it correctly). NDEF defines a number of
>>>> record types,
>>>> among them 'URI' and 'Mime Type'.
>>>>
>>>> A common way of using NFC with Bitcoin is to create a URI record that
>>>> contains a
>>>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also
>>>> support
>>>> the mime type record, which is then set to
>>>> 'application/bitcoin-paymentrequest'
>>>> and the rest of the NFC data is a complete BIP70 payment request.
>>>>
>>>>
>>>> ## Implementation ##
>>>>
>>>> To structure the discussion a little bit, I have listed a number of
>>>> scenarios to
>>>> consider below. Not every possible combination is listed, but it
>>>> should cover a
>>>> bit of everything.
>>>>
>>>> Scenarios:
>>>>
>>>> 1) Scan QR code, transmit transaction via Bitcoin network
>>>> Example QR code: bitcoin:1asdf...?amount=42
>>>>
>>>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>>>> Example NFC URI: bitcoin:1asdf...?amount=42
>>>>
>>>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via
>>>> HTTP
>>>> Example QR code:
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>>
>>>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via
>>>> HTTP
>>>> Example NFC URI:
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>>>
>>>> 5) Touch NFC pad, receive BIP70 details directly, post transaction via
>>>> HTTP
>>>> Example NFC MIME record: application/bitcoin-paymentrequest +
>>>> BIP70 payment request
>>>>
>>>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction
>>>> via Bluetooth
>>>> Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>>
>>>> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction
>>>> via Bluetooth
>>>> Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
>>>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>>>
>>>> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I
>>>> am just
>>>> listing them here for comparison. Scenario 3 is what is often in use
>>>> now, for
>>>> example when using a checkout screen by BitPay or Coinbase.
>>>>
>>>> I played around with both scenarios 4 and 5, trying to decide whether
>>>> I should
>>>> use an NFC URI record or already provide the complete BIP70 payment
>>>> request via
>>>> NFC.
>>>>
>>>> My experience here has been, that the latter was fairly fragile in my
>>>> setup
>>>> (Raspberry Pi, NFC dongle from a company called Sensor ID, using
>>>> nfcpy). I tried
>>>> with signed payment requests that were around 4k to 5k and the
>>>> transfer would
>>>> often not complete if I didn't hold the phone perfectly in place. So I
>>>> quickly
>>>> switched to using the NFC URI record instead and have the phone fetch
>>>> the BIP70
>>>> payment request via Bluetooth afterwards. Using this approach the
>>>> amount of data
>>>> is small enough that it's usually 'all or nothing' and that seems more
>>>> robust to
>>>> me.
>>>>
>>>> That said, I continue to have problems with the NFC stack that I'm
>>>> using, so it
>>>> might just be my NFC setup that is causing these problems. I will
>>>> probably give
>>>> the NXP NFC library a try next (which I believe is also the stack that
>>>> is used
>>>> by Android). Maybe I have more luck with that approach and could then
>>>> switch to
>>>> scenario 5.
>>>>
>>>> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt'
>>>> parameter is
>>>> the non-standard extension of Andreas' wallet that I was mentioning.
>>>> TBIP75
>>>> proposes to change 'bt' into 'r1' as part of a more generic approach of
>>>> numbering different sources for the BIP70 payment request. I think
>>>> that is a
>>>> good idea and would express my vote for this proposal. So the QR code
>>>> or NFC URI
>>>> would then look something like this:
>>>>
>>>>
>>>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource
>>>>
>>>>
>>>>
>>>> In addition the payment request would need to list additional
>>>> 'payment_url's. My
>>>> proposal would be to do something like this:
>>>>
>>>> message PaymentDetails {
>>>> ...
>>>> optional string payment_url = 6;
>>>> optional bytes merchant_data = 7;
>>>> repeated string additional_payment_urls = 8;
>>>> // ^-- new; to hold things like 'bt:1234567890AB'
>>>> }
>>>>
>>>> TBIP75 proposes to just change 'optional string payment_url' into
>>>> 'repeated
>>>> string payment_url'. If this isn't causing any problems (and hopefully
>>>> not too
>>>> much confusion?) I guess that would be fine too.
>>>>
>>>> In my opinion a wallet should then actually attempt all or multiple of
>>>> the
>>>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment
>>>> request via
>>>> both HTTP and Bluetooth) and go with whatever completes first. But
>>>> that is of
>>>> course up to each wallet to decide how to handle.
>>>>
>>>> TBIP75 furthermore proposes to include an additional 'h' parameter
>>>> which would
>>>> be a hash of the BIP70 payment request, preventing a MITM attack on the
>>>> Bluetooth channel even if the BIP70 payment request isn't signed. This
>>>> would
>>>> have also been my suggestion, although I know that Mike Hearn has
>>>> raised
>>>> concerns about this approach. One being, that one needs to finalize
>>>> the BIP70
>>>> payment request at the time the QR code and NFC URI is generated.
>>>>
>>>>
>>>> ## Questions ##
>>>>
>>>> My questions to the list:
>>>>
>>>> 1) Do you prefer changing 'optional string payment_url' into 'repeated
>>>> string
>>>> payment_url' or would you rather introduce a new field
>>>> 'additional_payment_urls'?
>>>>
>>>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin
>>>> Wallet?
>>>>
>>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>>>
>>>> 4) General comments, advice, feedback?
>>>>
>>>> I appreciate your input! :-)
>>>>
>>>> Cheers,
>>>> Jan
>>>>
>>>> [1] http://andyschroder.com/BitcoinFluidDispenser/
>>>> [2]
>>>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>>>
>>>>
>>>> [3]
>>>> https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>>>> [4]
>>>> https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and
>>>> Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations,
>>>> FREE
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>>>
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/9abdde55/attachment.sig>

2023-06-07 17:30:59 CEST

- reply

📅 Original date posted:2015-02-22
📝 Original message:On 02/22/2015 02:37 PM, Andy Schroder wrote:
> I'd like to see some discussion too about securing the bluetooth
> connection. Right now it is possible for an eavesdropper to monitor the
> data transferred.
Yes, this should be a prerequisite issue to all others.
> I'd personally like to see if wrapping the current
> connection with SSL works or if we can run https over a bluetooth
> socket.
There is no reason to add this significant complexity. The purpose of
SSL/TLS is to establish privacy over a *public* channel. But to do so
requires verification by the user of the merchant's public certificate.
Once we rely on the channel being *private*, the entire SSL process is
unnecessary.
Presumably we would not want to require PKI for privacy, since that's a
bit of a contradiction. But if one wants to do this NFC is not required,
since the private session can be established over the public (Bluetooth)
network.
> There was some criticism of this, but I don't think it has been
> tested to know if it is really a problem or not. If we just run https
> over bluetooth, then a lot of my concerns about the message header
> inconsistencies will go away and the connection will also be secure. We
> don't have to reinvent anything.
>
>
>
> Andy Schroder
>
> On 02/22/2015 02:08 PM, Jan Vornberger wrote:
>> Hi everyone,
>>
>> I am working on a Bitcoin point of sale terminal based on a Raspberry
>> Pi, which
>> displays QR codes, but also provides payment requests via NFC. It can
>> optionally
>> receive the sender's transaction via Bluetooth, so if the sender wallet
>> supports it, the sender can be completely offline. Only the terminal
>> needs an
>> internet connection.
>>
>> Typical scenario envisioned: Customer taps their smartphone (or maybe
>> smartwatch
>> in the future) on the NFC pad, confirms the transaction on their phone
>> (or smartwatch) and the transaction completes via Bluetooth and/or the
>> phone's
>> internet connection.
>>
>> You can see a prototype in action here:
>>
>> https://www.youtube.com/watch?v=P7vKHMoapr8
>>
>> The above demo uses a release version of Schildbach's Bitcoin Wallet,
>> so it
>> works as shown today. However, some parts - especially the Bluetooth
>> stuff - are
>> custom extensions of Schildbach's wallet which are not yet standard.
>>
>> I'm writing this post to document my experience implementing NFC and
>> offline
>> payments and hope to move the discussion forward around standardizing
>> some of
>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75
>> [4] are
>> relevant here as well.
>>
>>
>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>
>> Before I get into the implementation details, a few words for why I
>> decided to
>> go with the combination of NFC and Bluetooth:
>>
>> Doing everything via NFC is an interesting option to keep things
>> simple, but the
>> issue is, that one usually can't maintain the connection while the
>> user confirms
>> the transaction (as they take the device back to press a button or
>> maybe enter a
>> PIN). So there are three options:
>>
>> 1. Do a "double tap": User taps, takes the device back, confirms, then
>> taps
>> again to transmit the transaction. (I think Google Wallet does
>> something like
>> this.)
>>
>> 2. Confirm beforehand: User confirms, then taps and everything can
>> happen in one
>> go. The disadvantage is, that you confirm the transaction before you
>> have seen
>> the details. (I believe Google Wallet can also work this way.)
>>
>> 3. Tap the phone, then establish a Bluetooth connection which allows
>> you to do
>> all necessary communication even if the user takes the device back.
>>
>> I feel that option 3 is the nicest UX, so that is what I am focusing
>> on right
>> now, but there are pros and cons to all options. One disadvantage of
>> option 3 in
>> practice is, that many users - in my experience - have Bluetooth
>> turned off, so
>> it can result in additional UI dialogs popping up, asking the user to
>> turn on
>> Bluetooth.
>>
>> Regarding doing everything via Bluetooth or maybe BLE: I have been
>> following the
>> work that Airbitz has done around that, but personally I prefer the NFC
>> interaction of "I touch what I want to pay" rather than "a payment
>> request comes
>> to me through the air and I figure out whether it is meant for me/is
>> legitimate".
>>
>>
>> ## NFC data formats ##
>>
>> A bit of background for those who are not that familiar with NFC: Most
>> Bitcoin
>> wallets with NFC support make use of NDEF (NFC Data Exchange Format)
>> as far as I
>> am aware (with CoinBlesk being an exception, which uses host-based card
>> emulation, if I understand it correctly). NDEF defines a number of
>> record types,
>> among them 'URI' and 'Mime Type'.
>>
>> A common way of using NFC with Bitcoin is to create a URI record that
>> contains a
>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also
>> support
>> the mime type record, which is then set to
>> 'application/bitcoin-paymentrequest'
>> and the rest of the NFC data is a complete BIP70 payment request.
>>
>>
>> ## Implementation ##
>>
>> To structure the discussion a little bit, I have listed a number of
>> scenarios to
>> consider below. Not every possible combination is listed, but it
>> should cover a
>> bit of everything.
>>
>> Scenarios:
>>
>> 1) Scan QR code, transmit transaction via Bitcoin network
>> Example QR code: bitcoin:1asdf...?amount=42
>>
>> 2) Touch NFC pad, transmit transaction via Bitcoin network
>> Example NFC URI: bitcoin:1asdf...?amount=42
>>
>> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
>> Example QR code:
>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>
>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
>> Example NFC URI:
>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest
>>
>> 5) Touch NFC pad, receive BIP70 details directly, post transaction via
>> HTTP
>> Example NFC MIME record: application/bitcoin-paymentrequest +
>> BIP70 payment request
>>
>> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction
>> via Bluetooth
>> Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>
>> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction
>> via Bluetooth
>> Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
>> Payment request has 'payment_url' set to 'bt:1234567890AB'
>>
>> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I
>> am just
>> listing them here for comparison. Scenario 3 is what is often in use
>> now, for
>> example when using a checkout screen by BitPay or Coinbase.
>>
>> I played around with both scenarios 4 and 5, trying to decide whether
>> I should
>> use an NFC URI record or already provide the complete BIP70 payment
>> request via
>> NFC.
>>
>> My experience here has been, that the latter was fairly fragile in my
>> setup
>> (Raspberry Pi, NFC dongle from a company called Sensor ID, using
>> nfcpy). I tried
>> with signed payment requests that were around 4k to 5k and the
>> transfer would
>> often not complete if I didn't hold the phone perfectly in place. So I
>> quickly
>> switched to using the NFC URI record instead and have the phone fetch
>> the BIP70
>> payment request via Bluetooth afterwards. Using this approach the
>> amount of data
>> is small enough that it's usually 'all or nothing' and that seems more
>> robust to
>> me.
>>
>> That said, I continue to have problems with the NFC stack that I'm
>> using, so it
>> might just be my NFC setup that is causing these problems. I will
>> probably give
>> the NXP NFC library a try next (which I believe is also the stack that
>> is used
>> by Android). Maybe I have more luck with that approach and could then
>> switch to
>> scenario 5.
>>
>> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt'
>> parameter is
>> the non-standard extension of Andreas' wallet that I was mentioning.
>> TBIP75
>> proposes to change 'bt' into 'r1' as part of a more generic approach of
>> numbering different sources for the BIP70 payment request. I think
>> that is a
>> good idea and would express my vote for this proposal. So the QR code
>> or NFC URI
>> would then look something like this:
>>
>>
>> bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource
>>
>>
>> In addition the payment request would need to list additional
>> 'payment_url's. My
>> proposal would be to do something like this:
>>
>> message PaymentDetails {
>> ...
>> optional string payment_url = 6;
>> optional bytes merchant_data = 7;
>> repeated string additional_payment_urls = 8;
>> // ^-- new; to hold things like 'bt:1234567890AB'
>> }
>>
>> TBIP75 proposes to just change 'optional string payment_url' into
>> 'repeated
>> string payment_url'. If this isn't causing any problems (and hopefully
>> not too
>> much confusion?) I guess that would be fine too.
>>
>> In my opinion a wallet should then actually attempt all or multiple of
>> the
>> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment
>> request via
>> both HTTP and Bluetooth) and go with whatever completes first. But
>> that is of
>> course up to each wallet to decide how to handle.
>>
>> TBIP75 furthermore proposes to include an additional 'h' parameter
>> which would
>> be a hash of the BIP70 payment request, preventing a MITM attack on the
>> Bluetooth channel even if the BIP70 payment request isn't signed. This
>> would
>> have also been my suggestion, although I know that Mike Hearn has raised
>> concerns about this approach. One being, that one needs to finalize
>> the BIP70
>> payment request at the time the QR code and NFC URI is generated.
>>
>>
>> ## Questions ##
>>
>> My questions to the list:
>>
>> 1) Do you prefer changing 'optional string payment_url' into 'repeated
>> string
>> payment_url' or would you rather introduce a new field
>> 'additional_payment_urls'?
>>
>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin
>> Wallet?
>>
>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>
>> 4) General comments, advice, feedback?
>>
>> I appreciate your input! :-)
>>
>> Cheers,
>> Jan
>>
>> [1] http://andyschroder.com/BitcoinFluidDispenser/
>> [2]
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>
>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>
>> ------------------------------------------------------------------------------
>>
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/a3e8cdc2/attachment.sig>

2023-06-07 17:30:01 CEST

- reply

📅 Original date posted:2015-02-10
📝 Original message:On 02/10/2015 02:41 AM, Natanael wrote:
> Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak"
> <martin.habovstiak at gmail.com <mailto:martin.habovstiak at gmail.com>>:
>>
>> Why would anyone want to do anything about payment before choosing
>> what he wants to buy and for what price? I've never used Amazon but
>> isn't filling a form with shipping information enough?
>
> That's not what this is about.
>
> BIP70 isn't just payment, it is about communication the terms of the sale.
Hi Natanael,
BIP70 exists for seller non-repudiation (i.e. a cryptographically signed
receipt for payment) and establishing strong seller identity in a
face-to-face or other non-web scenario (since TLS doesn't help).
Anything else is incidental.
> Let's say you're visiting an international webshop. But they don't ship
> to your country. Wouldn't you want to know that before your start
> filling the cart? With this, your wallet / browser extension could tell
> you right away that you can't shop there. No time wasted!
>
> That's just one requirement of many where you would benefit from being
> told right away if it is acceptable for both parties or not.
There's quite a bit that can be done with wallets and web sites, but
personally I'd freak out if my wallet prompted me because I visited a
web site.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/dcdd1b2d/attachment.sig>

2023-06-07 17:29:47 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
> That's exactly what I though when seeing the RedPhone code, but after
> I studied the commit protocol I realized it's actually secure and
> convenient way to do it. You should do that too. :)
I was analyzing the model as you described it to me. A formal analysis
of the security model of a particular implementation, based on inference
from source code, is a bit beyond what I signed up for. But I'm
perfectly willing to comment on your description of the model if you are
willing to indulge me.
> Shortly, how it works:
> The initiator of the connection sends commit message containing the
> hash of his temporary public ECDH part, second party sends back their
> public ECDH part and then initiator sends his public ECDH part in
> open. All three messages are hashed together and the first two bytes
> are used to select two words from a shared dictionary which are
> displayed on the screen of both the initiator and the second party.
> The parties communicate those two words and verify they match.
How do they compare words if they haven't yet established a secure channel?
> If an attacker wants to do MITM, he has a chance of choosing right
> public parts 1:65536. There is no way to brute-force it, since that
> would be noticed immediately. If instead of two words based on the
> first two bytes, four words from BIP39 wordlist were chosen, it would
> provide entropy of 44 bits which I believe should be enough even for
> paranoid people.
>
> How this would work in Bitcoin payment scenario: user's phone
> broadcasts his name, merchant inputs amount and selects the name from
> the list, commit message is sent (and then the remaining two
> messages), merchant spells four words he sees on the screen and buyer
> confirms transaction after verifying that words match.
So the assumption is that there exists a secure (as in proximity-based)
communication channel?
e
> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>> A BIP-70 signed payment request in the initial broadcast can resolve the
>>>> integrity issues, but because of the public nature of the broadcast
>>>> coupled with strong public identity, the privacy compromise is much
>>>> worse. Now transactions are cryptographically tainted.
>>>>
>>>> This is also the problem with BIP-70 over the web. TLS and other
>>>> security precautions aside, an interloper on the communication, desktop,
>>>> datacenter, etc., can capture payment requests and strongly correlate
>>>> transactions to identities in an automated manner. The payment request
>>>> must be kept private between the parties, and that's hard to do.
>>>
>>> What about using encryption with forward secrecy? Merchant would
>>> generate signed request containing public ECDH part, buyer would send
>>> back transaction encrypted with ECDH and his public ECDH part. If
>>> receiving address/amount is meant to be private, use commit protocol
>>> (see ZRTP/RedPhone) and short authentication phrase (which is hard to
>>> spoof thanks to commit protocol - see RedPhone)?
>>
>> Hi Martin,
>>
>> The problem is that you need to verify the ownership of the public key.
>> A MITM can substitute the key. If you don't have verifiable identity
>> associated with the public key (PKI/WoT), you need a shared secret (such
>> as a secret phrase). But the problem is then establishing that secret
>> over a public channel.
>>
>> You can bootstrap a private session over the untrusted network using a
>> trusted public key (PKI/WoT). But the presumption is that you are
>> already doing this over the web (using TLS). That process is subject to
>> attack at the CA. WoT is not subject to a CA attack, because it's
>> decentralized. But it's also not sufficiently deployed for some scenarios.
>>
>> e
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/bcba6fb2/attachment.sig>

2023-06-07 17:29:41 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:Yes, a stellar device for mass surveillance coupled with transaction tainting.
e
> On Feb 5, 2015, at 1:19 PM, Brian Hoffman <brianchoffman at gmail.com> wrote:
>
> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little.
>
>
> On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike at plan99.net> wrote:
>
>>> I'm imagining myself walking around broadcasting my photo and MAC
>>> address while hucksters push payment requests to me for approval
>>
>> I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;)
>>
>> Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC.
>>
>> "Payment spam" might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/98dcee87/attachment.html>

2023-06-07 17:29:40 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:On 02/05/2015 12:28 PM, Mike Hearn wrote:
> The donation to live performer example is good - there's no issue of
> accidentally paying for someone else in this context as there's only one
> recipient, but many senders.
I'm not sure you could assume this, even if the payer only received one
broadcast. And if the payer receives multiple, it constitutes a DOS on
the scenario, potentially unintentional.
> The issue of confused payments remains in other situations though.
Agree, the problem of the payer strongly identifying the receiver
requires either proximity (NFC or QR code scan from the known-good
source) or PKI/WoT. The problem can't be resolved through a broadcast.
> For the coffee shop use case, it'd be nicer (I think) if we aim for a
> Square-style UI where the device broadcasts a (link to) a photo of the
> user combined with a bluetooth MAC. Then the merchant tablet can show
> faces of people in the shop, and can push a payment request to the users
> device. That device can then buzz the user, show a confirmation screen,
> put something on their smart watch etc or just auto-authorise the
> payment because the BIP70 signature is from a trusted merchant. User
> never even needs to touch their phone at all.
I'm imagining myself walking around broadcasting my photo and MAC
address while hucksters push payment requests to me for approval, while
recording my photo and correlating it to my address. It will pretty
quickly turn in to a scenario where I need to touch something before
this is turned on.
> On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul at airbitz.co
> <mailto:paul at airbitz.co>> wrote:
>
> The BIP70 protocol would preclude individuals from utilizing the P2P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable
> payment w/o internet by first transferring the URI to from Recipient
> to Sender. Then in the future, we could sign a Tx and send it over
> BLE back to the recipient (who would still need internet to verify
> the Tx). This is an important use case for areas with poor 3G/4G
> connectivity as I've experience myself.
>
> Also, due to Android issues, NFC is incredibly clunky. The URI
> Sender is required to tap the screen *while* the two phones are in
> contact. We support NFC the same way Bitcoin Wallet does, but unless
> the payment recipient has a custom Android device (which a merchant
> might) then the usage model is worse than scanning a QR code. BLE
> also allows people to pay at a distance such as for a donation to a
> live performer. We'll look at adding this to the Motivation section.
>
> From: Andreas Schildbach <andreas at sc...> - 2015-02-05 13:47:04
>
> Thanks Paul, for writing up your protocol!
>
> First thoughts:
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead. URIs mainly stick around because
> of QR codes limited capacity. BIP70 would partly address the "copycat"
> problem by signing payment requests.
>
> In your Motivation section, I miss some words about NFC. NFC already
> addresses all of the usability issues mentioned and is supported by
> mobile wallets since 2011. That doesn't mean your method doesn't make
> sense in some situations, but I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/829bd26c/attachment.sig>

2023-06-07 17:29:17 CEST

- reply

📅 Original date posted:2015-02-02
📝 Original message:Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise.
> On Feb 2, 2015, at 11:35 AM, Brian Erdelyi <brian.erdelyi at gmail.com> wrote:
>
>
>> Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly.
>>
>> It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile.
>>
>> It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app.
>
> I really like the concept of Bitcoin Authenticator and think it’s exactly what I was describing (without a third-party).
>
> I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. I think it may be more accurate to describe it as out of band transaction verification/signing or dual transaction signing. Regardless, it’s very exciting to see others are thinking about this too.
>
> Brian Erdelyi
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development