* Re: [bitcoin-dev] Is Bitcoin mempool synchronized?
@ 2020-07-01 0:53 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-01 0:53 UTC (permalink / raw)
To: Hilda, Bitcoin Protocol Discussion
Good morning Hilda,
> Hi there,
>
> I have been assuming Bitcoin system to be well synchronized, including mempools. But after being challenged, I started to think that I actually cannot verify this without knocking the door of every miner in every single second (just a time slice reasonable to me; stop torturing me by asking why). Can anyone share any thoughts with me?
No, definitely not.
There is no good way to limit the amount of transactions someone can push at you, except by various heuristics.
Yet those very same heuristics mean that someone with a good knowledge of those heuristics can make your mempool desynchronized with that of somebody else.
Fortunately for Bitcoin, it is the blockchain itself that we synchronize on.
People cannot push blocks at you without doing the work of grinding towards the difficulty target, thus it is not possible to spam blocks.
TANSTAAGM - There Ain't No Such Thing As A Global Mempool
For this reason, any consensus rule has to refer only to data inside blocks, and never to data in mempools, are mempools are ephemeral and not synchronized across all nodes.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
@ 2020-07-01 16:58 99% ` ZmnSCPxj
2020-07-02 12:22 99% ` Tejaswi Nadahalli
2020-07-02 12:39 99% ` Tejaswi Nadahalli
0 siblings, 2 replies; 47+ results
From: ZmnSCPxj @ 2020-07-01 16:58 UTC (permalink / raw)
To: Tejaswi Nadahalli
Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
Good morning Tejaswi,
> Hello ZmnSCPxj (as there would be no better way to start an email to you :-),
>
> I posted a reply to Dave in the other sub-thread of this main thread. We have a paper about something similar to what you have said - where we look at "weak" and "strong" miners, and how even if there are a few weak miners, they have a dominating strategy, etc.
>
By my reading, it seems to me that you divide miners into "weak" and "powerful".
Weak miners have lower hashrate than powerful ones.
The dividing point depends on how much Alice and Bob fees are.
If the hashrate share of a miner is less than the ratio of Alice (honest) fee to Bob (bribing) fee, then the miner is weak.
And your paper posits that if a miner is weak, its best strategy is to take the myopic strategy and include the currently-valid Alice transaction.
Thus, if Alice even *matches* Bob, it seems to me that this ratio f / b is 1.0 implying a miner can only be powerful if it has already 51%-attacked Bitcoin (which tends to invalidate all our security assumptions of higher-layer protocols anyway, since a 51% attacker can censor anything with impunity).
Of course, Bob can offer up to the entire fund amount, for free, to miners as a bribe, without loss to Bob.
For more realistic scenarios where no miner has 100% hashrate, then Alice can make all miners weak by being willing to pay up to 50% of the fund as fee, as a miner that achieves greater than 50% hashrate share would already effectively pwnzored Bitcoin and gained UNLIMITED POWAH anyway.
So it looks to me that scorched-earth is a possible mitigation against this attack.
--
Another analysis, similar but a little off-tangent to yours, would be to consider miners as a breeding group with various strategies, and see which one is able to gain more utilons (with which it creates more miners) and outbreed the other miners.
This models the fact that miners can use their earnings to reinvest into their mining operations and increase their mining hashrate, and the amount they can reinvest is proportional to their earnings.
A miner that "gives birth" to a child miner with the same strategy is, in the so-called "real world", simply a miner that has earned enough and reinvested those earnings to double the hashrate of their business (which, logically speaking, would use the same strategy throughout the entire business).
Let us start with a population of 4 miners, 3 of which follow the non-myopic strategy, and the remaining following the myopic strategy.
Let us postulate that all miners have the same unit hashrate.
Thus, this starting population is 75% non-myopic, 25% myopic.
If there exists a timelocked bribe, then if non-myopic miner is chosen at a block, it will have to sacrifice the Alice fee minus whatever lesser transaction fee it can replace in its block.
If the Alice transaction is successfully delayed until the Bob transaction is valid, then the non-myopic miners can get the Bob transaction confirmed.
However, even in the case that the Alice transaction is delayed, the myopic miner still has its 25% chance --- equal to the 25% chance of the three non-myopic miners --- to confirm the Bob transaction and earn the increased bribe that Bob offers.
Thus, the non-myopic miners can end up sacrificing fee earnings, and in the end the myopic miner still has the 25% chance to get the Bob transaction fee later when it becomes valid.
So the non-myopic miners do not impose any loss on myopic miners.
On the other hand, if the non-myopic miners sacrificed their chances to include the Alice transaction in the hope of getting the later 25% chance to get the Bob higher-fee timelocked transaction, and then the myopic miner gets the next block, the myopic miner gets the Alice transaction confirmed and the 25% chance to get the Bob higher fee is lost by the non-myopic miners.
Thus, the myopic miner is able to impose costs on their non-myopic competitors.
So even if by chance for the entire locktime, only the non-myopic miners are selected, the myopic miner still retains its 25% chance of getting the block at locktime + 1 and confirming and earning the bigger Bob fee.
Thus, we expect that the myopic miner will earn more than 25% of subsidies and fees than the non-myopic miners, in such a mixed environment.
We can then consider that the myopic miner, being able to earn more, is able to increase its progeny (i.e. expand its mining business and inspire new miners to follow its strategy towards success) faster than the non-myopic miners.
We can thus conclude that the myopic miners will eventually dominate over the breeding population and drive the non-myopic miners to near-extinction.
It is helpful to remember that rationality is about success *in the universe you exist in*.
While miners may step back and consider that, ***if*** all of them were to use non-myopic strategy, they would all earn more, the fact of the matter is that each miner works for themselves, and themselves alone, in a highly competitive environment.
Thus, even though they know *all of them* will benefit if they use the non-myopic strategy, they cannot be sure, unless they are all perfectly synchronized mind-clones of each other, that the other miners will rather be selfish and mine for themselves, even if in the end every miner earns less
The standard for success is to earn more *than your competitors*, not ensure that *every* miner earns more.
Fortunately, since miners are running a business, this competition leads to better services to the the customers of the mining business, a known phenomenon of the free market, yay free market greed is good.
The user Alice is a customer of the mining business.
Alice gets, as a side effect of this competitiveness of miners (which leads to miners adopting myopic strategies in order to gain an edge over non-myopic miners), improved security of their HTLCs without requiring slashable fidelity bonds or such-like that MAD-HTLC proposes.
Using this model, it seems to me that non-myopic miners can only maintain hold over the blockchain if all miners agree to use non-myopic strategy.
This is basically all miners forming a cartel / monopoly, which we know is detrimental to customers of the monopoly, and is the reason why we prefer decentralization.
Regards,
ZmnSCPxj
> On Mon, Jun 29, 2020 at 8:05 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > Good morning Dave, et al.,
> >
> > > > Myopic Miners: This bribery attack relies on all miners
> > > >
> > > >
> > > > being rational, hence considering their utility at game conclu-
> > > > sion instead of myopically optimizing for the next block. If
> > > > a portion of the miners are myopic and any of them gets to
> > > > create a block during the first T − 1 rounds, that miner would
> > > > include Alice’s transaction and Bob’s bribery attempt would
> > > > have failed.
> > > > In such scenarios the attack succeeds only with a certain
> > > > probability – only if a myopic miner does not create a block
> > > > in the first T − 1 rounds. The success probability therefore
> > > > decreases exponentially in T . Hence, to incentivize miners
> > > > to support the attack, Bob has to increase his offered bribe
> > > > exponentially in T .
> > >
> > > This is a good abstract description, but I think it might be useful for
> > > readers of this list who are wondering about the impact of this attack
> > > to put it in concrete terms. I'm bad at statistics, but I think the
> > > probability of bribery failing (even if Bob offers a bribe with an
> > > appropriately high feerate) is 1-exp(-b*h) where `b` is the number of
> > > blocks until timeout and `h` is a percentage of the hashrate controlled
> > > by so-called myopic miners. Given that, here's a table of attack
> > > failure probabilities:
> > >
> > > "Myopic" hashrate
> > > B 1% 10% 33% 50%
> > > l +---------------------------------
> > > o 6 | 5.82% 45.12% 86.19% 95.02%
> > > c 36 | 30.23% 97.27% 100.00% 100.00%
> > > k 144 | 76.31% 100.00% 100.00% 100.00%
> > > s 288 | 94.39% 100.00% 100.00% 100.00%
> > >
> > > So, if I understand correctly, even a small amount of "myopic" hashrate
> > > and long timeouts---or modest amounts of hashrate and short
> > > timeouts---makes this attack unlikely to succeed (and, even in the cases
> > > where it does succeed, Bob will have to offer a very large bribe to
> > > compensate "rational" miners for their high chance of losing out on
> > > gaining any transaction fees).
> > >
> > > Additionally, I think there's the problem of measuring the distribution
> > > of "myopic" hashrate versus "rational" hashrate. "Rational" miners need
> > > to do this in order to ensure they only accept Bob's timelocked bribe if
> > > it pays a sufficiently high fee. However, different miners who try to
> > > track what bribes were relayed versus what transactions got mined may
> > > come to different conclusions about the relative hashrate of "myopic"
> > > miners, leading some of them to require higher bribes, which may lead
> > > those those who estimated a lower relative hash rate to assume the rate
> > > of "myopic" mining in increasing, producing a feedback loop that makes
> > > other miners think the rate of "myopic" miners is increasing. (And that
> > > assumes none of the miners is deliberately juking the stats to mislead
> > > its competitors into leaving money on the table.)
> >
> > A thought occurs to me, that we should not be so hasty to call non-myopic strategy "rational".
> > Let us consider instead "myopic" and "non-myopic" strategies in a population of miners.
> >
> > I contend that in a mixed population of "myopic" and "non-myopic" miners, the myopic strategy is dominant in the game-theoretic sense, i.e. it might earn less if all miners were myopic, but if most miners were non-myopic and a small sub-population were myopic and there was no easy way for non-myopic miners to punish myopic miners, then the myopic miners will end up earning more (at the expense of the non-myopic miners) and dominate over non-myopic miners.
> > Such dominant result should prevent non-myopic miners from arising in the first place.
> >
> > The dominance results from the fact that by accepting the Alice transaction, myopic miners are effectively deducting the fees earned by non-myopic miners by preventing the Bob transaction from being confirmable.
> > On the other hand, even if the non-myopic miners successfully defer the Alice transaction, the myopic miner still has a chance equal to its hashrate of getting the Bob transaction and its attached fee.
> > Thus, myopic miners impose costs on their non-myopic competitors that non-myopic miners cannot impose their myopic competitors.
> > If even one myopic miner successfully gets the Alice transaction confirmed, all the non-myopic miners lose out on the Bob bribe fee.
> >
> > So I think the myopic strategy will be dominant and non-myopic miners will not arise in the first place.
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-01 16:58 99% ` ZmnSCPxj
@ 2020-07-02 12:22 99% ` Tejaswi Nadahalli
2020-07-02 16:06 99% ` ZmnSCPxj
2020-07-02 12:39 99% ` Tejaswi Nadahalli
1 sibling, 1 reply; 47+ results
From: Tejaswi Nadahalli @ 2020-07-02 12:22 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> And your paper posits that if a miner is weak, its best strategy is to
> take the myopic strategy and include the currently-valid Alice transaction.
>
Yes. The proof is quite trivial and follows from the definition of weak: if
the myopic miner's hashpower percentage is p_i, and it's lower than f/b,
that means that f > b*p_i. By including the currently-valid Alice
transaction, the myopic miner could make f, which is higher than their
expected gain, which is b*p_i. The myopic miner has a p_i chance of mining
the first block when Bob's transaction becomes valid, and it's most likely
to stay valid for just 1 block, as every miner would want that immediately
when it gets valid. This is where we disagree with the MAD-HTLC paper. They
assume that there are not any miners with sub-1% hashrate around. We find
that there are many such miners, and with channel_reserve_satoshi set to 1%
of the channel value, Alice can bump her fees to at least 1% of the channel
value without worry (because she will get Bob's channel_reserve_satoshi's
for herself if Bob is cheating by releasing a previous commitment TXN).
We additionally also show that when strong miners know that weak miners are
around, some of their strategies get dominated as well, and they will be
forced to include Alice's transaction as well. This, if there is just one
*known* weak miner, things are good for Alice. As an FYI, in our paper
Alice is the cheater and Bob is the victim. There were reasons to "reverse
the convention", so to speak - but that's for another day :-)
>
> Thus, if Alice even *matches* Bob, it seems to me that this ratio f / b is
> 1.0 implying a miner can only be powerful if it has already 51%-attacked
> Bitcoin (which tends to invalidate all our security assumptions of
> higher-layer protocols anyway, since a 51% attacker can censor anything
> with impunity).
>
We assume that Bob will bribe with the entire channel value - because he
has received commensurate goods and services off-chain. So, Alice will find
it difficult to match Bob's bribe, but she doesn't have to.
>
> Of course, Bob can offer up to the entire fund amount, for free, to miners
> as a bribe, without loss to Bob.
>
Yes. Precisely.
>
> For more realistic scenarios where no miner has 100% hashrate, then Alice
> can make all miners weak by being willing to pay up to 50% of the fund as
> fee, as a miner that achieves greater than 50% hashrate share would already
> effectively pwnzored Bitcoin and gained UNLIMITED POWAH anyway.
>
But she doesn't have to go as far as 50%. Just 1% seems quite reasonable,
given a reasonable timelock. We have a closed form solution for the
timelock T as well. In Lightning's case, with 1% channel_reserve_satoshis
around, we arrive at T = 316, which is much longer than the current default
of 144.
>
> So it looks to me that scorched-earth is a possible mitigation against
> this attack.
>
I don't follow this. We show that a reasonable value of fees and timelock
are enough to avoid the attack. Why scorch the earth?
[-- Attachment #2: Type: text/html, Size: 4163 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-01 16:58 99% ` ZmnSCPxj
2020-07-02 12:22 99% ` Tejaswi Nadahalli
@ 2020-07-02 12:39 99% ` Tejaswi Nadahalli
1 sibling, 0 replies; 47+ results
From: Tejaswi Nadahalli @ 2020-07-02 12:39 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
[-- Attachment #1: Type: text/plain, Size: 5935 bytes --]
On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Another analysis, similar but a little off-tangent to yours, would be to
> consider miners as a breeding group with various strategies, and see which
> one is able to gain more utilons (with which it creates more miners) and
> outbreed the other miners.
>
> This models the fact that miners can use their earnings to reinvest into
> their mining operations and increase their mining hashrate, and the amount
> they can reinvest is proportional to their earnings.
> A miner that "gives birth" to a child miner with the same strategy is, in
> the so-called "real world", simply a miner that has earned enough and
> reinvested those earnings to double the hashrate of their business (which,
> logically speaking, would use the same strategy throughout the entire
> business).
>
> Let us start with a population of 4 miners, 3 of which follow the
> non-myopic strategy, and the remaining following the myopic strategy.
> Let us postulate that all miners have the same unit hashrate.
> Thus, this starting population is 75% non-myopic, 25% myopic.
>
> If there exists a timelocked bribe, then if non-myopic miner is chosen at
> a block, it will have to sacrifice the Alice fee minus whatever lesser
> transaction fee it can replace in its block.
> If the Alice transaction is successfully delayed until the Bob transaction
> is valid, then the non-myopic miners can get the Bob transaction confirmed.
>
> However, even in the case that the Alice transaction is delayed, the
> myopic miner still has its 25% chance --- equal to the 25% chance of the
> three non-myopic miners --- to confirm the Bob transaction and earn the
> increased bribe that Bob offers.
>
> Thus, the non-myopic miners can end up sacrificing fee earnings, and in
> the end the myopic miner still has the 25% chance to get the Bob
> transaction fee later when it becomes valid.
> So the non-myopic miners do not impose any loss on myopic miners.
>
> On the other hand, if the non-myopic miners sacrificed their chances to
> include the Alice transaction in the hope of getting the later 25% chance
> to get the Bob higher-fee timelocked transaction, and then the myopic miner
> gets the next block, the myopic miner gets the Alice transaction confirmed
> and the 25% chance to get the Bob higher fee is lost by the non-myopic
> miners.
> Thus, the myopic miner is able to impose costs on their non-myopic
> competitors.
>
> So even if by chance for the entire locktime, only the non-myopic miners
> are selected, the myopic miner still retains its 25% chance of getting the
> block at locktime + 1 and confirming and earning the bigger Bob fee.
>
> Thus, we expect that the myopic miner will earn more than 25% of subsidies
> and fees than the non-myopic miners, in such a mixed environment.
>
This is exactly our analysis, and is covered in section 2.5 of our paper.
We formalize the ideas a bit more, and are able to relate the values of
Alice-fee, Bob-bribe, timelock, and miner's hashpower percentage. We go a
bit further into #reckless territory as well - reducing the timelock value
to super low values. That's in Algorithm #1 of our paper, and is a bit more
involved.
>
> We can then consider that the myopic miner, being able to earn more, is
> able to increase its progeny (i.e. expand its mining business and inspire
> new miners to follow its strategy towards success) faster than the
> non-myopic miners.
>
> We can thus conclude that the myopic miners will eventually dominate over
> the breeding population and drive the non-myopic miners to near-extinction.
>
This is an interesting direction that we chose to not look at. Like the
MAD-HTLC authors, we assume a constant hash-rate distribution across time,
which is obviously not a great assumption. It might work in the local
context of an HTLC's timelock, but in our approach, we are also interested
in *weak* miners, and finding them across 1000's of blocks might get tricky.
> It is helpful to remember that rationality is about success *in the
> universe you exist in*.
> While miners may step back and consider that, ***if*** all of them were to
> use non-myopic strategy, they would all earn more, the fact of the matter
> is that each miner works for themselves, and themselves alone, in a highly
> competitive environment.
> Thus, even though they know *all of them* will benefit if they use the
> non-myopic strategy, they cannot be sure, unless they are all perfectly
> synchronized mind-clones of each other, that the other miners will rather
> be selfish and mine for themselves, even if in the end every miner earns
> less
> The standard for success is to earn more *than your competitors*, not
> ensure that *every* miner earns more.
>
> Fortunately, since miners are running a business, this competition leads
> to better services to the the customers of the mining business, a known
> phenomenon of the free market, yay free market greed is good.
> The user Alice is a customer of the mining business.
> Alice gets, as a side effect of this competitiveness of miners (which
> leads to miners adopting myopic strategies in order to gain an edge over
> non-myopic miners), improved security of their HTLCs without requiring
> slashable fidelity bonds or such-like that MAD-HTLC proposes.
>
Yes. And in the context of Lightning, both Alice and Bob need to have
fidelity bonds, which triples the already bad channel-lockin cost.
> Using this model, it seems to me that non-myopic miners can only maintain
> hold over the blockchain if all miners agree to use non-myopic strategy.
> This is basically all miners forming a cartel / monopoly, which we know is
> detrimental to customers of the monopoly, and is the reason why we prefer
> decentralization.
>
If miners form a cartel and get to 51%, we are all doomed anyway.
Thanks for the detailed reply. And apologies for splitting my email into
two parts.
[-- Attachment #2: Type: text/html, Size: 6804 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Tool for checking a wallet's handling of reverted 0-conf transactions
@ 2020-07-02 13:51 99% Oded Leiba
0 siblings, 0 replies; 47+ results
From: Oded Leiba @ 2020-07-02 13:51 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
As was disclosed today, several wallets have been found not to handle well
the scenario of reverted transactions at zero confirmations. This includes
showing an increased balance to the user without decreasing it when a
transaction is replaced and also preventing the user from being able to
spend other valid coins.
You can test the behavior of your own wallet (either that you use or
develop) and read more about it in this new tool:
https://github.com/KZen-networks/big-spender
Oded
[-- Attachment #2: Type: text/html, Size: 642 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-02 12:22 99% ` Tejaswi Nadahalli
@ 2020-07-02 16:06 99% ` ZmnSCPxj
2020-07-03 9:43 99% ` Tejaswi Nadahalli
0 siblings, 1 reply; 47+ results
From: ZmnSCPxj @ 2020-07-02 16:06 UTC (permalink / raw)
To: Tejaswi Nadahalli
Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
Good morning Tejaswi,
> > So it looks to me that scorched-earth is a possible mitigation against this attack.
>
> I don't follow this. We show that a reasonable value of fees and timelock are enough to avoid the attack. Why scorch the earth?
Because your model only considers that a block might have only 0 or 1 transactions, and there is no such thing as a mempool containing alternative, fee-paying transactions that the miner could include *instead*.
In reality, what a miner can earn from adding Alice transaction is the *difference* between the Alice transaction fee and the transaction that *just* misses getting included in the block because of feerate.
Thus, the f will not, in fact, *quite* be the Alice fee, but instead less than that.
Indeed if the Alice transaction fee is lower than the top 4 Mweight transactions in the mempool, the miner would be *losing* funds by including the Alice transaction.
My understanding is that we expect mempools to eventually never empty, as the block subsidy reduces over time, thus the payoff f for including the Alice transaction *instead of* some other transaction will be less than the Alice fee.
This effect also holds for Bob, but we can probably expect, all things being equal, that approximately the same value will be deducted from both the Bob bribe and Alice fee by the mempool effect.
Thus the ratio should really be (f - x) / (b - x), where x is the fee-of-transaction-that-just-misses-the-block.
At fee spikes, this x will go higher, and thus (f - x) / (b - x) will be far smaller than f / b and might even become negative, in which case the Alice transaction will not be confirmed even by myopic miners, because the Alice transaction will be below the top 4Mweight transactions in the mempool.
So it seems to me reasonable to use a *gradual* scorched earth policy, as it is not only resilient against this attack, but also to fee spikes.
Alice starts at the 1% reserve, then for every block that goes by, bumps up the fee.
Then Alice will settle at an (f - x) / (b - x) level that achieves the least weak miner that is known to run the myopic strategy.
I believe this is also better for UX --- people already accept that during high fee spikes, they end up paying more for onchain activities.
But boosting up `to_self_delay` is bad because it makes honest unilateral closes take longer, and we already get frownie faces from users about this parameter.
By using a gradual scorched-earth strategy we can start at the reserve level, and if we are not under attack and there is no fee spike, do not lose anything other than the reserve funds of the thief (which is not ours, but is instead that of the thief).
But if an attack happens during a fee spike, then even though we retain our current default `to_self_delay` of 144, we still have the ability to gradually and automatically move to higher fee regions until our transaction confirms, and we have a good excuse for it to present to users: "a fee spike was happening at the time, so you had to pay some extra miner fees".
----
And since you and your paper openly discusses it anyway, I would like to reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
You make recommendations about `to_self_delay` and `channel_reserve_satoshis`, which are not parameters of Lightning HTLCs (those are stuff like `cltv_delta` and `final_cltv`), but are channel parameters.
The MAD-HTLC argument applies just as well to channel mechanisms themselves, ***independently of*** any HTLCs they transport.
The MAD-HTLC paper has the following core argument:
* We currently assume that currently-valid transactions will inevitably supersede alternate transactions that are valid at a later block height, simply because of the time advantage.
* However, the owner of a later-block-height transaction can bribe miners to defer confirmation of currently-valid transactions, until its later-block-height transaction is valid and confirms.
The above core argument is presented as applying to HTLCs.
However, the same argument actually **also** applies to all current offchain multiparticipant cryptocurrency systems (i.e. "channel mechanisms").
* Spilman
* Poon-Dryja (what we currently use in Lightning)
* Decker-Wattenhofer decrementing-`nSequence`
* Decker-Russell-Osuntokun
The [Khabbazian-Nadahalli-Wattenhofer "Timelocked Bribing" paper](https://eprint.iacr.org/2020/774.pdf) mentions the use of revoked transactions in a Poon-Dryja mechanism, but seems to imply that the issue is with the HTLC instantiated inside the revoked transaction.
But note that the paper describes recommendations for the `to_self_delay` parameter and also analyzes the `channel_reserve_satoshis` parameter, which are parameters of the ***Poon-Dryja*** mechanism, and **not** of the HTLCs instantiated inside it.
So, to be very clear, the MAD-HTLC argument applies to all the above mechanisms *even if HTLCs are not used at all*.
Or put another way, if you use a modern offchain updateable cryptocurrency system at all, you are still vulnerable to the MAD-HTLC argument even if you never instantiate HTLCs inside the offchain system.
Thus, other proposed systems that (could) use any of the channel mechanisms, but do ***not*** necessarily use HTLCs, such as CoinPools, channel factories, and statechains, are also vulnerable to the MAD-HTLC argument.
In particular, if the MAD-HTLC argument holds, we should take note that e.g. Lightning channels have to be at least as large as any HTLC they contain, and since the MAD-HTLC argument applies to the channel itself (in addition to any HTLCs they contain), the application of that argument implies greater loss, as it is the entire channel that is at risk, not just any HTLCs it might contain.
Spilman
=======
A Spilman channel is a unidirectional single-funded channel.
The overall idea was presented pre-SegWit, and needed `OP_CHECKLOCKTIMEVERIFY` to be malleation-safe.
I will describe here a modernized version that uses SegWit (and thus is malleation safe) instead.
Suppose Bob wishes to make a Spilman channel to Alice.
The setup is as follows:
* Bob creates but does *NOT* sign a funding transaction, paying out to a 2-of-2 between Alice and Bob, and hands over this txid and the output number to Alice.
* Alice creates a timeout transaction, `nLockTime`d to a pre-agreed locktime, spending the above txout, and returning the funds to Bob, and signs this transaction and hands over the signature and tx to Bob.
* Bob signs the funding transaction and broadcasts it.
* Alice and Bob wait for deep confirmation of the funding tx.
At each payment from Bob to Alice, Bob signs a non-`nLockTime`d (or one with current blockheight) transaction that spends the funding txout and assigns more of the fund to Alice, then sends the signature and tx to Alice.
At any time, Alice can unilaterally close the channel using any of the signatures given by Bob.
Rationally, it will publish the one that gives it the most money, which is the latest such transaction, thus leading to the unidirectional nature of Spilman channels.
Alice needs to perform this unilateral close far before the pre-agreed locktime.
Under the MAD-HTLC argument, Bob can bribe miners to ignore the Alice unilateral close transaction, and the initial timeout transaction by Bob gets confirmed even if within the channel mechanism Alice is supposed to own most or all of the funds.
Poon-Dryja
==========
A Poon-Dryja channel is a modern two-participant bidirectional channel.
The core of security of Poon-Dryja involves "revocable outputs".
A revocable output is an output that, when published onchain, is owned by one entity (the owner), but that entity may reveal a secret, the revocation secret, to another entity (the revoker).
Once that other entity knows the revocation secret, if the output is ever published onchain, it can revoke the output and claim its value.
Poon-Dryja uses this building block to implement an updateable state.
All states are represented by commitment transactions that have revocable outputs.
In order to advance to a new state, the revocable outputs of previous states are revoked by exchanging revocation secrets.
Thus, the security of Poon-Dryja is dependent on the correct operation of revocation.
Revocable outputs are implemented by imposing a relative locktime on the owner of the output, and requiring knowledge of two secrets from the revoker.
Thus, a revocable output has two branches:
* Revocation branch: with the revoker privkey and knowledge of a revocaation secret, the revoker can claim the fund immediately.
* Claim branch: with the owner privkey and a relative locktime, the owner can claim the fund after a pre-agreed number of blocks (`to_self_delay` in Lightning) since the output is confirmed onchain.
Under the MAD-HTLC argument, the owner of the revoked output can bribe miners to ignore attempts by the revoker to claim the funds until the claim branch is valid and confirmable.
Thus, a thief can publish old state, then apply the MAD-HTLC argument to get miners to ignore the revoker of the old state.
Decker-Wattenhofer decrementing-`nSequence`
===========================================
Decker-Wattenhofer ("Duplex Micropayment Channels") is a modern multi-participant (N >= 2) offchain updateable cryptocurrency mechanism.
Decker-Wattenhofer chains together two different mechanisms, embedding them one inside the other, in order to balance the tradeoffs of one with the tradeoffs of the other.
* One or more decrementing-`nSequence` mechanisms, chained one inside the other.
* Two ("duplex") unidirectional Spilman variants, using a relative locktime instead of an absolute locktime, one in both directions of the channel, inside the innermost decrementing-`nSequence` mechanism.
The decrementing-`nSequence` mechanisms by themselves are multiparticipant (N >= 2), and if we focus only on having one or more of these mechanisms chained together, we can consider Decker-Wattenhofer as multiparticipant.
In the decrementing-`nSequence` mechanism, there is a kickoff transaction which spends from the n-of-n funding outpoint, and sends it to yet another n-of-n output between the participants.
Then, the second n-of-n is spent by a transaction with a relative-locktime `nSequence` transaction, which then distributes the money among various participants.
When a new state is created, the participants create and sign a new relative-locktime `nSequence` transaction spending the kickoff n-of-n outpoint.
The new state transaction has a lower `nSequence` than the most previous state transaction, hence decrementing-`nSequence`.
Once the latest state transaction has a 0-block relative locktime, a newer state can no longer be added to the mechanism.
The kickoff n-of-n outpoint thus has multiple branches, one for each created state.
The most recent state is assumed to supersede previous states, because it has the smallest relative locktime among all states.
Under the MAD-HTLC argument, a participant which prefers an older state can bribe miners to defer confirmation of all more recent states.
Thus, that participant can publish the kickoff and bribe miners to defer more recent states until its preferred state is confirmable onchain.
Decker-Russell-Osuntokun
========================
Decker-Russell-Osuntokun ("eltoo") is a futuristic multiparticipant (N >= 2) offchain updateable cryptocurrency system.
Decker-Russell-Osuntokun uses a proposed new `SIGHASH_NOINPUT` flag, which does not commit to the specific output being spent, allowing a signature that signs using `SIGHASH_NOINPUT` to be used to spend a different transaction outpoint, as long as the same pubkey is used for that outpoint.
As is typical for channel mechanisms, a funding outpoint is created, which is an n-of-n of all participants.
The funding outpoint is spent by an update transaction with a single output, which has the following branches:
* Update branch: can be spent by the same n-of-n pubkeys as the funding outpoint, as long as the spending transaction has a higher `nLockTime` than the update transaction.
* State branch: can be spent by a different n-of-n pubkeys from the same participants, after a relative locktime.
* Each update transaction has its own unique set of n-of-n pubkeys for the state branch, given by the same participant set.
Of note is that the `nLockTime` used in Decker-Russell-Osuntokun are always past `nLockTime`s, so that the update branch is always confirmable at the current tip, from now until forever.
Only the state branch has an actual timelock that could prevent immediate confirmation of a transaction spending that branch.
Update transactions (awesomely mis)use `nLockTime` as a sequence number; the first update transaction has the lowest `nLockTime`, then each succeeding update transaction has a higher `nLockTime`, until they reach the present time.
Update transactions are signed with `SIGHASH_NOINPUT`.
This allows the update transaction to not only spend the funding outpoint itself, but also to spend any previous update transaction.
Thus, if an old update transaction is published onchain, its output can be re-spent by any newer update transaction before the state transaction for that update can come into play.
Any other participant who notices this event can simply publish the newest update transaction it knows, as that would supersede the state transaction, which can only be confirmed after a time delay.
Under the MAD-HTLC argument, a participant who prefers an older state can publish the update transaction for the older state, then bribe miners to defer confirmation of newer update transactions, until the state transaction for that update transaction can be confirmed.
Conclusion
==========
All the above mechanisms use a timelock, and implicitly have the assumption that "a transaction, that can be confirmed now, supersedes any transaction that has a timelock that forces it to be confirmed later".
It seems likely to me that even future mechanisms will use the same assumption as well.
In particular, many proposed mechanisms for non-federated sidechains often include some kind of delay between when a sidechain coin is burned and the corresponding mainchain coin is released (i.e. side-to-main peg).
Often, this delay exists in order to allow showing of a counterproof that the supposed side-to-main transfer did not actually exist in the sidechain (or was later reorged out, or whatever).
It seems to me that the MAD-HTLC argument would also apply to such mechanisms (if anyone still wants to go push sidechains, anyway).
Thus, we really need to carefully investigate the MAD-HTLC argument.
My current analysis suggests that in practice, the MAD-HTLC argument does not apply at all (else I would not be revealing that all channel mechanisms are broken **if** the MAD-HTLC argument *does* apply), since the myopic strategy seems to be pretty much inevitably dominant at stable states.
But it would still be best to investigate further until we are fully convinced that the MAD-HTLC argument ("'earlier supersedes later' might be falsified by bribery") does not apply.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP draft: BIP32 Path Templates
@ 2020-07-02 16:28 99% Dmitry Petukhov
2020-07-03 14:39 99% ` David A. Harding
0 siblings, 1 reply; 47+ results
From: Dmitry Petukhov @ 2020-07-02 16:28 UTC (permalink / raw)
To: bitcoin-dev
I think there should be standard format to describe constraints for
BIP32 paths.
I present a BIP draft that specifies "path templates" for BIP32 paths:
https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/bip-path-templates.mediawiki
Matching against these templates allow to easily discern 'valid'
paths, that match the constraints, and 'invalid' paths, that exceed the
constraints. Extended motivation is given at the end of this message,
and in the text of the BIP draft.
A formal spec in TLA+ of a finite state machine implementing the parser
for the described format (and the matching operation) accompanies this
BIP draft: https://github.com/dgpv/bip32_template_parse_tplaplus_spec
This formal spec can be used with TLC model checker and a helper script
to generate thorough test data for implementations.
One (python) implementation of template parsing and matching already
exists (linked in the BIP draft).
Examples of the templates:
"m/[44,49,84]'/0'/0'/[0-1]/[0-50000]" specifies a full template that
matches both external and internal chains of BIP44, BIP49 and BIP84
paths, with a constraint that the address index cannot be larger than
50000
"[0-2,33,123]/*" specifies a partial template that matches non-hardened
values 0, 1, 2, 33, 123 as first index, and any non-hardened value at
second index
"*h/0" specifies a partial template that matches any hardened index
followed by any non-hardened index
Motivation:
BIP32 derivation path format is universal, and a number of schemes for
derivation were proposed in BIP43 and other documents, such as BIPs
44,45,49,84. The flexibility of the format allowed industry
participants to implement custom derivation shemes that fit particular
purposes, but not necessarily useful in general.
Unrestricted derivation path usage might be unsafe in certain contexts.
In particular, when "change" outputs of a transaction are sent to the
addresses derived via paths unknown to the sender, the sender might
loose access to the whole change amount.
A simplistic approach of hard-coding the checks for well-known paths
into software and firmware leads to reduced interoperability. Vendors
cannot choose custom paths that are appropriate for their particular,
non-general-purpose applications, and are forced to shoehorn their
solutions into using well-known paths, or convince other vendors to
support their custom paths. This approach scales poorly.
A flexible approach proposed is to define a standard notation for
"BIP32 path templates" that succintly describes the constraints to
impose on the derivation path.
Wide support for these path templates will increase interoperability
and flexibility of solutions, and will allow vendors and individual
developers to easily define their own custom restrictions. This way,
they will be able to deal with the risks of accidental or malicious use
of unrestricted derivation paths in a more flexible and precise manner.
Well-known path templates can be pre-configured by default on devices
and applications, but users can have an option to turn off the
templates that are not relevant to their uses.
Having standardized format for custom path templates will enable a
common approach to be developed to the enforcement of
application-specific path restrictions in devices and applications. One
example of such approach might be for devices to allow to install
application-specific profiles with path templates and possibly other
custom parameters. Care must be taken to prevent accidental
installation of malicious or incorrect profile, though.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-02 16:06 99% ` ZmnSCPxj
@ 2020-07-03 9:43 99% ` Tejaswi Nadahalli
2020-07-03 10:16 99% ` ZmnSCPxj
0 siblings, 1 reply; 47+ results
From: Tejaswi Nadahalli @ 2020-07-03 9:43 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
[-- Attachment #1: Type: text/plain, Size: 19689 bytes --]
On Thu, Jul 2, 2020 at 6:06 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> At fee spikes, this x will go higher, and thus (f - x) / (b - x) will be
> far smaller than f / b and might even become negative, in which case the
> Alice transaction will not be confirmed even by myopic miners, because the
> Alice transaction will be below the top 4Mweight transactions in the
> mempool.
>
I agree. The MAD-HTLC authors actually keep the base fee in their
calculations, and we deliberately decided to ignore this. We believe that
this base fee to be much lower than the typical 1% channel balance, and it
actually doesn't change any of our results. This was brushed under the
"without loss of generality" rug. I admit that we should have made this
clear in our Assumptions section though. Point taken.
> But if an attack happens during a fee spike, then even though we retain
> our current default `to_self_delay` of 144, we still have the ability to
> gradually and automatically move to higher fee regions until our
> transaction confirms, and we have a good excuse for it to present to users:
> "a fee spike was happening at the time, so you had to pay some extra miner
> fees".
>
Agree on the UX. There is a tradeoff between the timelocked value of the
channel balance to Alice during benign vs malicious abandonment by Bob. In
your opinion, increasing the fees beyond 1% (and thereby cutting into
Alice's share itself) is a slightly better tradeoff than increasing
to_self_delay.
> And since you and your paper openly discusses it anyway, I would like to
> reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
>
We know. Maybe we should have made it clear in the paper that when we use
the Poon-Dryja channel construction, we use the idea that the knowledge of
the preimage of a hash is equivalent to knowing the private key of the
revocation public key. In fact, this is how the Poon-Dryja construction is
explained in McCorry's Ph.D thesis
<https://nms.kcl.ac.uk/patrick.mccorry/thesis.pdf>, and IMHO is easier to
understand than the original description in the Poon-Dryja paper (or Bolt
#3, for that matter).
You could further argue that the hashlock is an incidental artefact, and
our paper mostly refers to timelocked transactions. And the rest of your
email describes applications of timelocked (and obviously presigned)
transactions, which are all vulnerable to the same bribing attack.
Additionally, the Wattehnofer in our paper is the same Wattenhofer from the
Duplex Channel paper.
My current analysis suggests that in practice, the MAD-HTLC argument does
> not apply at all (else I would not be revealing that all channel mechanisms
> are broken **if** the MAD-HTLC argument *does* apply), since the myopic
> strategy seems to be pretty much inevitably dominant at stable states.
>
We agree.
> But it would still be best to investigate further until we are fully
> convinced that the MAD-HTLC argument ("'earlier supersedes later' might be
> falsified by bribery") does not apply.
>
I think this is the analysis our paper does, and perhaps it's our mistake
that we do not set the context better. We only mention (and propose fixes
for) Poon-Dryja channel construction, and Tier Nolan's Atomic Swap
construction.
We could have addressed Spilman's one-way channels or Decker-Wattenhofer
duplex channels, but that would have been pointless as they were never
going to make it into production after Poon-Dryja and subsequently, Eltoo
were proposed. But not addressing Eltoo in the paper is an omission that I
am a bit upset about. We additionally do not address more sophisticated
atomic swaps from Somsen or Fournier. Nor do we address Kanzure's vault
proposal. In fact, one rule of thumb might be that wherever watchtowers are
required, a timelocked bribe might be possible.
And again, thanks for the detailed analysis.
On Thu, Jul 2, 2020 at 6:06 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Tejaswi,
>
> > > So it looks to me that scorched-earth is a possible mitigation against
> this attack.
> >
> > I don't follow this. We show that a reasonable value of fees and
> timelock are enough to avoid the attack. Why scorch the earth?
>
> Because your model only considers that a block might have only 0 or 1
> transactions, and there is no such thing as a mempool containing
> alternative, fee-paying transactions that the miner could include *instead*.
>
> In reality, what a miner can earn from adding Alice transaction is the
> *difference* between the Alice transaction fee and the transaction that
> *just* misses getting included in the block because of feerate.
>
> Thus, the f will not, in fact, *quite* be the Alice fee, but instead less
> than that.
>
> Indeed if the Alice transaction fee is lower than the top 4 Mweight
> transactions in the mempool, the miner would be *losing* funds by including
> the Alice transaction.
>
> My understanding is that we expect mempools to eventually never empty, as
> the block subsidy reduces over time, thus the payoff f for including the
> Alice transaction *instead of* some other transaction will be less than the
> Alice fee.
>
>
> This effect also holds for Bob, but we can probably expect, all things
> being equal, that approximately the same value will be deducted from both
> the Bob bribe and Alice fee by the mempool effect.
> Thus the ratio should really be (f - x) / (b - x), where x is the
> fee-of-transaction-that-just-misses-the-block.
> At fee spikes, this x will go higher, and thus (f - x) / (b - x) will be
> far smaller than f / b and might even become negative, in which case the
> Alice transaction will not be confirmed even by myopic miners, because the
> Alice transaction will be below the top 4Mweight transactions in the
> mempool.
>
>
> So it seems to me reasonable to use a *gradual* scorched earth policy, as
> it is not only resilient against this attack, but also to fee spikes.
> Alice starts at the 1% reserve, then for every block that goes by, bumps
> up the fee.
> Then Alice will settle at an (f - x) / (b - x) level that achieves the
> least weak miner that is known to run the myopic strategy.
>
>
> I believe this is also better for UX --- people already accept that during
> high fee spikes, they end up paying more for onchain activities.
> But boosting up `to_self_delay` is bad because it makes honest unilateral
> closes take longer, and we already get frownie faces from users about this
> parameter.
> By using a gradual scorched-earth strategy we can start at the reserve
> level, and if we are not under attack and there is no fee spike, do not
> lose anything other than the reserve funds of the thief (which is not ours,
> but is instead that of the thief).
> But if an attack happens during a fee spike, then even though we retain
> our current default `to_self_delay` of 144, we still have the ability to
> gradually and automatically move to higher fee regions until our
> transaction confirms, and we have a good excuse for it to present to users:
> "a fee spike was happening at the time, so you had to pay some extra miner
> fees".
>
>
> ----
>
> And since you and your paper openly discusses it anyway, I would like to
> reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
> You make recommendations about `to_self_delay` and
> `channel_reserve_satoshis`, which are not parameters of Lightning HTLCs
> (those are stuff like `cltv_delta` and `final_cltv`), but are channel
> parameters.
>
> The MAD-HTLC argument applies just as well to channel mechanisms
> themselves, ***independently of*** any HTLCs they transport.
>
> The MAD-HTLC paper has the following core argument:
>
> * We currently assume that currently-valid transactions will inevitably
> supersede alternate transactions that are valid at a later block height,
> simply because of the time advantage.
> * However, the owner of a later-block-height transaction can bribe
> miners to defer confirmation of currently-valid transactions, until its
> later-block-height transaction is valid and confirms.
>
> The above core argument is presented as applying to HTLCs.
>
> However, the same argument actually **also** applies to all current
> offchain multiparticipant cryptocurrency systems (i.e. "channel
> mechanisms").
>
> * Spilman
> * Poon-Dryja (what we currently use in Lightning)
> * Decker-Wattenhofer decrementing-`nSequence`
> * Decker-Russell-Osuntokun
>
> The [Khabbazian-Nadahalli-Wattenhofer "Timelocked Bribing" paper](
> https://eprint.iacr.org/2020/774.pdf) mentions the use of revoked
> transactions in a Poon-Dryja mechanism, but seems to imply that the issue
> is with the HTLC instantiated inside the revoked transaction.
> But note that the paper describes recommendations for the `to_self_delay`
> parameter and also analyzes the `channel_reserve_satoshis` parameter, which
> are parameters of the ***Poon-Dryja*** mechanism, and **not** of the HTLCs
> instantiated inside it.
>
> So, to be very clear, the MAD-HTLC argument applies to all the above
> mechanisms *even if HTLCs are not used at all*.
> Or put another way, if you use a modern offchain updateable cryptocurrency
> system at all, you are still vulnerable to the MAD-HTLC argument even if
> you never instantiate HTLCs inside the offchain system.
>
> Thus, other proposed systems that (could) use any of the channel
> mechanisms, but do ***not*** necessarily use HTLCs, such as CoinPools,
> channel factories, and statechains, are also vulnerable to the MAD-HTLC
> argument.
>
> In particular, if the MAD-HTLC argument holds, we should take note that
> e.g. Lightning channels have to be at least as large as any HTLC they
> contain, and since the MAD-HTLC argument applies to the channel itself (in
> addition to any HTLCs they contain), the application of that argument
> implies greater loss, as it is the entire channel that is at risk, not just
> any HTLCs it might contain.
>
> Spilman
> =======
>
> A Spilman channel is a unidirectional single-funded channel.
>
> The overall idea was presented pre-SegWit, and needed
> `OP_CHECKLOCKTIMEVERIFY` to be malleation-safe.
> I will describe here a modernized version that uses SegWit (and thus is
> malleation safe) instead.
>
> Suppose Bob wishes to make a Spilman channel to Alice.
> The setup is as follows:
>
> * Bob creates but does *NOT* sign a funding transaction, paying out to a
> 2-of-2 between Alice and Bob, and hands over this txid and the output
> number to Alice.
> * Alice creates a timeout transaction, `nLockTime`d to a pre-agreed
> locktime, spending the above txout, and returning the funds to Bob, and
> signs this transaction and hands over the signature and tx to Bob.
> * Bob signs the funding transaction and broadcasts it.
> * Alice and Bob wait for deep confirmation of the funding tx.
>
> At each payment from Bob to Alice, Bob signs a non-`nLockTime`d (or one
> with current blockheight) transaction that spends the funding txout and
> assigns more of the fund to Alice, then sends the signature and tx to Alice.
>
> At any time, Alice can unilaterally close the channel using any of the
> signatures given by Bob.
> Rationally, it will publish the one that gives it the most money, which is
> the latest such transaction, thus leading to the unidirectional nature of
> Spilman channels.
> Alice needs to perform this unilateral close far before the pre-agreed
> locktime.
>
> Under the MAD-HTLC argument, Bob can bribe miners to ignore the Alice
> unilateral close transaction, and the initial timeout transaction by Bob
> gets confirmed even if within the channel mechanism Alice is supposed to
> own most or all of the funds.
>
> Poon-Dryja
> ==========
>
> A Poon-Dryja channel is a modern two-participant bidirectional channel.
>
> The core of security of Poon-Dryja involves "revocable outputs".
> A revocable output is an output that, when published onchain, is owned by
> one entity (the owner), but that entity may reveal a secret, the revocation
> secret, to another entity (the revoker).
> Once that other entity knows the revocation secret, if the output is ever
> published onchain, it can revoke the output and claim its value.
>
> Poon-Dryja uses this building block to implement an updateable state.
> All states are represented by commitment transactions that have revocable
> outputs.
> In order to advance to a new state, the revocable outputs of previous
> states are revoked by exchanging revocation secrets.
> Thus, the security of Poon-Dryja is dependent on the correct operation of
> revocation.
>
> Revocable outputs are implemented by imposing a relative locktime on the
> owner of the output, and requiring knowledge of two secrets from the
> revoker.
>
> Thus, a revocable output has two branches:
>
> * Revocation branch: with the revoker privkey and knowledge of a
> revocaation secret, the revoker can claim the fund immediately.
> * Claim branch: with the owner privkey and a relative locktime, the owner
> can claim the fund after a pre-agreed number of blocks (`to_self_delay` in
> Lightning) since the output is confirmed onchain.
>
> Under the MAD-HTLC argument, the owner of the revoked output can bribe
> miners to ignore attempts by the revoker to claim the funds until the claim
> branch is valid and confirmable.
> Thus, a thief can publish old state, then apply the MAD-HTLC argument to
> get miners to ignore the revoker of the old state.
>
> Decker-Wattenhofer decrementing-`nSequence`
> ===========================================
>
> Decker-Wattenhofer ("Duplex Micropayment Channels") is a modern
> multi-participant (N >= 2) offchain updateable cryptocurrency mechanism.
>
> Decker-Wattenhofer chains together two different mechanisms, embedding
> them one inside the other, in order to balance the tradeoffs of one with
> the tradeoffs of the other.
>
> * One or more decrementing-`nSequence` mechanisms, chained one inside the
> other.
> * Two ("duplex") unidirectional Spilman variants, using a relative
> locktime instead of an absolute locktime, one in both directions of the
> channel, inside the innermost decrementing-`nSequence` mechanism.
>
> The decrementing-`nSequence` mechanisms by themselves are multiparticipant
> (N >= 2), and if we focus only on having one or more of these mechanisms
> chained together, we can consider Decker-Wattenhofer as multiparticipant.
>
> In the decrementing-`nSequence` mechanism, there is a kickoff transaction
> which spends from the n-of-n funding outpoint, and sends it to yet another
> n-of-n output between the participants.
> Then, the second n-of-n is spent by a transaction with a relative-locktime
> `nSequence` transaction, which then distributes the money among various
> participants.
>
> When a new state is created, the participants create and sign a new
> relative-locktime `nSequence` transaction spending the kickoff n-of-n
> outpoint.
> The new state transaction has a lower `nSequence` than the most previous
> state transaction, hence decrementing-`nSequence`.
> Once the latest state transaction has a 0-block relative locktime, a newer
> state can no longer be added to the mechanism.
>
> The kickoff n-of-n outpoint thus has multiple branches, one for each
> created state.
> The most recent state is assumed to supersede previous states, because it
> has the smallest relative locktime among all states.
>
> Under the MAD-HTLC argument, a participant which prefers an older state
> can bribe miners to defer confirmation of all more recent states.
> Thus, that participant can publish the kickoff and bribe miners to defer
> more recent states until its preferred state is confirmable onchain.
>
> Decker-Russell-Osuntokun
> ========================
>
> Decker-Russell-Osuntokun ("eltoo") is a futuristic multiparticipant (N >=
> 2) offchain updateable cryptocurrency system.
>
> Decker-Russell-Osuntokun uses a proposed new `SIGHASH_NOINPUT` flag, which
> does not commit to the specific output being spent, allowing a signature
> that signs using `SIGHASH_NOINPUT` to be used to spend a different
> transaction outpoint, as long as the same pubkey is used for that outpoint.
>
> As is typical for channel mechanisms, a funding outpoint is created, which
> is an n-of-n of all participants.
> The funding outpoint is spent by an update transaction with a single
> output, which has the following branches:
>
> * Update branch: can be spent by the same n-of-n pubkeys as the funding
> outpoint, as long as the spending transaction has a higher `nLockTime` than
> the update transaction.
> * State branch: can be spent by a different n-of-n pubkeys from the same
> participants, after a relative locktime.
> * Each update transaction has its own unique set of n-of-n pubkeys for
> the state branch, given by the same participant set.
>
> Of note is that the `nLockTime` used in Decker-Russell-Osuntokun are
> always past `nLockTime`s, so that the update branch is always confirmable
> at the current tip, from now until forever.
> Only the state branch has an actual timelock that could prevent immediate
> confirmation of a transaction spending that branch.
>
> Update transactions (awesomely mis)use `nLockTime` as a sequence number;
> the first update transaction has the lowest `nLockTime`, then each
> succeeding update transaction has a higher `nLockTime`, until they reach
> the present time.
>
> Update transactions are signed with `SIGHASH_NOINPUT`.
> This allows the update transaction to not only spend the funding outpoint
> itself, but also to spend any previous update transaction.
>
> Thus, if an old update transaction is published onchain, its output can be
> re-spent by any newer update transaction before the state transaction for
> that update can come into play.
> Any other participant who notices this event can simply publish the newest
> update transaction it knows, as that would supersede the state transaction,
> which can only be confirmed after a time delay.
>
> Under the MAD-HTLC argument, a participant who prefers an older state can
> publish the update transaction for the older state, then bribe miners to
> defer confirmation of newer update transactions, until the state
> transaction for that update transaction can be confirmed.
>
> Conclusion
> ==========
>
> All the above mechanisms use a timelock, and implicitly have the
> assumption that "a transaction, that can be confirmed now, supersedes any
> transaction that has a timelock that forces it to be confirmed later".
>
> It seems likely to me that even future mechanisms will use the same
> assumption as well.
>
> In particular, many proposed mechanisms for non-federated sidechains often
> include some kind of delay between when a sidechain coin is burned and the
> corresponding mainchain coin is released (i.e. side-to-main peg).
> Often, this delay exists in order to allow showing of a counterproof that
> the supposed side-to-main transfer did not actually exist in the sidechain
> (or was later reorged out, or whatever).
> It seems to me that the MAD-HTLC argument would also apply to such
> mechanisms (if anyone still wants to go push sidechains, anyway).
>
> Thus, we really need to carefully investigate the MAD-HTLC argument.
>
> My current analysis suggests that in practice, the MAD-HTLC argument does
> not apply at all (else I would not be revealing that all channel mechanisms
> are broken **if** the MAD-HTLC argument *does* apply), since the myopic
> strategy seems to be pretty much inevitably dominant at stable states.
> But it would still be best to investigate further until we are fully
> convinced that the MAD-HTLC argument ("'earlier supersedes later' might be
> falsified by bribery") does not apply.
>
>
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 21590 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-03 9:43 99% ` Tejaswi Nadahalli
@ 2020-07-03 10:16 99% ` ZmnSCPxj
2020-07-03 10:44 99% ` Tejaswi Nadahalli
0 siblings, 1 reply; 47+ results
From: ZmnSCPxj @ 2020-07-03 10:16 UTC (permalink / raw)
To: Tejaswi Nadahalli
Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
Good morning Tejaswi,
> > But if an attack happens during a fee spike, then even though we retain our current default `to_self_delay` of 144, we still have the ability to gradually and automatically move to higher fee regions until our transaction confirms, and we have a good excuse for it to present to users: "a fee spike was happening at the time, so you had to pay some extra miner fees".
>
> Agree on the UX. There is a tradeoff between the timelocked value of the channel balance to Alice during benign vs malicious abandonment by Bob. In your opinion, increasing the fees beyond 1% (and thereby cutting into Alice's share itself) is a slightly better tradeoff than increasing to_self_delay.
Currently, we say `to_self_delay` is a parameter of how long you can be offline, and is imposed on your counterparty (so its effect on you is to allow the counterparty to safely be offline for that long).
This explanation seems palatable to users; they understand that it is the counterparty which is asking this of them, and that they ask a similar number of their counterparty, which is also their own protection.
On the other hand, we do not really expect to get beyond 1% unless we are under attack, *or* the fee spikes are really, really bad.
So this seems a practical tradeoff for us over in Lightning-land.
> > And since you and your paper openly discusses it anyway, I would like to reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
>
> We know. Maybe we should have made it clear in the paper that when we use the Poon-Dryja channel construction, we use the idea that the knowledge of the preimage of a hash is equivalent to knowing the private key of the revocation public key. In fact, this is how the Poon-Dryja construction is explained in McCorry's Ph.D thesis, and IMHO is easier to understand than the original description in the Poon-Dryja paper (or Bolt #3, for that matter).
Yes, I realized it a little after reading MAD-HTLC that it applied to all the other known channel mechanisms as well, not just HTLCs, and decided to investigate this topic further, and have been circumspect regarding this.
> You could further argue that the hashlock is an incidental artefact, and our paper mostly refers to timelocked transactions. And the rest of your email describes applications of timelocked (and obviously presigned) transactions, which are all vulnerable to the same bribing attack. Additionally, the Wattehnofer in our paper is the same Wattenhofer from the Duplex Channel paper.
Yes, I agree that the hashlock is an incidental artefact.
What MAD-HTLC questions is our assumption that a valid transaction with an earlier locktime supersedes a valid transaction spending the same txout with a later locktime.
Whether it involves presigned transactions or hashlocks are incidental artefacts.
So for example, a SCRIPT `OP_IF <A> OP_ELSE <1 day> OP_CHECKSEQUENCEVERIFY OP_DROP <B> OP_ENDIF OP_CHECKSIG` would also be vulnerable to the MAD-HTLC argument.
(Indeed, BOLT spec uses something very much like that script, now that I look at it again; in our case the `<A>` is a combination of keys from both parties, that cannot be signed with unless one party knows both sub-keys.)
>
> > My current analysis suggests that in practice, the MAD-HTLC argument does not apply at all (else I would not be revealing that all channel mechanisms are broken **if** the MAD-HTLC argument *does* apply), since the myopic strategy seems to be pretty much inevitably dominant at stable states.
>
> We agree.
>
>
> > But it would still be best to investigate further until we are fully convinced that the MAD-HTLC argument ("'earlier supersedes later' might be falsified by bribery") does not apply.
>
> I think this is the analysis our paper does, and perhaps it's our mistake that we do not set the context better. We only mention (and propose fixes for) Poon-Dryja channel construction, and Tier Nolan's Atomic Swap construction.
>
> We could have addressed Spilman's one-way channels or Decker-Wattenhofer duplex channels, but that would have been pointless as they were never going to make it into production after Poon-Dryja and subsequently, Eltoo were proposed.
I suggested that, until `SIGHASH_ANYPREVOUT` gets enabled, the Decker-Wattenhofer construction (removing the duplex Spilman-like channels at the end and leaving just the decrementing-`nSequence` constructions) could be used for Ruben Somsen StateChains, so you might not want to dismiss that so readily.
The decrementing-`nSequence` mechanisms have the advantage that it does not require a punishment/revocation branch, similar to Decker-Russell-Osuntokun "eltoo", and thus would work just as well to implement statechains, at least until all the debates around `SIGHASH_ANYPREVOUT` settle and it gets deployed.
Similarly, the proposed CoinPool as well could be implemented using Decker-Wattenhofer, assuming it gets any details or support behind it sufficiently to push it before `SIGHASH_ANYPREVOUT` gets deployed.
> But not addressing Eltoo in the paper is an omission that I am a bit upset about. We additionally do not address more sophisticated atomic swaps from Somsen or Fournier. Nor do we address Kanzure's vault proposal. In fact, one rule of thumb might be that wherever watchtowers are required, a timelocked bribe might be possible.
I think a better heuristic is that, if the logic of the construction assumes "transaction with earlier locktime supersedes transaction with later locktime", then it is timelocked-bribery-vulnerable.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-03 10:16 99% ` ZmnSCPxj
@ 2020-07-03 10:44 99% ` Tejaswi Nadahalli
[not found] ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
0 siblings, 1 reply; 47+ results
From: Tejaswi Nadahalli @ 2020-07-03 10:44 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Fri, Jul 3, 2020 at 12:17 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> > In fact, one rule of thumb might be that wherever watchtowers are
> required, a timelocked bribe might be possible.
>
> I think a better heuristic is that, if the logic of the construction
> assumes "transaction with earlier locktime supersedes transaction with
> later locktime", then it is timelocked-bribery-vulnerable.
>
That's true by definition. Timelocked bribes are, well, going to be
possible when there are timelocks. I was going more for an "indirect clue"
that wherever a watchtower is proposed, a timelocked bribe is possible.
This is entirely a pedantic point :-)
[-- Attachment #2: Type: text/html, Size: 979 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
[not found] ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
@ 2020-07-03 12:38 99% ` ZmnSCPxj
[not found] ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
2020-07-05 9:03 99% ` Stanga
2020-07-06 11:13 99% ` Tejaswi Nadahalli
1 sibling, 2 replies; 47+ results
From: ZmnSCPxj @ 2020-07-03 12:38 UTC (permalink / raw)
To: Itay Tsabary; +Cc: Bitcoin Protocol Discussion, Matan Yehieli
Good morning Ittay,
> Hi all,
>
> Itay from MAD-HTLC here. I feel like some details got lost along the way so please let me get these sorted out.
>
> 1. Myopic and non-myopic miners:
> When we use the term myopic we mean a miner that optimizes transaction selection for the next block with respect only to the next block. The term non-myopic refers to a miner that optimizes transaction selection for the next block with respect to several future blocks. To accommodate for the stochastic nature of block creation these optimizations are of the expected revenue. However, neither of these mean that these miners choose to act in a way that reduces their expected revenue -- specifically, if from a non-myopic's miner perspective including Alice's immediate transaction is better off than waiting for Bob's future transaction, then this is what they do.
>
> Consequently, saying that "being myopic" dominates "being non-myopic" is incorrect -- myopic is included in being non-myopic, thus cannot be better than it.
The term "dominates" here is a technical term in game theory.
A strategy dominates over another strategy if, in a mixed environment, the first strategy always wins more points than the second strategy, no matter what proportion they may initially start in the mixed environment.
For example, in an environment of prisoner dilemma games, a tit-for-tat strategy dominates over the always-betray strategy, which dominates over always-cooperate strategy.
The above is the use of the term "dominate", and not that somehow one strategy "contains" the other.
Always-betray does not contain always-cooperate.
It is immaterial that the non-myopic "contains" myopic strategy as a sub-strategy.
Sometimes, overriding a sub-strategy can lead to worse outcomes and you are better off sticking to the sub-strategy rather than an extended strategy that sometimes overrides the sub-strategy
(notice how mixed teams of computer+human are no longer dominant in chess, because computer chess AIs are now so sophisticated that on average, the human overriding the computer strategy often leads to worse outcomes than just following the computer; yet about a decade ago such mixed computer+human teams were dominant over pure-computer and pure-human teams; yet you could say the same, that the computer+human "includes" the pure-computer strategy, but nowadays does ***not*** dominate it).
Or: worse is better.
What matters is, if you make them compete in an environment, myopic strategies will consistently beat non-myopic strategies because the myopic miners will impose costs on the non-myopic miners.
>
> So, the next issue to address is estimation of how much of the hash rate is actually non-myopic. Currently that answer is simple -- probably 0. Bitcoin Core (97% of the blocks) doesn't offer these optimizations, and most likely other clients do not have these as well. But, we showed this is rather trivial to implement (150 LoC in Bitcoin Core), and theoretically can be included in Core's next version AFAIK. Moreover, any miner can simply apply our patch independently, achieving the same effect.
>
> Please note more elaborate optimizations are in miners' best interest, especially as mining incentives transition from block minting to fees -- the latter are becoming the main income source, and I believe less sophisticated miners will miss out substantially. You can check out Phil Daian's paper about front-running in Ethereum for example: https://arxiv.org/abs/1904.05234
Yes, but again: myopic strategies dominate over non-myopic strategies, thus implementing non-myopic strategies is pointless, since they will lose revenue in an environment where even a single miner is myopic.
It is immaterial that it takes only 150 LoC to implement non-myopia: if it earns less money in an environment where even a minority of blocks are created by myopic miners (much less 97%), nobody will use the non-myopic strategy and they will remain at negligible near-0% hashrate.
As they say, "you can't get to there from here".
> As common in game-theory papers, our analysis does assume Common Knowledge -- all participants know all other participants, their available strategies and utilities (Tejaswi et al.'s paper makes the same assumption). As commented before, true, this is not always the case -- nodes might have different mempools, and some might not have applied the optimization patch and act myopically. Such miners are therefore "resisting" the attack -- as stated, by including Alice's transaction they ruin other miners' potential profit from Bob's high fee transaction.
The only additional assumption you are missing is that miners care about *themselves* and not about *all miners*.
Non-myopia may earn more money for *all* miners if *all* miners use it, but if a *single* miner starts using myopic strategies in a non-myopic environment, they will earn more funds than their non-myopic competitors and thus dominate, shifting the percentages until almost all miners are using myopic strategies.
That they require less processing ("keep it simple, sir") is just gravy on top.
The only way for non-myopic miners to win is to form a cartel, and a miner cartel with >50% hashpower would be the end of Bitcoin anyway.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: BIP32 Path Templates
2020-07-02 16:28 99% [bitcoin-dev] BIP draft: BIP32 Path Templates Dmitry Petukhov
@ 2020-07-03 14:39 99% ` David A. Harding
2020-07-03 16:53 99% ` Dmitry Petukhov
0 siblings, 1 reply; 47+ results
From: David A. Harding @ 2020-07-03 14:39 UTC (permalink / raw)
To: Dmitry Petukhov, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via bitcoin-dev wrote:
> I think there should be standard format to describe constraints for
> BIP32 paths.
>
> I present a BIP draft that specifies "path templates" for BIP32 paths:
>
> https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/bip-path-templates.mediawiki
Hi Dmitry,
How do path templates compare to key origin identification[1] in
output script descriptors?
Could you maybe give a specfic example of how path templates might be
used? Are they for backups? Multisig wallet coordination? Managing
data between software transaction construction and hardware device
signing?
Thanks,
-Dave
[1] https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#key-origin-identification
(See earlier in the doc for examples)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: BIP32 Path Templates
2020-07-03 14:39 99% ` David A. Harding
@ 2020-07-03 16:53 99% ` Dmitry Petukhov
2020-07-03 19:10 99% ` Dmitry Petukhov
2020-07-06 15:24 99% ` Dmitry Petukhov
0 siblings, 2 replies; 47+ results
From: Dmitry Petukhov @ 2020-07-03 16:53 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]
IIUC, key origin identification specify chains of addresses, with
relation to specific keys. As the name suggests, they are for
identidication.
Path templates specify application-specific constraints for the
derivation paths. They are for imposing restrictions.
You could use path templates for identification, too, and in fact the
"path" part of the key origin identification would be a valid path
template. Path templates have potential to identify multiple chains
of addresses though, and I cannot say how useful it can be, if at all.
When a hardware wallet or some other type of autonomous signer signs a
transaction, there are two points where HD derivation can occur: 1) when
signing an input 2) when checking if the output is the change output
The second case is occurs more often, I think (determining actual
amount sent), but the first case can have uses, too -- when an
autonomous signer can impose restrictions on derivation path based on
the identity of the user that request the signing, for example.
In both of these points an application-specific or usecase-specific
signing scheme might require that only certain whitelisted derivation
paths are used (sending change to the known key, but using derivation
path unknown to the sender allows an attacker to hold the change amount
for ransom, for example)
An autonomous signer might not be aware of the restrictions used in
particular scheme, because it might be developed by different vendor
than the implementor of the particular scheme. Or it might be difficult
to update the firmware of autonomous signer when the checks of the
path constraints are hard-coded in the program code. Having constraints
specified as data would allow to place them in configuration of the
signer.
One particular example of this being a problem is how hardware wallet
vendors seem to be inclined to decide to just restrict the derivation
paths allowed for the change addresses to the set of "well-known"
paths.
Such restrictions, on one hand, break custom schemes used by
various software solutions that rely on the ability of hardware wallet
to sign custom paths, and on the other hand, such hardcoded restrictions
might happen to be too relaxed, if the set of "well-known" path grows,
or the user or software vendor knows for sure that they won't use
addresses past index 1000, for example.
The format for the path templates described in the presented BIP draft
aims to provide a building block for interoperability between various
hardware and software vendors in regard to this particular task of
specifying derivation path restrictions.
Adopting a common format for specifying restictions is a flexible
alternative to everyone adopting a rigid set of "well-known" paths.
Such a set will inevitably grow, and those who really need custom
paths and do not have resources to push for standardization of their
custom paths will be at a disadvantage.
My hope is that having a clear specification and (possibly, in the
future) permissibly licensed quality implementations would make
adopting such format easier for vendors.
В Fri, 3 Jul 2020 10:39:45 -0400
"David A. Harding" <dave@dtrt•org> wrote:
> On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via
> bitcoin-dev wrote:
> > I think there should be standard format to describe constraints for
> > BIP32 paths.
> >
> > I present a BIP draft that specifies "path templates" for BIP32
> > paths:
> >
> > https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/bip-path-templates.mediawiki
> >
>
> Hi Dmitry,
>
> How do path templates compare to key origin identification[1] in
> output script descriptors?
>
> Could you maybe give a specfic example of how path templates might be
> used? Are they for backups? Multisig wallet coordination? Managing
> data between software transaction construction and hardware device
> signing?
>
> Thanks,
>
> -Dave
>
> [1]
> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#key-origin-identification
> (See earlier in the doc for examples)
[-- Attachment #2: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: BIP32 Path Templates
2020-07-03 16:53 99% ` Dmitry Petukhov
@ 2020-07-03 19:10 99% ` Dmitry Petukhov
2020-07-06 15:24 99% ` Dmitry Petukhov
1 sibling, 0 replies; 47+ results
From: Dmitry Petukhov @ 2020-07-03 19:10 UTC (permalink / raw)
To: Dmitry Petukhov via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
В Fri, 3 Jul 2020 21:53:44 +0500
Dmitry Petukhov via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
wrote:
> The format for the path templates described in the presented BIP draft
> aims to provide a building block for interoperability between various
> hardware and software vendors in regard to this particular task of
> specifying derivation path restrictions.
One example of an interoperability workflow might be:
A software vendor that utilizes custom derivation paths in their
schemes create a "profile" that contains the constraints on the paths
(and possibly other parameters, but this is out of scope of the
proposal) for their particular scheme. In a simple case it might just
be a path template string provided in the documentation.
A user of a software solution from that vendor takes a hardware wallet
that supports path templates (or richer "profiles") and installs the
profile for that solution into hardware wallet. In a simple case, the
user just pastes a path template string into some configuration utility
program and then confirms the setting on-device.
The device statrts to enforce the constraints specified in the template
(or "profile"), and the software solution works as intended by the
software vendor.
[-- Attachment #2: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
[not found] ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
@ 2020-07-04 20:58 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-04 20:58 UTC (permalink / raw)
To: Itay Tsabary; +Cc: Bitcoin Protocol Discussion, Matan Yehieli
Good morning Ittay,
> The analysis in our MAD-HTLC paper shows that when all players are rational (i.e., make the best decisions), and have the greater strategy space (which is easy to achieve, 150 Loc), the subgame-perfect-equilibrium strategy (this is like Nash-equilibrium for dynamic games https://en.wikipedia.org/wiki/Subgame_perfect_equilibrium) for even relatively-small fee is to support the attack. Putting it in game-theory terms -- strategy "exclude-Alice-until-timeout-then-include-Bob" results with higher utility than strategy "include-Alice-Tx-now" (and by definition, "include-Alice-Tx-now" does not dominante "exclude-Alice-until-timeout-then-include-Bob").
It may be helpful to think in terms of Prisoner Dilemma.
| cooperate | betray
-----------+-----------+---------
cooperate | -1, -1 | 0, -3
-----------+-----------+---------
betray | -3, 0 | -2, -2
"include-Alice-Tx-now" imposes a greater cost on those playing "exclude-Alice-until-timeout-then-include-Bob" players, than the benefit that both miners play "exclude-Alice-until-timeout-then-include-Bob".
Basically, "cooperate" == "exclude-Alice-until-timeout-then-include-Bob", "betray" == "include-Alice-Tx-now".
One way to get around this is to invoke Iterated Prisoner Dilemma, but that requires that miners can identify other miners and to be able to act accordingly to how those other miners have acted in the past.
The entire point of Bitcoin mining is to allow strong anonymity of miners (not that this commonly happens in practice, given the habit of putting identifying information in coinbases).
Another way would be to have a higher system that polices its constituents and ensures that every miner plays "exclude-Alice-until-timeout-then-include-Bob", and punishes "include-Alice-Tx-now".
But that would be equivalent to a centralized cartel, and would be the death of Bitcoin anyway, at which point, all Bitcoin tokens will be worthless.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
@ 2020-07-04 21:05 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-04 21:05 UTC (permalink / raw)
To: David A. Harding; +Cc: Matan Yehieli, Bitcoin Protocol Discussion, Itay Tsabary
Good morning Dave,
> > > - Inputs:
> > > - Bob 1 BTC - HTLC amount
> > > - Bob 1 BTC - Bob fidelity bond
> > > - Cases:
> > > - Alice reveals hashlock at any time:
> > > - 1 BTC goes to Alice
> > > - 1 BTC goes to Bob (fidelity bond refund)
> > > - Bob reveals bob-hashlock after time L:
> > > - 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
> > > - Bob cheated, anybody reveals both hashlock and bob-hashlock:
> > > - 2 BTC goes to miner
> > >
> > > [...]
> >
> > The cases you present are exactly how MAD-HTLC works. It comprises two
> > contracts (UTXOs):
> >
> > - Deposit (holding the intended HTLC tokens), with three redeem paths:
> > - Alice (signature), with preimage "A", no timeout
> > - Bob (signature), with preimage "B", timeout T
> > - Any entity (miner), with both preimages "A" and "B", no timeout
> > - Collateral (the fidelity bond, doesn't have to be of the same amount)
> > - Bob (signature), no preimage, timeout T
> > - Any entity (miner), with both preimages "A" and "B", timeout T
>
> I'm not these are safe if your counterparty is a miner. Imagine Bob
> offers Alice a MAD-HTLC. Alice knows the payment preimage ("preimage
> A"). Bob knows the bond preimage ("preimage B") and he's the one making
> the payment and offering the bond.
>
> After receiving the HTLC, Alice takes no action on it, so the timelock
> expires. Bob publicly broadcasts the refund transaction with the bond
> preimage. Unbeknownst to Bob, Alice is actually a miner and she uses her
> pre-existing knowledge of the payment preimage plus her received
> knowledge of the bond preimage to privately attempt mining a transaction
> that pays her both the payment ("deposit") and the bond ("collateral").
>
> Assuming Alice is a non-majority miner, she isn't guaranteed to
> succeed---her chance of success depends on her percentage of the network
> hashrate and how much fee Bob paid to incentivize other miners to
> confirm his refund transaction quickly. However, as long as Alice has a
> non-trivial amount of hashrate, she will succeed some percentage of the
> time in executing this type of attack. Any of her theft attempts that
> fail will leave no public trace, perhaps lulling users into a false
> sense of security.
This note seems to have gotten missed in discussion.
Another note is that from what I can tell, the preimages "A" and "B" can be provided by any miner.
If the fund value plus the collateral is large enough, it may incentivize competing miners to reorg the chain, redirecting the funds of the MAD-HTLC to themselves, rather than advance the blockchain state, at least until alternative transctions bump their fees up enough that the collateral + fund is matched.
This may not apply to Lightning at least if you do not go beyond the Wumbo limit, but *could* apply to e.g. SwapMarket, if it uses MAD-HTLCs.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
2020-07-03 12:38 99% ` ZmnSCPxj
[not found] ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
@ 2020-07-05 9:03 99% ` Stanga
1 sibling, 0 replies; 47+ results
From: Stanga @ 2020-07-05 9:03 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Matan Yehieli, Itay Tsabary
[-- Attachment #1: Type: text/plain, Size: 6679 bytes --]
Hi ZmnSCPxj,
1. If all miners are rational and non-myopic, they will support the attack.
They don't need to cooperate, it's not the end of Bitcoin, but they all
have to know everyone is rational and non-myopic. If you want to be secure
in a situation like this then mad-htlc helps. Otherwise you can stick with
htlc. To be clear, assuming it away means assuming at least some miners are
altruistic or suboptimal.
2. I believe what Itay meant when he said myopic is included in non-myopic
is that non-myopic will never choose a worse strategy than myopic. They
both have the same utility function, but the non-myopic has more freedom.
Specifically, if there are enough miners that are either irrational or
myopic, and the bribe is small, then the best non-myopic strategy and the
best myopic strategy is to not accept the bribe. (I think we're all in
agreement on this one, it's just about terminology)
Best,
Ittay
On Fri, Jul 3, 2020 at 3:38 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Good morning Ittay,
>
> > Hi all,
> >
> > Itay from MAD-HTLC here. I feel like some details got lost along the way
> so please let me get these sorted out.
> >
> > 1. Myopic and non-myopic miners:
> > When we use the term myopic we mean a miner that optimizes transaction
> selection for the next block with respect only to the next block. The
> term non-myopic refers to a miner that optimizes transaction selection for
> the next block with respect to several future blocks. To accommodate for
> the stochastic nature of block creation these optimizations are of
> the expected revenue. However, neither of these mean that these miners
> choose to act in a way that reduces their expected revenue -- specifically,
> if from a non-myopic's miner perspective including Alice's immediate
> transaction is better off than waiting for Bob's future transaction, then
> this is what they do.
> >
> > Consequently, saying that "being myopic" dominates "being non-myopic" is
> incorrect -- myopic is included in being non-myopic, thus cannot be better
> than it.
>
> The term "dominates" here is a technical term in game theory.
>
> A strategy dominates over another strategy if, in a mixed environment, the
> first strategy always wins more points than the second strategy, no matter
> what proportion they may initially start in the mixed environment.
>
> For example, in an environment of prisoner dilemma games, a tit-for-tat
> strategy dominates over the always-betray strategy, which dominates over
> always-cooperate strategy.
>
> The above is the use of the term "dominate", and not that somehow one
> strategy "contains" the other.
> Always-betray does not contain always-cooperate.
>
> It is immaterial that the non-myopic "contains" myopic strategy as a
> sub-strategy.
> Sometimes, overriding a sub-strategy can lead to worse outcomes and you
> are better off sticking to the sub-strategy rather than an extended
> strategy that sometimes overrides the sub-strategy
>
> (notice how mixed teams of computer+human are no longer dominant in chess,
> because computer chess AIs are now so sophisticated that on average, the
> human overriding the computer strategy often leads to worse outcomes than
> just following the computer; yet about a decade ago such mixed
> computer+human teams were dominant over pure-computer and pure-human teams;
> yet you could say the same, that the computer+human "includes" the
> pure-computer strategy, but nowadays does ***not*** dominate it).
>
> Or: worse is better.
>
>
> What matters is, if you make them compete in an environment, myopic
> strategies will consistently beat non-myopic strategies because the myopic
> miners will impose costs on the non-myopic miners.
>
>
> >
> > So, the next issue to address is estimation of how much of the hash rate
> is actually non-myopic. Currently that answer is simple -- probably 0.
> Bitcoin Core (97% of the blocks) doesn't offer these optimizations, and
> most likely other clients do not have these as well. But, we showed this is
> rather trivial to implement (150 LoC in Bitcoin Core), and theoretically
> can be included in Core's next version AFAIK. Moreover, any miner can
> simply apply our patch independently, achieving the same effect.
> >
> > Please note more elaborate optimizations are in miners' best interest,
> especially as mining incentives transition from block minting to fees --
> the latter are becoming the main income source, and I believe less
> sophisticated miners will miss out substantially. You can check out Phil
> Daian's paper about front-running in Ethereum for example:
> https://arxiv.org/abs/1904.05234
>
> Yes, but again: myopic strategies dominate over non-myopic strategies,
> thus implementing non-myopic strategies is pointless, since they will lose
> revenue in an environment where even a single miner is myopic.
>
> It is immaterial that it takes only 150 LoC to implement non-myopia: if it
> earns less money in an environment where even a minority of blocks are
> created by myopic miners (much less 97%), nobody will use the non-myopic
> strategy and they will remain at negligible near-0% hashrate.
>
> As they say, "you can't get to there from here".
>
>
> > As common in game-theory papers, our analysis does assume Common
> Knowledge -- all participants know all other participants, their available
> strategies and utilities (Tejaswi et al.'s paper makes the same
> assumption). As commented before, true, this is not always the case --
> nodes might have different mempools, and some might not have applied the
> optimization patch and act myopically. Such miners are therefore
> "resisting" the attack -- as stated, by including Alice's transaction they
> ruin other miners' potential profit from Bob's high fee transaction.
>
> The only additional assumption you are missing is that miners care about
> *themselves* and not about *all miners*.
>
> Non-myopia may earn more money for *all* miners if *all* miners use it,
> but if a *single* miner starts using myopic strategies in a non-myopic
> environment, they will earn more funds than their non-myopic competitors
> and thus dominate, shifting the percentages until almost all miners are
> using myopic strategies.
> That they require less processing ("keep it simple, sir") is just gravy on
> top.
>
>
> The only way for non-myopic miners to win is to form a cartel, and a miner
> cartel with >50% hashpower would be the end of Bitcoin anyway.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7612 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] MAD-HTLC
[not found] ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
2020-07-03 12:38 99% ` ZmnSCPxj
@ 2020-07-06 11:13 99% ` Tejaswi Nadahalli
1 sibling, 0 replies; 47+ results
From: Tejaswi Nadahalli @ 2020-07-06 11:13 UTC (permalink / raw)
To: Itay Tsabary; +Cc: Matan Yehieli, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On Fri, Jul 3, 2020 at 1:49 PM Itay Tsabary <sitay@campus•technion.ac.il>
wrote:
> Note the required token amount for the collateral contract is low and
> independent of the required deposit tokens -- only a relatively small
> incentive is required to make "acting honestly" Bob's preferred choice.
> So, this is basically a negligible overhead, token-wise. As a downside, it
> does create slightly larger transactions (another UTXO, etc.).
>
I read the MAD-HTLC paper and I think it actually doesn't get into the size
of the collateral (v^{col}). I might have missed it though. Can you please
point me to the section in the paper where the amount is discussed?
I assumed that v^{col} has to be at least the size of v^{dep}. Otherwise,
Bob can threaten Alice with an HTLC bribery attack, and Alice knows that
Bob has very little to lose. Bob *should* have the same amount to lose, to
make it work - no?
>
[-- Attachment #2: Type: text/html, Size: 1575 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: BIP32 Path Templates
2020-07-03 16:53 99% ` Dmitry Petukhov
2020-07-03 19:10 99% ` Dmitry Petukhov
@ 2020-07-06 15:24 99% ` Dmitry Petukhov
1 sibling, 0 replies; 47+ results
From: Dmitry Petukhov @ 2020-07-06 15:24 UTC (permalink / raw)
To: Dmitry Petukhov via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
В Fri, 3 Jul 2020 21:53:44 +0500
Dmitry Petukhov via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
wrote:
> My hope is that having a clear specification and (possibly, in the
> future) permissibly licensed quality implementations would make
> adopting such format easier for vendors.
I have added a C implementation (MIT-licensed):
https://github.com/dgpv/bip32_template_c_implementation
[-- Attachment #2: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
@ 2020-07-09 21:40 99% Anthony Towns
2020-07-09 22:30 99% ` Anthony Towns
2020-07-10 3:29 99% ` ZmnSCPxj
0 siblings, 2 replies; 47+ results
From: Anthony Towns @ 2020-07-09 21:40 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hello world,
After talking with Christina ages ago, we came to the conclusion that
it made more sense to update BIP 118 to the latest thinking than have
a new BIP number, so I've (finally) opened a (draft) PR to update BIP
118 with the ANYPREVOUT bip I've passed around to a few people,
https://github.com/bitcoin/bips/pull/943
Probably easiest to just read the new BIP text on github:
https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
It doesn't come with tested code at this point, but I figure better to
have the text available for discussion than nothing.
Some significant changes since previous discussion include complete lack
of chaperone signatures or anything like it (if you want them, you can
always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
longer commits to the value (details/rationale in the text).
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 21:40 99% [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
@ 2020-07-09 22:30 99% ` Anthony Towns
2020-07-10 7:46 99% ` Christian Decker
2020-07-10 3:29 99% ` ZmnSCPxj
1 sibling, 1 reply; 47+ results
From: Anthony Towns @ 2020-07-09 22:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev wrote:
> After talking with Christina
Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke.
Cheers,
aj, hoping he typed one of those right, at least...
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 21:40 99% [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
2020-07-09 22:30 99% ` Anthony Towns
@ 2020-07-10 3:29 99% ` ZmnSCPxj
1 sibling, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-10 3:29 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
Good morning aj,
It seems okay to me.
--
Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction could, in theory, have only a single internal taproot pubkey, `P = MuSig(A, B)` for a channel between A and B.
So the funding outpoint would be spent with a taprooted P + a single tapscript `<1> OP_CHECKSIG`.
Update transactions would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUTANYSCRIPT`.
The update transaction output would be spendable with a taprooted P + a single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1> OP_CHECKSIG`.
Each update transaction would have a monotonically-increasing `nLockTime`, i.e. the above `index`.
Then a state transaction would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUT`, which commits to the exact script including `<index + 1>`, which is unique for each update transaction.
Thus a state transaction can only spend the specific update transaction, but the update transaction can spend the funding outpoint or any update transaction outpoint.
State transaction input would have an `nSequence` requiring a relative locktime of the agreed-upon unilateral close delay.
The above assumes MuSig signing, which requires 1.5 round trips for a channel, or three broadcast rounds for a multiparticipant (n >= 3) construction.
Regards,
ZmnSCPxj
> Hello world,
>
> After talking with Christina ages ago, we came to the conclusion that
> it made more sense to update BIP 118 to the latest thinking than have
> a new BIP number, so I've (finally) opened a (draft) PR to update BIP
> 118 with the ANYPREVOUT bip I've passed around to a few people,
>
> https://github.com/bitcoin/bips/pull/943
>
> Probably easiest to just read the new BIP text on github:
>
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>
> It doesn't come with tested code at this point, but I figure better to
> have the text available for discussion than nothing.
>
> Some significant changes since previous discussion include complete lack
> of chaperone signatures or anything like it (if you want them, you can
> always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
> longer commits to the value (details/rationale in the text).
>
> Cheers,
> aj
>
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 22:30 99% ` Anthony Towns
@ 2020-07-10 7:46 99% ` Christian Decker
0 siblings, 0 replies; 47+ results
From: Christian Decker @ 2020-07-10 7:46 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
No worries, it's a common character twist I find myself doing from time to
time :-)
Cheers,
Christina
On Fri, 10 Jul 2020, 00:31 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > After talking with Christina
>
> Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke.
>
> Cheers,
> aj, hoping he typed one of those right, at least...
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1247 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Taproot activation discussion
@ 2020-07-12 14:53 99% Steve Lee
0 siblings, 0 replies; 47+ results
From: Steve Lee @ 2020-07-12 14:53 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
Hello all,
A new Freenode IRC channel ##taproot-activation has been created for
discussion about various activation proposals, community outreach, and
general next steps to gain adoption. Feel free to engage, lurk, or ignore.
Steve
[-- Attachment #2: Type: text/html, Size: 319 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
[not found] <f0372f8eec5878fd919b654db76aeff7.squirrel@giyzk7o6dcunb2ry.onion>
@ 2020-07-14 2:58 99% ` Mr. Lee Chiffre
2020-07-14 14:42 99% ` ZmnSCPxj
0 siblings, 1 reply; 47+ results
From: Mr. Lee Chiffre @ 2020-07-14 2:58 UTC (permalink / raw)
To: lightning-dev; +Cc: bitcoin-dev
Sorry. Re-sending with correction to CC bitcoin-dev
I am sorry if this was already brought up in previous threads. If I know
lightning network correctly then HTLC is used to enforce settlements on
blockchain if there is a dispute. Could a person lose money if their HTLC
does not get confirmed in the timeframe or if an older HTLC gets
confirmed first? I see different ways this could happen.
One, if the blockchain is very saturated with other transactions. The
reason we need lightning network is why it might have troubles with
settlements? Two, competition from a different conflicting HTLC. A newer
HTLC might not get confirmed before an older HTL. Three, denial of service
the lightning router so they never have a chance to send a settlement
HTLC.
I found out about a recent attack technique that sounds like it might be
similar called "flood and loot".
Is this a concern on lightning network? I humbly say that I do not fully
understand all of lightning network yet. I am working to grasp the idea.
These are questions I look to find answer for. Another question I have. I
did read the paper Scalable Funding of Bitcoin Micropayment Channel
Networks. Would channel factories be better and eliminate my concern?
I am sending this to lightning-dev mailing list. I do not see
lightning-dev emails because google recaptcha blocks me from the
subscribe. Please CC me if you reply so I can read it.
--
lee.chiffre@secmail•pro
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Thoughts on soft-fork activation
@ 2020-07-14 9:37 99% Anthony Towns
2020-07-14 20:46 99% ` Matt Corallo
0 siblings, 1 reply; 47+ results
From: Anthony Towns @ 2020-07-14 9:37 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi,
I've been trying to figure out a good way to activate soft forks in
future. I'd like to post some thoughts on that. So:
I think there's two proposals that are roughly plausible. The first is
Luke's recent update to BIP 8:
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
It has the advantage of being about as simple as possible, and (in my
opinion) is an incremental improvement on how segwit was activated. Its
main properties are:
- signalling via a version bit
- state tansitions based on height rather than median time
- 1 year time frame
- optional mandatory activation at the end of the year
- mandatory signalling if mandatory activation occurs
- if the soft fork activates on the most work chain, nodes don't
risk falling out of consensus depending on whether they've opted in
to mandatory activation or not
I think there's some fixable problems with that proposal as it stands
(mostly already mentioned in the comments in the recently merged PR,
https://github.com/bitcoin/bips/pull/550 )
The approach I've been working on is based on the more complicated and
slower method described by Matt on this list back in January. I've got a
BIP drafted at:
https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki
The main difference with the mechanism described in January is that the
threshold gradually decreases during the secondary period -- it starts at
95%, gradually decreases until 50%, then mandatorily activates. The idea
here is to provide at least some potential reward for miners signalling
in the secondary phase: if 8% of hashpower had refused to signal for
a soft-fork, then there would have been no chance of activating until
the very end of the period. This way, every additional percentage of
hashpower signalling brings the activation deadline forward.
The main differences between the two proposals is that the BIP 8 approach
has a relatively short time frame for users to upgrade if we want
mandatory activation without a supermajority of hashpower enforcing the
rules; while the "decreasing threshold" approach linked above provides
quite a long timeline.
In addition, there is always the potential to introduce a BIP 91/148
style soft-fork after the fact where either miners or users coordinate to
have mandatory signalling which then activates a pre-existing deployment
attempt.
I think the design constraints we want are:
* if everyone cooperates and no one objects, we activate pretty quickly
* there's no obvious exploits, and we have plausible contingency plans
in place to discourage people from try to use the attempt to deploy
a new soft fork as a way of attacking bitcoin, either via social
disruption or by preventing bitcoin from improving
* we don't want to ship code that causes people to fall out of
consensus in the (hopefully unlikely) event that things don't go
smoothly [0]
In light of that, I think I'm leaning towards:
* use BIP 8 with mandatory activation disabled in bitcoin core -- if
you want to participate in enforcing mandatory activation, you'll
need to recompile, or use a fork like bitcoin knots; however if
mandatory activation occurs on the longest chain, you'll still follow
that chain and enforce the rules.
* be prepared to update the BIP 8 parameters to allow mandatory
activation in bitcoin core if, after 9 months say, it's apparent that
there aren't reasonable objections, there's strong support for
activation, the vast majority of nodes have already updated to
enforce the rules upon activation, and there's strong support for
mandatory activation
* change the dec-threshold proposal to be compatible with BIP 8, and
keep it maintained so that it can be used if there seems to be
widespread consensus for activation, but BIP 8 activation does
not seem certain -- ie, as an extra contingency plan.
* be prepared to support miners coordinating via BIP 91 either to
bring activation forward in either BIP 8 or "decreasing threshold" or
de-risk BIP 8 mandatory activation -- ie, an alternative contingency
plan. This is more appropriate if we've found that users/miners have
upgraded so that activation is safe; so it's a decision we can make
later when we have more data, rather than having to make the decision
early when we don't have enough information to judge whether it's
safe or not.
* (also, improve BIP 8 a bit more before deploying it -- I'm hoping for
some modest changes, which is why "decreasing threshold" isn't already
compatible with BIP 8)
* (continue to ensure the underlying soft fork makes sense and is
well implemented on its own merits)
* (continue to talk to as many people as we can about the underlying
changes and make sure people understand what's going on and that
we've addressed any reasonable objections)
I'm hopeful activating taproot will go smoothly, but I'm not 100% sure
of it, and there are potentially many different ways in which things go
wrong; so starting with something simple and being ready to adapt if/when
we see things starting to go weird seems like a good approach to me.
Cheers,
aj
[0] At least, that's how I'm phrasing some of the concerns that were
expressed in, eg,
https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
2020-07-14 2:58 99% ` [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories Mr. Lee Chiffre
@ 2020-07-14 14:42 99% ` ZmnSCPxj
2020-07-15 15:23 99% ` Jochen Hoenicke
0 siblings, 1 reply; 47+ results
From: ZmnSCPxj @ 2020-07-14 14:42 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion; +Cc: lightning-dev
Good morning Mr. Lee,
> Sorry. Re-sending with correction to CC bitcoin-dev
>
> I am sorry if this was already brought up in previous threads. If I know
> lightning network correctly then HTLC is used to enforce settlements on
> blockchain if there is a dispute. Could a person lose money if their HTLC
> does not get confirmed in the timeframe or if an older HTLC gets
> confirmed first? I see different ways this could happen.
>
> One, if the blockchain is very saturated with other transactions. The
> reason we need lightning network is why it might have troubles with
> settlements?
This could happen, but the entire exercise is to move transactions off the blockchain, precisely to lower this risk.
Otherwise, transfers onchain will take a long time.
In practice, a long time to settle a payment will invalidate many real-world economic exchanges anyway (consider paying for food at a restaurant --- if your payments take days to settle, the food has gotten stale before the restaurant receives payment and releases your food).
Thus, if an onchain transfer takes a long time to settle, there is already risk of economic loss present.
By moving activity offchain, we reduce pressure onchain and improve settlement speeds on both offchain and onchain, reducing risk of economic loss due to delay.
> Two, competition from a different conflicting HTLC. A newer
> HTLC might not get confirmed before an older HTL.
I cannot make sense of this.
You cannot create conflicting HTLCs.
Either you have some free money to create an HTLC, in which case there is no possible conflict with an existing HTLC (the fund is reserved for HTLCs, or it is yours without further encumbrance).
Thus it is not possible to create a conflicting HTLC in any case: either you have funds (that are not already in an HTLC) to fund an HTLC and that HTLC cannot conflict with existing ones, or you have no funds and a new HTLC cannot be created until one of the HTLCs is resolved one way or another.
> Three, denial of service
> the lightning router so they never have a chance to send a settlement
> HTLC.
This is possible, but only that node risks loss.
The reason why unilateral close is always possible is to handle the case where a routing node comes offline.
If you have offered an HTLC to a routing node, you retain a timelock branch back to you (the "T" in HTLC).
If the routing node goes offline past the timelock in the HTLC, then you unilaterally close the channel and drop the HTLC onchain.
This is what lets you recover your funds.
>
> I found out about a recent attack technique that sounds like it might be
> similar called "flood and loot".
Roughly, my understanding of Flood and Loot is to make a lot of uneconomically tiny HTLCs going through a target victim forwarding node.
You make circular routes going from your own node back to yourself.
Then you refuse to actually claim the HTLCs sent back to yourself.
Then you go offline.
This means that the only way for the forwarding node to recover its funds is to drop the channel(s) involved onchain.
But if the HTLCs are many and tiny, they are simply too uneconomic to claim onchain, so they just lose the channel funds as fees.
>
> Is this a concern on lightning network?
Yes.
Work is being done (anchor commitments) to mitigate the effects of onchain fees on Lightning.
> I humbly say that I do not fully
> understand all of lightning network yet. I am working to grasp the idea.
> These are questions I look to find answer for. Another question I have. I
> did read the paper Scalable Funding of Bitcoin Micropayment Channel
> Networks. Would channel factories be better and eliminate my concern?
They would not.
Ultimately, your "final defense" is to drop the entire construction onchain until you reach the HTLCs and you can have the blockchain enforce the HTLC contract.
It would *help* to reduce blockchain bloat by reducing the size of transactions to create multiple channels, and thus also secondarily helps reduce onchain fee pressure and also reduce Flood-and-Loot (which is basically a layer-crossing attack, taking advantage of lower-layer fees to create attacks on higher layers).
But always the underlying problem remains: security costs something, and you have to pay for protection on the Internet when transacting with potentially untrusted (and untrustable) entities.
It seems unlikely that "security costs something" can be eliminated.
One can consider that modern-day state-imposed taxation is paying for security, for instance, of traditional face-to-face transactions.
With Bitcoin, you can choose to either transact and pay for security, or not transact and forgo what you would have bought.
With some tradeoffs, you can pay by other means that may be cheaper for you.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Thoughts on soft-fork activation
2020-07-14 9:37 99% [bitcoin-dev] Thoughts on soft-fork activation Anthony Towns
@ 2020-07-14 20:46 99% ` Matt Corallo
2020-07-17 2:58 99% ` ZmnSCPxj
0 siblings, 1 reply; 47+ results
From: Matt Corallo @ 2020-07-14 20:46 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
Thanks Anthony for this writeup!
I find it incredibly disappointing that the idea of naive flag day fork activation is being seriously discussed in the
form of BIP 9. Activation of forks is not only about the included changes but also around the culture of how changes to
Bitcoin should be and are made. Whether we like it or not, how Taproot activates will set a community understanding and
future norms around how many changes are made.
Members of this list lost sleep and years off their life from stress fighting to ensure that the process by which
Bitcoin changes is not only principled in its rejection of unilateral changes, but also that that idea was broadly
understood, and broadly *enforced* by community members - the only way in which it has any impact. That fight is far
from over - Bitcoin's community grows and changes daily, and the history around what changed and how has been rewritten
time and time again. Worse still, the principled nature of Bitcoin's change process is targeted constantly as untrue in
an attempt by various alternative systems to pretend that their change process of "developers ship new code, users run
it blindly" is identical to Bitcoin.
While members of this list may be aware of significant outreach efforts and design work to ensure that Taproot is not
only broadly acceptable to Bitcoin users, but also has effectively no impact on users who wish not to use it, it is
certainly not the case that all Bitcoin users are aware of that work, nor seen the results directly communicated to them.
Worse still, it is hard to argue that a new version of Bitcoin Core containing a fixed future activation of a new
consensus rule is anything other than "developers have decided on new rules" (even if it is, based on our own knowledge,
not the case). Indeed, even the proposal by Anthony, which makes reference to my previous work has this issue, and it
may not be avoidable - there is very legitimate concern over miners blocking changes to Bitcoin which do not harm them
which users objectively desire, potentially purely through apathy. But to dismiss the concerns over the optics which set
the stage for how future changes are made to Bitcoin purely because miners may be too busy with other things to upgrade
their nodes seems naive at best.
I appreciate the concern over activation timeline given miner apathy, and to some extend Anthony's work here addresses
that with decreasing activation thresholds during the second signaling period, but bikeshedding on timeline may be merited.
To not make every attempt to distance the activation method from the public perception unilateral activation strikes me
as the worst of all possible outcomes for Bitcoin's longevity. Having a quieting period after BIP 9 activation failure
may not be the best way to do that, but it seems like a reasonable attempt.
Matt
On 7/14/20 5:37 AM, Anthony Towns via bitcoin-dev wrote:
> Hi,
>
> I've been trying to figure out a good way to activate soft forks in
> future. I'd like to post some thoughts on that. So:
>
> I think there's two proposals that are roughly plausible. The first is
> Luke's recent update to BIP 8:
>
> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
>
> It has the advantage of being about as simple as possible, and (in my
> opinion) is an incremental improvement on how segwit was activated. Its
> main properties are:
>
> - signalling via a version bit
> - state tansitions based on height rather than median time
> - 1 year time frame
> - optional mandatory activation at the end of the year
> - mandatory signalling if mandatory activation occurs
> - if the soft fork activates on the most work chain, nodes don't
> risk falling out of consensus depending on whether they've opted in
> to mandatory activation or not
>
> I think there's some fixable problems with that proposal as it stands
> (mostly already mentioned in the comments in the recently merged PR,
> https://github.com/bitcoin/bips/pull/550 )
>
> The approach I've been working on is based on the more complicated and
> slower method described by Matt on this list back in January. I've got a
> BIP drafted at:
>
> https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki
>
> The main difference with the mechanism described in January is that the
> threshold gradually decreases during the secondary period -- it starts at
> 95%, gradually decreases until 50%, then mandatorily activates. The idea
> here is to provide at least some potential reward for miners signalling
> in the secondary phase: if 8% of hashpower had refused to signal for
> a soft-fork, then there would have been no chance of activating until
> the very end of the period. This way, every additional percentage of
> hashpower signalling brings the activation deadline forward.
>
> The main differences between the two proposals is that the BIP 8 approach
> has a relatively short time frame for users to upgrade if we want
> mandatory activation without a supermajority of hashpower enforcing the
> rules; while the "decreasing threshold" approach linked above provides
> quite a long timeline.
>
> In addition, there is always the potential to introduce a BIP 91/148
> style soft-fork after the fact where either miners or users coordinate to
> have mandatory signalling which then activates a pre-existing deployment
> attempt.
>
> I think the design constraints we want are:
>
> * if everyone cooperates and no one objects, we activate pretty quickly
>
> * there's no obvious exploits, and we have plausible contingency plans
> in place to discourage people from try to use the attempt to deploy
> a new soft fork as a way of attacking bitcoin, either via social
> disruption or by preventing bitcoin from improving
>
> * we don't want to ship code that causes people to fall out of
> consensus in the (hopefully unlikely) event that things don't go
> smoothly [0]
>
> In light of that, I think I'm leaning towards:
>
> * use BIP 8 with mandatory activation disabled in bitcoin core -- if
> you want to participate in enforcing mandatory activation, you'll
> need to recompile, or use a fork like bitcoin knots; however if
> mandatory activation occurs on the longest chain, you'll still follow
> that chain and enforce the rules.
>
> * be prepared to update the BIP 8 parameters to allow mandatory
> activation in bitcoin core if, after 9 months say, it's apparent that
> there aren't reasonable objections, there's strong support for
> activation, the vast majority of nodes have already updated to
> enforce the rules upon activation, and there's strong support for
> mandatory activation
>
> * change the dec-threshold proposal to be compatible with BIP 8, and
> keep it maintained so that it can be used if there seems to be
> widespread consensus for activation, but BIP 8 activation does
> not seem certain -- ie, as an extra contingency plan.
>
> * be prepared to support miners coordinating via BIP 91 either to
> bring activation forward in either BIP 8 or "decreasing threshold" or
> de-risk BIP 8 mandatory activation -- ie, an alternative contingency
> plan. This is more appropriate if we've found that users/miners have
> upgraded so that activation is safe; so it's a decision we can make
> later when we have more data, rather than having to make the decision
> early when we don't have enough information to judge whether it's
> safe or not.
>
> * (also, improve BIP 8 a bit more before deploying it -- I'm hoping for
> some modest changes, which is why "decreasing threshold" isn't already
> compatible with BIP 8)
>
> * (continue to ensure the underlying soft fork makes sense and is
> well implemented on its own merits)
>
> * (continue to talk to as many people as we can about the underlying
> changes and make sure people understand what's going on and that
> we've addressed any reasonable objections)
>
> I'm hopeful activating taproot will go smoothly, but I'm not 100% sure
> of it, and there are potentially many different ways in which things go
> wrong; so starting with something simple and being ready to adapt if/when
> we see things starting to go weird seems like a good approach to me.
>
> Cheers,
> aj
>
> [0] At least, that's how I'm phrasing some of the concerns that were
> expressed in, eg,
>
> https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
2020-07-14 14:42 99% ` ZmnSCPxj
@ 2020-07-15 15:23 99% ` Jochen Hoenicke
0 siblings, 0 replies; 47+ results
From: Jochen Hoenicke @ 2020-07-15 15:23 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]
On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Good morning Mr. Lee,
>
> > Sorry. Re-sending with correction to CC bitcoin-dev
> >
> > I am sorry if this was already brought up in previous threads. If I know
> > lightning network correctly then HTLC is used to enforce settlements on
> > blockchain if there is a dispute. Could a person lose money if their HTLC
> > does not get confirmed in the timeframe or if an older HTLC gets
> > confirmed first? I see different ways this could happen.
> >
> > One, if the blockchain is very saturated with other transactions. The
> > reason we need lightning network is why it might have troubles with
> > settlements?
>
> This could happen, but the entire exercise is to move transactions off the
> blockchain, precisely to lower this risk.
>
> Otherwise, transfers onchain will take a long time.
> In practice, a long time to settle a payment will invalidate many
> real-world economic exchanges anyway (consider paying for food at a
> restaurant --- if your payments take days to settle, the food has gotten
> stale before the restaurant receives payment and releases your food).
> Thus, if an onchain transfer takes a long time to settle, there is already
> risk of economic loss present.
>
> By moving activity offchain, we reduce pressure onchain and improve
> settlement speeds on both offchain and onchain, reducing risk of economic
> loss due to delay.
>
>
> > Two, competition from a different conflicting HTLC. A newer
> > HTLC might not get confirmed before an older HTL.
>
> I cannot make sense of this.
>
> You cannot create conflicting HTLCs.
>
Correct. Removing or Creating an HTLC is something that both channel
partners need to agree on. They may create multiple pending HTLCs as long
as there are enough funds, but creating conflicting HTLCs is not possible.
> >
> > I found out about a recent attack technique that sounds like it might be
> > similar called "flood and loot".
>
> Roughly, my understanding of Flood and Loot is to make a lot of
> uneconomically tiny HTLCs going through a target victim forwarding node.
> You make circular routes going from your own node back to yourself.
> Then you refuse to actually claim the HTLCs sent back to yourself.
>
No, the way I understand it is that an attacker, say Malleroy, routes a lot
of medium sized HTLC payments from his node to his node via a victim node,
say Alice's, and possibly other nodes.
Then Malleroy *accepts* the payments by publishing the hash on the
receiving end, so he gets all the sent funds on his receiving channel.
Malleroy's receiving node behaves completely honestly, and nobody can prove
that it belongs to the attacker.
Finally when Alice claims her HTLC by presenting the hash, Malleroy just
ignores the claim. Now Alice, the victim, is forced to close the channel
to prevent the HTLC to timeout. If Malleroy does it with multiple victims
at exactly the same time, they will all compete with each other. The
victims cannot increase the fee for the HTLC claiming transaction, because
they are the ones who force-closed the channel. CPFP doesn't work, because
their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can
claim the still pending HTLCs using an RBF transaction.
So it is Alice who has to force close, which puts her at a big disadvantage.
Malleroy will have to pay the lightning fees, but they are negligible. The
fee for the on-chain force-close transaction (with the HTLC outputs) is
paid by whoever opened the channel. AFAIK the fee for the HTLC resolving
transactions is paid by whoever claims the HTLC. In this scenario it is
paid from Alice's money. If Malleroy opened the channel, he risks losing
some funds to on-chain fees. On the other hand the one who pays the fee
controls the fee. He could negotiate a very low fee (say a cent per HTLC),
when the network is idle and then wait for a natural congestion before
starting the attack, giving him a low risk with high success probability.
Every HTLC he can claim after timeout is profit.
Regards,
Jochen
[-- Attachment #2: Type: text/html, Size: 4930 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
@ 2020-07-15 20:56 99% ` Russell O'Connor
2020-07-15 21:05 99% ` Greg Sanders
0 siblings, 1 reply; 47+ results
From: Russell O'Connor @ 2020-07-15 20:56 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> That brings me to Matt's point: there is no need to do this right now. We
> can simply amend BIP173 to only permit length 20 and length 32 (and only
> length 20 for v0, if you like; but they're so far apart that permitting
> both shouldn't hurt), for now. Introducing the "new" address format (the
> one using an improved checksum algorithm) only needs to be there in time
> for when a non-32-byte-witness-program would come in sight.
>
As a prerequisite to taproot activation, I was looking into amending BIP173
as stated above. However after reviewing
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
it seems that insertions of 5 characters or more is "safe" in the sense
that there is low probability of creating a valid checksum by doing so
randomly.
This means we could safely allow witness programs of lengths *20*, 23, 26,
29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses of
length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also support a
set of shorter addresses, but given the lack of entropy in such short
addresses, it is hard to believe that such witness programs could be used
to secure anything. I'm not sure what the motivation for allowing such
short witness programs was, but I'm somewhat inclined to exclude them from
the segwit address format.
Given that we would only be able to support one of 39 or 40 byte witness
programs, it is sensible to choose to allow 40 byte witness programs to be
addressable. This is the maximum witness program size allowed by BIP 141.
So my proposal would be to amend BIP173 in such a way to restrict "bc" and
"tb" segwit address formats to require witness programs be of size *20*,
23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2
and 40) would, of course, still be legal in accordance with BIP 141;
however they would be unaddressable by using this "bc" and "tb" prefix.
Another address format would be needed to support other witness sizes,
should the need ever arise.
--
Russell O'Connor
[-- Attachment #2: Type: text/html, Size: 2896 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
2020-07-15 20:56 99% ` Russell O'Connor
@ 2020-07-15 21:05 99% ` Greg Sanders
2020-07-15 21:11 99% ` Russell O'Connor
0 siblings, 1 reply; 47+ results
From: Greg Sanders @ 2020-07-15 21:05 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion; +Cc: Pieter Wuille
[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]
Can you make it clear what the bold vs not-bold numbers mean?
On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>> That brings me to Matt's point: there is no need to do this right now. We
>> can simply amend BIP173 to only permit length 20 and length 32 (and only
>> length 20 for v0, if you like; but they're so far apart that permitting
>> both shouldn't hurt), for now. Introducing the "new" address format (the
>> one using an improved checksum algorithm) only needs to be there in time
>> for when a non-32-byte-witness-program would come in sight.
>>
>
> As a prerequisite to taproot activation, I was looking into amending
> BIP173 as stated above. However after reviewing
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
> it seems that insertions of 5 characters or more is "safe" in the sense
> that there is low probability of creating a valid checksum by doing so
> randomly.
>
> This means we could safely allow witness programs of lengths *20*, 23,
> 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses
> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also
> support a set of shorter addresses, but given the lack of entropy in such
> short addresses, it is hard to believe that such witness programs could be
> used to secure anything. I'm not sure what the motivation for allowing
> such short witness programs was, but I'm somewhat inclined to exclude them
> from the segwit address format.
>
> Given that we would only be able to support one of 39 or 40 byte witness
> programs, it is sensible to choose to allow 40 byte witness programs to be
> addressable. This is the maximum witness program size allowed by BIP 141.
>
> So my proposal would be to amend BIP173 in such a way to restrict "bc" and
> "tb" segwit address formats to require witness programs be of size *20*,
> 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2
> and 40) would, of course, still be legal in accordance with BIP 141;
> however they would be unaddressable by using this "bc" and "tb" prefix.
> Another address format would be needed to support other witness sizes,
> should the need ever arise.
>
> --
> Russell O'Connor
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3752 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
2020-07-15 21:05 99% ` Greg Sanders
@ 2020-07-15 21:11 99% ` Russell O'Connor
0 siblings, 0 replies; 47+ results
From: Russell O'Connor @ 2020-07-15 21:11 UTC (permalink / raw)
To: Greg Sanders; +Cc: Bitcoin Protocol Discussion, Pieter Wuille
[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]
The bold values are the witness program lengths and address lengths of the
segwit v0 programs (BIP-141), which clearly need to be covered in my
proposed amendment. 32 bytes is also the proposed witness program length
for segwit v1 that would correspond to a taproot (BIP-341) program.
On Wed, Jul 15, 2020 at 5:05 PM Greg Sanders <gsanders87@gmail•com> wrote:
> Can you make it clear what the bold vs not-bold numbers mean?
>
> On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>>
>>> That brings me to Matt's point: there is no need to do this right now.
>>> We can simply amend BIP173 to only permit length 20 and length 32 (and only
>>> length 20 for v0, if you like; but they're so far apart that permitting
>>> both shouldn't hurt), for now. Introducing the "new" address format (the
>>> one using an improved checksum algorithm) only needs to be there in time
>>> for when a non-32-byte-witness-program would come in sight.
>>>
>>
>> As a prerequisite to taproot activation, I was looking into amending
>> BIP173 as stated above. However after reviewing
>> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
>> it seems that insertions of 5 characters or more is "safe" in the sense
>> that there is low probability of creating a valid checksum by doing so
>> randomly.
>>
>> This means we could safely allow witness programs of lengths *20*, 23,
>> 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses
>> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also
>> support a set of shorter addresses, but given the lack of entropy in such
>> short addresses, it is hard to believe that such witness programs could be
>> used to secure anything. I'm not sure what the motivation for allowing
>> such short witness programs was, but I'm somewhat inclined to exclude them
>> from the segwit address format.
>>
>> Given that we would only be able to support one of 39 or 40 byte witness
>> programs, it is sensible to choose to allow 40 byte witness programs to be
>> addressable. This is the maximum witness program size allowed by BIP 141.
>>
>> So my proposal would be to amend BIP173 in such a way to restrict "bc"
>> and "tb" segwit address formats to require witness programs be of size
>> *20*, 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes
>> (between 2 and 40) would, of course, still be legal in accordance with BIP
>> 141; however they would be unaddressable by using this "bc" and "tb"
>> prefix. Another address format would be needed to support other witness
>> sizes, should the need ever arise.
>>
>> --
>> Russell O'Connor
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 4416 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Thoughts on soft-fork activation
2020-07-14 20:46 99% ` Matt Corallo
@ 2020-07-17 2:58 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-17 2:58 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
Good morning list, BlueMatt and aj,
There is an idea circulating on IRC and elsewhere, which seems to be at least mildly supported by gmax and roconnor, which I will try to explain here.
(These are my words, so if there is some mistake, I apologize)
Basically:
* Deploy a BIP8 `lockinontimeout=true` `lockin=+42 months` (or 36 months, or 24 months) at next release.
* Pedanty note: BIP8 uses blockheights, not actual times.
* Then 1 year after `starttime`, ***if*** it is not activated yet:
* Discuss.
* If we think it is only because of miner apathy and user support seems good regardless, deploy a BIP91 reduced-threshold 80% that enforces the BIP8 bit.
* We hope that this will stave off independent attempts at a UASF with a faster timeout.
* If we think there are real reasons not to continue with Taproot as-is, deploy an abort: a softfork that disallows transaction outputs with `OP_1 <32-bytes>` `scriptPubKey` (other lengths and other versions are allowed).
This approximates what aj is proposing:
* Ultimately, we expect to deploy a BIP8 `lockinontimeout=true` that will have a timeout that ends +42 months after the first countdown, even with Modern Softfork Activation.
* The abort is roughly equivalent to the Modern Softfork Activation case where during the 6 month discussion period we decide not to deploy Taproot after all.
* The deployment of a BIP91 reduced-threshold 80% approximates what aj proposes, to reduce the threshold for activation later.
As I understand it, an advantage of this proposal is that we can deploy very quickly a relatively simple BIP8 `locktimeontimeout=true`, then continue debate on various details (is 80% too low? too high? are users actually deploying? are mining pools updating? etc) in parallel.
This lets the code into the hands of users where they can start deploying it and we can start getting better gauges on how well Taproot is supported.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services
@ 2020-07-17 6:02 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-17 6:02 UTC (permalink / raw)
To: Chris Belcher; +Cc: bitcoin-dev
Good morning Chris,
> On 13/06/2020 15:06, ZmnSCPxj wrote:
>
> > Good morning Chris,
> >
> > > Would it be fair to summarize the idea in this way:
> > > CoinSwappers can slow down the CoinSwap process which will give an
> > > opportunity for makers to use batching.
> >
> > I think so.
> > Regards,
> > ZmnSCPxj
>
> It's definitely a good idea. As well as improving privacy by pretending
> to be a service provider which uses batching, it may also be practical
> just because CoinSwap takers will want to slow down the process for
> greater privacy so that an adversary would have to search more of the
> blockchain to attempt to deanonymize them. Also, by being prepared to
> wait longer the takers will also save miner fees.
Despite the subject title, I have realized belatedly that the same kind of batching can be done by the taker as well.
For example, the taker can contact two makers in parallel to setup separate CoinSwaps with them.
Then the taker produces a transaction spending its funds and sending them out to two outputs.
If the taker uses P2PKH for receiving and change, and we use (via 2p-ECDSA) P2PKH 2-of-2 to anchor the swaps, then if both CoinSwap operations are successful, the transaction looks exactly like an ordinary pay-to-someone-and-get-back-change transaction.
Indeed, each of the two makers contacted, if they are not themselves colluding with each other, cannot really differentiate this from somebody doing a CoinSwap only with them, since the other output is indistinguishable from change.
I am uncertain how much extra privacy (or cheapness) this buys the taker, however.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
@ 2020-07-20 14:18 99% ZmnSCPxj
2020-07-21 1:27 99% ` ZmnSCPxj
2020-07-21 5:25 99% ` Andy Schroder
0 siblings, 2 replies; 47+ results
From: ZmnSCPxj @ 2020-07-20 14:18 UTC (permalink / raw)
To: bitcoin-dev
Introduction
============
An electrical relay is an electrically-controlled switch, often diagrammed as:
+-------------o
|
| \
| \
+--o o-------o
o---- |
) |
) |
) |
o---- |
The terminals at the left feed into a coil.
When electricity passes through the coil, it magnetizes a core, and the magnetism attracts a switch into a closed position, which would let electricity to pass through the terminals at the right.
This can be used to "turn on" or supply power to a different electrical device.
If no electricity is passing through the coil via the terminals on the left, then no electricity can pass through the terminals on the right, as the switch is an open position at default.
This is a fairly simple logic circuitry, upon which more complicated circuitry can be made.
Similarly, a Cryptographic Relay is a hardware electrical component that allows control of some electrical circuit.
It has two terminals which are the two terminals of a switch.
It can also be contacted, for example via Bluetooth, by an electronic computing device.
The Cryptographic Relay has a public key, which represents the current owner of the relay.
If the electronic device is able to provide a proof-of-knowledge of the private key (i.e. a signature) corresponding to the public key that the Cryptographic Relay knows, then it allows the switch to be controlled by that device.
Motivation
==========
Suppose I have a car I wish to sell to you, for Bitcoins.
This car, as it happens, has a Cryptographic Relay: it will only start its engine if it gets a signed message from me using a private key I have on my phone.
It knows my public key, and will only turn off and on at my command.
Now, you want to be able to know that by paying me Bitcoins, you get sole ownership of the car I am selling.
This is in fact, nothing more than a swap operation.
I have an asset, a car, and you have an asset, some Bitcoins.
We want to atomically swap one asset for the other asset, and those assets do not exist in a single asset-assignment system.
Paying Bitcoins For Cars Via Succinct Atomic Swaps
==================================================
Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which can be used to create an atomic swap between my car and your Bitcoins.
An important part of this Succinct Atomic Swap is that all timeouts are only in one asset-assignment system.
The original Succinct Atomic Swap discussion gives an example of swapping Bitcoins for Litecoins.
Each has its own distinct blockchain, which is a distinct distributed asset-assignment system.
A crucial part of the Succinct Atomic Swap is that all timelocks are only on one asset-assignment system.
The other asset-assignment system need not support anything other than assigning ownership of assets to (homomorphically additive) public keys.
This is important as a major simplification of the Cryptographic Relay:
The relay only needs to know its *current owner*, and does not need to know the current time!
Thus, in order for you to buy my car:
* You set up the Succinct Atomic Swap on the Bitcoin blockchain.
* We generate fresh private keys, then combine them via MuSig, and I transfer the ownership of the car to that MuSig public key.
* If I claim the funds, that atomically reveals my share of the private key to you, so you can claim the car using your private key plus my share and transfer the car to sole control of you.
* If I fail to claim the funds, then when you reclaim your funds at timeout, that atomically reveals your share of the private key to me, so that I can claim the car using my private key plus your share and transfer the car back to sole control of me.
This is in fact the same as the Succinct Atomic Swap example, except that instead of me swapping my Litecoins for your Bitcoins, I am swapping my Cryptographic Relay for your Bitcoins.
Cryptographic Relay Operations
==============================
Thus, a Cryptographic Relay needs to support only the following basic operations.
These operations are triggered by its owner sending a message, plus a signature verifiable by the public key, to the Cryptographic Relay.
(Cryptographer warning: if using Schnorr, the message hashed into the signature also has to include the public key that is signing it, since BIP32 nonhardened derivation allows a Schnorr signature created by one child private key to be trivially malleated into a signature for the same message by a sibling private key; this does not exist in ECDSA due to its nonlinearity.
message sends need not include the public key, it can be added by the cryptographic relay since it has to know the public key of the owner anyway.
Of note is that the bip-340 description of Schnorr includes the public key in the hash operation of signatures as well, and does not require this.)
The only operations necessary are:
1. Turn on.
2. Turn off.
3. Transfer ownership to new pubkey ___.
Due to Succinct Atomic Swaps not requiring any kind of timelock on one asset-assignment system, the Cryptographic Relay need not have any concept of time, as mentioned above, and transfer of ownership can be done by a simple message signed by the current owner transferring ownership to a new public key.
(Cryptographer warning: turn-on/turn-off messages should be challenge-response: the Cryptographic Relay requests signing with a unique nonce included in the message, otherwise previous messages can be captured by third parties and replayed; ownership-transfer messages should probably also include a nonce, or otherwise we could require non-reuse of keys.
This can be implemented with a 64-bit incrementing nonce, which should work for the practical lifetime of any Cryptographic Relay.)
(Cryptographer warning: similarly, ownership-transfer messages should probably be indexed as well with an incrementing nonce, otherwise key reuse would allow signature replay; similarly again, each Cryptographic Relay should have a UUID that is included in message hashes, as otherwise key reuse would allow signature replay for commands to one device to be repeated for another device.)
Lightning
=========
Unfortunately, it seems not possible to transport Succinct Atomic Swap constructions over the Lightning Network.
Succinct Atomic Swaps have an asymmetric setup, unlike the traditional HTLC-based atomic swaps.
This asymmetry makes it difficult to reason about how a forwarding node on the Lightning Network would be able to accept a Succinct Atomic Swap and then send out another Succinct Atomic Swap.
An observation to make is that the Bitcoin-side construction in the Succinct Atomic Swap description has the following branches:
* B gets the money, and A learns a secret from B.
* After a timeout, A gets the money back, and B learns a secret from A.
Unfortunately, the above construction, while instantiatable in a single channel (any absolute-timelock contract enforceable on a blockchain can be instantiated in a channel anchored in that blockchain), cannot be safely *forwarded* over the Lightning Network in a sequence of channels forming a route.
This is because we need to have a different timeout at each forwarding hop, in order to allow a forwarding node enough time to discover an event and react accordingly.
This means that each forwarding node has to have a shorter timeout on its outgoing contract than its incoming contract.
But in the half-Succinct-Atomic-Swap contract, the forwarding node needs to provide a secret in order to reclaim the funds at the timeout.
And it can only discover that secret at the later timeout of the incoming contract.
Thus, it is not safe for the forwarding node to forward any half-Succinct-Atomic-Swap contract.
Thus, we either:
* Prevent old, low-value cryptographic cars from being bought using Lightning, reducing their economic veolocity and preventing moon and lambos.
* OR, we give the Cryptographic Relay a notion of time which makes it compatible with PTLCs that can be routed over Lightning.
In essence, the PTLC "goes over one more hop", this time transferring ownership of the Cryptographic Relay.
A Cryptographic Notion of Time
==============================
Time stops for no one; it will not stop for thee.
Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.
Now, we can observe that block header hashes are, in fact, low-entropy.
This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.
Now, we can observe that temperature is largely itself also an expression of entropy.
Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature.
Overall, the temperature differential across the universe decreases in the direction of future time.
However, it is possible to implement a sort of Maxwell's Demon.
Maxwell's Demon is an entity that guards a hole between two containers containing air.
If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.
Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.
Of course, we already have implementations of Maxwell's Demon.
We call such implementations "refrigerators".
Refrigerators, to do their magic, must consume energy and emit heat.
Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.
We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold.
But we know that refrigerators, to do their work, must consume energy and emit heat.
And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.
Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.
And since we know that:
* The future is where the universal entropy is larger than the past.
* Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).
...then we know that a longer proof-of-work header chain represents more actual physical time passing.
Proof-of-work is therefore also an unforgeable proof-of-time-passing.
Thus, all we need for a cryptographically-secure *measure of time* is a header chain.
Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.
This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
Thus, it must use this cryptographic notion of time.
Giving Cryptographic Relays a Notion of Time
============================================
In order to implement timelocks, we can add an `nLockTime` field to ownership-transfer messages for the Cryptographic Relay.
On manufacturing a Cryptographic Relay, the manufacturer stores in unchangeable memory (e.g. burned diode non-erasable PROMs) the block header hash of a sufficiently-deep block (for example, one that has been buried for 6 or so difficulty adjustment periods), its blockheight, and the difficulty target for the adjustment period.
If the Cryptographic Relay receives an ownership-transfer message with `nLockTime` greater than this recorded block height, it demands a header chain rooted at the prerecorded block up to the specified `nLockTime`.
It then validates that the header chain has sufficient difficulty for each adjustment period covered, and also emulates the difficulty adjustment at appropriate blockheights.
This is sufficient proof to it that time has passed since its manufacture, as a header chain is a cryptographic proof of time passing.
This allows me to sell a cryptographic car to you, over Lightning, by this ritual:
* First, we generate fresh keypairs and their combined MuSig pubkey.
* We perform a MuSig signing operation, signing an ownership-transfer message with a future `nLockTime`, transferring ownership from the MuSig pubkey back to my unilateral pubkey.
* I transfer control of the car to the MuSig pubkey.
* We partially perform a second MuSig signing operation, signing an ownership-transfer message with a 0 `nLockTime`, transferring ownership from the MuSig pubkey back to you, but pausing after the `R` exchange.
* Specifically, after the `R` exchange, you generate the point corresponding to my share of the signature `s`, which you can get from my `R`, your `R`, my public key, and your public key, and the message we agreed on.
* I generate an invoice for the above signature share point (i.e. pay for signature).
* You pay the invoice, making sure that the maximum cltv-delta for the outgoing payment does not exceed the pre-agreed timeout (minus some time margin you deem safe).
Then:
* If you successfully pay the invoice (i.e. I release my share of the signature) you can now complete the signature for the transfer to your unilateral control.
* If you are unable to pay the invoice, then once the future blockheight is reached, I download the Bitcoin block header chain and feed it and the backout ownership-transfer message to the car and regain control of my vehicle.
This provides Lightning-with-PTLCs compatibility (which we expect to be deployed on the network anyway), while still requiring relatively low resources on the Cryptographic Relay hardware (at the cost that timelocked backouts require much bandwidth; but since such backouts are expected to be rare, this may be an acceptable tradeoff).
A Cryptographic Relay accepting this notion of time can continue to be used with Succinct Atomic Swaps, by using ownership-transfer messages with a 0 `nLockTime`, with the advantage that backouts need not download a block header chain to the Cryptographic Relay.
A Case Against Blockchain Proliferation
=======================================
We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.
This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.
However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.
Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.
And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.
On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.
The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.
Tr\*st in manufacturers can be acquired, at very high expense, by using cut-and-choose: get a number of Cryptographic Relays, randomly select some of them, then open those and analyze if there are any backdoors, then utilize the rest if the randomly-opened ones do not have any discovered backdoors or other security issues.
Delegated Operators
===================
Another useful capability to add to Cryptographic Relays would be to allow adding operators, which are additional public keys that can turn it on or off, but cannot authorize a transfer of ownership or the addition of new operators.
Only the owner of the Cryptographic Relay can add or delete operators.
For example, suppose you, the buyer of my cryptographic car, represent a typical family share-owned between you and all of your husbands.
Then when purchasing the car from me, you can transfer ownership of the car to a MuSig n-of-n between you and your husbands, rather than unilateral control of yourself.
Of course, practically speaking, only one of you or your husbands can operate the car at once.
Thus, while the ownership of the vehicle is an n-of-n MuSig, you can assign individual keys of yourself and each of your husbands, as operators of the car.
The Cryptographic Relay would need to allocate a fixed amount of space for the number of allowed operators, thus imposing a practical limit on the number of husbands you can have simultaneously.
Unfortunately, the Cryptographic Relay cannot store an arbitrary number of public keys, thus there are limits on the number of husbands a human can have.
Whenever an ownership transfer is performed, all operators are deleted, thus preventing one of the previous operators attempting to start the car and drive it off even though it is semantically owned by someone else.
A car purchased by an extended family, such as a company, might be owned by a k-of-n of the stakeholders of the company, and then employees of the company might be assigned as operators.
Practical Deployment
====================
By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).
In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.
Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
Similarly, many existing cars can be started without keys by hot-wiring.
Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.
A Cryptographic Relay is a simple device:
* The design of the device is simple, requiring support for only a few operations.
* The interface of the device is simple: it is only a switch, and easy to integrate into more complex applications.
The switch may be used as the route for the power supply, or it may be used simply for an electrical connection that is detected by some control system of the appliance to know whether it should act as "on" or "off".
This simplicity and generality allows simple interfacing with a variety of electrical devices.
The intent is that:
* It is easy to implement and subsequently manufacture the device, so that risks of backdoors being installed by centralized manufacturers is mitigated by having multiple Cryptographic Relay manufacturers competing and incentivized to discover backdoors and other security failures of their competitors.
* It is easy to integrate the device into the design of a more complex device intended for use by an end-user.
It is also easy to integrate the device, post-design, to a more complex existing device that did not include it.
Collateralizing Cryptographic Relay Devices
===========================================
Giving Cryptographic Relays a notion of time allows them to be used in more complicated contracts.
Suppose after purchasing the cryptographic car from me, you and your husbands find yourselves in tight financial straits.
You and your husbands might then want to take a loan from some entity.
Obviously, that entity will not simply loan out precious Bitcoins unless you promise to pay it back with *more* Bitcoins than what it gave out.
And that entity might want to accept your cryptographic car as collateral for the loan, so that if you are unable to pay, the entity can partially recoup losses by reselling your cryptographic car.
With `SIGHASH_ANYPREVOUT` and Taproot, it becomes possible to trustlessly arrange a collateralized loan on the cryptographic car (to the extent the loan shark tr\*sts that none of you or any of your husbands have replaced the Cryptographic Relay with a backdoored device, at least).
The loan shark arranges a loan in a multi-step process involving multiple PTLC-like constructions:
* First, all of you (you and your husbands, and the loan shark) generate two fresh keypairs.
* Call the first the "loan-out" keypair.
* Call the second the "loan-payback" keypair.
* You generate (but do not sign!) a command to transfer control of the car from you to a MuSig(you, your husbands ..., loan shark) using the "loan-out" pubkeys.
* Generate the initial backout command, which transfers from the MuSig loan-out pubkey above, back to you and your husbands, but with an `nLockTime` in the future.
Get a complete signature for this command with the loan shark and your husbands and you.
* This backout timeout period should be short, and is needed only if the loan shark suddenly aborts before it hands over the loan to you.
* Sign the transfer of the car from you to the MuSig loan-out and feed it to the car.
* Generate (but do not sign!) the collateralization command, which transfers from the MuSig loan-out pubkey, to a new MusSig(you, your husbands ..., loan shark) using the "loan-payback" pubkeys.
* Generate the collateral-claim command, which transfers from the MuSig loan-payback pubkey to the loan shark, but with an `nLockTime` a little after the due date of your loan.
Generate a complete signature for this command to the loan shark, which the loan shark will now hold and use in case you do not pay back the loan.
* Generate the collateral-reclaim command, which transfers from the MuSig loan-payback pubkey back to you and your husbands.
Generate a partial signature for this command from you and your husbands, but with a missing share from the loan shark, and keep this partial signature.
* Generate a Taproot address (called the loan-payback Taproot address) with two SCRIPT branches, with an internal public key equal to the loan-payback pubkey.
* One SCRIPT branch allows signing by the internal public key with `SIGHASH_ANYPREVOUT`.
* The other SCRIPT branch imposes a short `OP_CHECKSEQUENCEVERIFY` timeout, and claiming by the MuSig of you and your husbands.
* Generate loan-payback Bitcoin transaction, which spends using a `SIGHASH_ANYPREVOUT` signature on the first branch of the above Taproot address, an amount equal to your loan plus interest, and sending unilateral control to the loan shark.
Demand an adaptor signature for this transaction, which would reveal to you the loan shark signature share of the collateral-reclaim command.
Then provide the signature shares for you and your husband to the loan shark.
* If the loan shark completes this signature and reclaims the loan plus interest, you learn the share to complete the collateral-reclaim command and thereby reclaim your car after paying back the loan.
* Now the loan shark creates (but does not sign!) the loan-out transaction, which pays out the MuSig loan-out pubkey the amount being loaned.
* Generate the loan-out-revert transaction, which spends the loan-out transaction and pays it back to the loan shark, but with an `nLockTime` in the future, nearer than the `nLockTime` of the initial backout command.
Sign this transaction with you and your husbands and the loan shark.
* The loan shark generates a partial signature for the collateralization command, missing the shares from you and your husbands.
* Generate the loan-out-claim transaction, which spends the loan-out transaction and pays it to you and your husbands.
The loan shark will demand an adaptor signature for this transaction, which lets it learn the sum of the missing signatures shares for the collateralization command.
Then the loan shark provides its share of the signature for the loan-out-claim transaction.
* The loan shark signs the loan-out transaction and broadcasts it.
* You now complete the signature for the loan-out-claim transaction and broadcast it.
The loan shark learns the missing signature shares for the collateralization command and performs it, locking your car into collateralization (where it cannot be transferred unless you, your husbands, and the loan shark agree).
With the loan-out-claim transaction valid, you can now take the loan.
Then, if you are able to pay back the loan before the due date:
* Send the loan amount plus interest, exactly, to the loan-payback Taproot address.
* If the loan shark accepts the payback of the loan, it reanchors the loan-payback Bitcoin transaction and completes the signature, then claims the paid back loan.
* With the loan-payback signature completed, you learn the partial signature needed to complete the signature for the collateral-reclaim command, and you can now feed it to the car and regain ownership over it.
* If the loan shark does not accept payback of the loan, you can at least recover the loan and interest by the second branch of the loan-payback Taproot address.
If you are unable to pay back the loan:
* The collateral-claim command becomes valid a little after the loan due date, and the loan shark takes unilateral possession of your car to recoup its losses.
The above uses onchain Bitcoins.
Similar setups may be possible over Lightning (there is no need for a `SIGHASH_ANYPREVOUT` in this case, as the loan shark may issue a long-lived invoice that lets you learn its signature share for the collateral-reclaim command signature).
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
2020-07-20 14:18 99% [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware ZmnSCPxj
@ 2020-07-21 1:27 99% ` ZmnSCPxj
2020-07-21 5:25 99% ` Andy Schroder
1 sibling, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-21 1:27 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
Good morning list,
Andy Schroder shared a mildly related link: http://andyschroder.com/DistributedCharge/
The above project does not use the Cryptographic Relay.
Briefly, it is a rentable charging station for electric cars.
I observed, however, that a rentable Cryptographic Relay device could be implemented using Cryptographic Relay features:
* Support for MuSig (by use of Schnorr signatures).
* Timelocks (by use of block header chains).
* Delegated operators.
> Suppose you own a Cryptographic Relay controlling a charger for electrical cars.
> And I wish to rent this charger for some time so I can charge my electrical car.
>
> This rental contract can be done by this ritual:
>
> * We generate two fresh keypairs.
> * Call the first keypair the "rent-transfer" keypair.
> * Call the second keypair the "rental-period" keypair.
> * You generate, but do not sign, a rent-transfer command to transfer ownership from your unilateral ownership to the MuSig of our rent-transfer keys.
> * We generate an initial backout command to transfer ownership from the MuSig rent-transfer key back to your control, but with an `nLockTime` in the close future.
> We sign this command.
> * We generate a rental-start command to transfer ownership from the MuSig rent-transfer key to our MuSig rental-period key.
> I create a partial signature, missing only your share.
> * We generate a command to add me as a delegated operator of the device, authorized by the MuSig rental-period key.
> * We generate a rental-end command to transfer ownership from the MuSig rental-period key, back to your unilateral control, with an `nLockTime` equal to the end of the rental period.
> We sign this command.
> * Then, I create (but do not sign!) a rent-funding Bitcoin transaction for the rent, paying to the Musig rent-transfer key.
> * We generate a rent-reclaim Bitcoin transaction spending the above rent-funding Bitcoin transaction, sending the funds back to my unilateral control, but with an `nLockTime` in the future but less than the timeout of the initial backout command.
> We sign this transaction.
> * You sign the rent-transfer command and feed it to the device.
> * We generate a rent-claim Bitcoin transaction spending the above rent-funding Bitcoin transaction, sending the funds to your unilateral control.
> I demand an adaptor signature, such that I can learn your share of the signature of the rental-start command.
> Then I provide a partial signature to you.
> * You complete the rent-claim Bitcoin transaction signature, claiming the rental fee.
> * I get the completed rental-start command signature and send it to the device, transferring ownership of the device to our MuSig rental-period pubkey.
> * I send the command to add me as an operator of the device, letting me use the device as I see fit, but not transfer ownership to anyone else.
> * When the rental period ends, you send the rental-end command to the device and turn it off so I can no longer use it.
>
> The above can probably also be done with the Bitcoin-side payments done via Lightning-with-PTLC.
> It requires Taproot, but does not require `SIGHASH_ANYPREVOUT`.
We can also consider the case where the renter of the device wishes to return it early, for a partial refund of the total rent (or equivalently, for the renter to rent in units of smaller time and just extending the rental period as needed).
> As the ownership of the device is in a 2-of-2 between the renter and the "true owner", they can, after having a meeting of minds, arrange for an early return command conditional on a partial refund of the original rent.
> Again, there is simply a need for pay-for-signature, with the renter partial-signing a command to return the device ownership early, which if completed by the owner, completes the signature to refund the original rent.
>
> Alternately, the rent may pay for a short rental period, and to extend the rental period, the 2-of-2 between the nenter and "true owner" on the device is "reseated" (i.e. fresh keypairs to generate a fresh 2-of-2 are created and ownership transferred to the new 2-of-2) which invalidates the previous timeout, and moves to a later timeout.
> The "re-rental" command which moves the ownership from the previous 2-of-2 to the next 2-of-2 is partially signed by the renter, and to complete the signature, the renter pays for the signature share from the owner.
> (this is done after setting up the command to make the renter a delegated operator and the command to let the owner re-acquire unilateral ownership of the device, I elide those steps here.)
> The pay-for-signature can be done over Lightning as well.
Now, suppose the device being rented out is in fact a smart domicile, which can be locked/unlocked by the owner/operator of a Cryptographic Relay.
Typically, when renting out domiciles, a deposit is involved, where:
* The tenant pays out the rent plus the deposit.
* The landlady may keep the deposit in case of egregious damage to (or other abuse of) the domicile.
The construction of a rent-with-deposit contract is actually similar to the construction of the earlier given collateralized loan:
> * The "loan shark" position is taken up by the "renter".
> * The "loaner" position is taken up by the "landlady" of the device being rented out.
> * The "loan shark" also asks for a command to add them as a delegated operator of the device.
> * Instead of the payback amount being larger than what the loan shark/renter pays to the loaner/landlady, it is smaller, with the lower payback amount representing the deposit.
>
> In this particular case, the contractors need not use `SIGHASH_ANYPREVOUT`, instead the landlady can give a PTLC on the deposit with the deposit being funded from the loan payout transaction (which would be a rent+deposit-payout transaction).
(note: missing in the above is the detail that at the end of the contract period, ownership of the device goes back to the landlady/loaner position, as opposed to the collateralized-loan case where it goes to the loan shark position.)
Perhaps smart contract languages should have PTLCs and partial signatures as primitives and be written in a compositional/declarative style, rather than some Turing-complete mess, because PTLCs are cool.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Implementing Investment Aggregation
@ 2020-07-21 3:40 99% ZmnSCPxj
2020-07-21 5:23 99% ` esnierde
0 siblings, 1 reply; 47+ results
From: ZmnSCPxj @ 2020-07-21 3:40 UTC (permalink / raw)
To: bitcoin-dev
Introduction
============
In a capitalist economic system, it is allowed for an entity to lend money out to another entity, as long as both agree upon the conditions of the loan: how long, how much interest, any collateral, etc.
This is a simple extension of basic capitalist economic thinking: that the owner of funds or other capital, is the one who should decide how to utilize (or not utilize) that capital, including the decision to lend (or not lend).
It has been observed as well that groups of people may have relatively small savings that they can afford to put into investment (i.e. loaning out for an interest rate), but as the technological capabilities of our shared civilization have expanded, the required capital to create new businesses or expand existing ones have grown much larger than most single individuals can invest in.
Thus, coordinators that aggregate the savings of multiple individuals, and then lend them out for interest to new or expanding businesses, have also arisen, in order to take advantage of the larger return-on-investment of more capital-intensive but high-technology businesses, capturing the long tail of small investors.
Traditionally, we call these coordinators "banks".
However, this typically involves delegating the work of judging whether a business proposal is likely to give a return on investment, or not, to the coordinator itself.
Further, the coordinator typically acts as a custodian of the funds, thus adding the risk of custodial default to the small-time investors in addition to loan default.
(In this view-point, central banks that provide fiscal insurance in case of loan default by printing new money, are no different from custodial default, as they degrade the monetary base in doing so.)
This writeup proposes the use of features that we expect to deploy at some point in the future, to allow for a non-custodial coordinator of multiple small investors.
This is not a decentralized system, as there is a coordinator; however, as the coordinator is non-custodial, and takes on the risk of default as well, the risk is reduced relative to a centralized custodial solution.
Note that custodiality is probably a much bigger risk than centralization, and a centralized non-custodial probably has fewer risks than a decentralized custodial setup.
In particular, a decentralized custodial setup can be emulated by a centralized custodial setup using sockpuppets, and without any decent sybil protection (which can be too expensive and price out investments by the long tail of small investors, thus leading to centralization amongst a few large investors anyway), is likely no better than a centralized custodial setup.
Focusing on non-custodiality rather than decentralization may be a better option in general.
A group of small investors may very well elect a coordinator, and since each investor remains in control of its funds until it is transferred to the lendee, the coordinator has no special power beyond what it has as one of the small investors anyway, thus keeping decentralization in spirit if not in form.
Non-custodial Investment Aggregation
====================================
In principle, if a small investor finds a potentially-lucrative business that needs capital to start or expand its operation, and promises to return the loaned capital with interest later, then that small investor need not store its money with anyone else: it could just deal with the business itself directly.
However, the small investor still needs to determine, for itself, whether the business is expected to be lucrative, and that the expected return on investment is positive (i.e. the probability of non-default times (1 plus interest rate) is greater than 1, and the absolute probability of non-default fits its risk profile).
We will not attempt to fix this problem here, only the requirement (as with the current banking system) to trust some bank **in addition to** trusting the businesses that are taking on loans to start/expand their business.
(again: not your keys not your coins applies, as always; investors are taking on risk of default.)
The coordinator need only do something as simple as find a sufficiently large set of entities that are willing to indicate their Bitcoin UTXOs as being earmarked for investment in a particular business.
The coordinator, upon finding such a set, can then create a transaction spending those UTXOs and paying unilaterally to the business taking the loan.
The business provides proof that the destination address is under its unilateral control (so that investors know that they only need to trust that the business itself will do everything in its power to succeed and pay back the loan, without having additional trust in the coordinator to hold their funds in custody).
Then the individual investors sign the transaction, releasing their funds to the business.
However, the issue now arises: suppose the business succeeds and is able to pay back its loan.
How does the business pay back the loan?
Thus, prior to the investors ever signing the loan-out transaction, they first prepare a loan-payback transaction.
This loan-payback transaction spends from a multisignature of all the investors, equal in value to the loan amount plus agreed-upon interest, and distributes the money to each of the involved investors.
Crucially, this loan-payback transaction is signed with a `SIGHASH_ANYPREVOUT` signature.
Now, in order for the business to pay back its loan, it only needs to gather enough Bitcoins to pay back the loan, and pay back the exact amount to the multisignature address of the investors.
Then, any of the investors can reclaim their funds, plus interest, by re-anchoring the loan-payback transaction to this transaction output and broadcasting it.
The coordinator, for its services, may extract a fee from the loan-payback transaction that all the investors can agree to; thus, it takes on as well the risk of default by the business (the coordinator exerts effort to locate investors and encourage them to invest, and would lose the fee paid for its efforts if the business it is proposing as a good investment does not pay back), which seems appropriate if it also serves as a basic filter against bad business investments.
Finally, by working in Bitcoin, it cannot have a lender of last resort, and thus must evaluate possible business investments as accurately as possible (as default risks its fee earnings).
(investors also need to consider the possibility that the purported "business" is really a sockpuppet of the coordinator; the investors should also evaluate this when considering whether to invest in the business or not, as part of risk of default.)
(the above risk is mitigated somewhat if the investors identify the business first, then elect a coordinator to handle all the "paperwork" (txes, transporting signatures/PSBTs, etc.) by drawing lots.)
Thus, ***if*** the business is actually able to pay back its loan, the coordinator is never in custodial possession of funds.
Cross-business Aggregation
==========================
Nothing in the above setup really changes if the investors would prefer to spread their risk by investing sub-sections of their savings into multiple different businesses.
This gives somewhat lower expected returns, but gives some protection against complete loss, allowing individual investors to adjust their risk exposure and their desired expected returns.
The batch transaction that aggregates the allocated UTXOs of the investors can pay out to multiple borrowing businesses.
And each business can be given a loan-payback address, which is controlled by the investors that extended their loans.
Investors generate an aggregate loan-payback transaction and signature for each business they invest in.
Collateralized Loans
====================
As observed in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018053.html, a Cryptographic Relay would allow collateralized loans.
Nothing prevents the "loan shark" in the collateralized loan example from being a MuSig of multiple small investors.
Practically, a coordinator would help facilitate construction of the necessary transactions and interaction with the loanee, but as long as ownership remains controlled by the individual investors, there should not be any custodial issues.
Of course, if the loan defaults, then the collateral needs to be sold in order to recoup the loss incurred in loan default case.
Coordinating this sale amongst the multiple small investors is now potentially harder.
An additional service may be willing to pre-allocate Bitcoin funds into a timelocked contract, where the amount can be claimed conditional on transfer of the ownership of the collateral to the service in the future, or if the fund is not so claimed, to be returned to the service with the collateral not claimed (as it might have been reclaimed by the loaner after successfully paying back its loan).
This additional service earns by arbitraging the time preference: in case of default, the investors would prefer to recoup their financial losses quickly, while the service is now in possession of the collateral that it can resell later at a higher rate.
Note that these are all operations that traditional banks perform; again, this idea simply removes the necessity for custodial holding of funds, in the way traditional banks do.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Implementing Investment Aggregation
2020-07-21 3:40 99% [bitcoin-dev] Implementing Investment Aggregation ZmnSCPxj
@ 2020-07-21 5:23 99% ` esnierde
2020-07-21 16:28 99% ` ZmnSCPxj
0 siblings, 1 reply; 47+ results
From: esnierde @ 2020-07-21 5:23 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11053 bytes --]
Good Day ZmnSCPxj,
Thanks for sharing the idea! I read through the doc and have some concerns
that might be off the topic or outside the scope. Please bear with me.
The traditional banking system provides more than custodial holding of
funds in terms of lending & borrowing. One important function is to match
long term investments with short or variable term deposits. Alice might be
willing to make investments at time 0, but some emergency occurs and she
may need (part of) her bitcoins back at time 1 before the loan due date.
Also, in the banking system, there are usually sophisticated risk analysis
systems covering formulas, due diligence, and funds for loan defaults.
Banks can reinvest partial of what they namely have and obtain profits to
cover possible losses when borrowers cannot pay back 100%. In this way,
they are more resilient to defaults & change of collaterals' value, and
borrowers might be able to leverage 1 unit worth of collateral to get 3
units fund instead of 1.
Thank you,
Hilda
On Mon, 20 Jul 2020 at 23:40, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Introduction
> ============
>
> In a capitalist economic system, it is allowed for an entity to lend money
> out to another entity, as long as both agree upon the conditions of the
> loan: how long, how much interest, any collateral, etc.
> This is a simple extension of basic capitalist economic thinking: that the
> owner of funds or other capital, is the one who should decide how to
> utilize (or not utilize) that capital, including the decision to lend (or
> not lend).
>
> It has been observed as well that groups of people may have relatively
> small savings that they can afford to put into investment (i.e. loaning out
> for an interest rate), but as the technological capabilities of our shared
> civilization have expanded, the required capital to create new businesses
> or expand existing ones have grown much larger than most single individuals
> can invest in.
>
> Thus, coordinators that aggregate the savings of multiple individuals, and
> then lend them out for interest to new or expanding businesses, have also
> arisen, in order to take advantage of the larger return-on-investment of
> more capital-intensive but high-technology businesses, capturing the long
> tail of small investors.
> Traditionally, we call these coordinators "banks".
>
> However, this typically involves delegating the work of judging whether a
> business proposal is likely to give a return on investment, or not, to the
> coordinator itself.
> Further, the coordinator typically acts as a custodian of the funds, thus
> adding the risk of custodial default to the small-time investors in
> addition to loan default.
> (In this view-point, central banks that provide fiscal insurance in case
> of loan default by printing new money, are no different from custodial
> default, as they degrade the monetary base in doing so.)
>
> This writeup proposes the use of features that we expect to deploy at some
> point in the future, to allow for a non-custodial coordinator of multiple
> small investors.
>
> This is not a decentralized system, as there is a coordinator; however, as
> the coordinator is non-custodial, and takes on the risk of default as well,
> the risk is reduced relative to a centralized custodial solution.
>
> Note that custodiality is probably a much bigger risk than centralization,
> and a centralized non-custodial probably has fewer risks than a
> decentralized custodial setup.
> In particular, a decentralized custodial setup can be emulated by a
> centralized custodial setup using sockpuppets, and without any decent sybil
> protection (which can be too expensive and price out investments by the
> long tail of small investors, thus leading to centralization amongst a few
> large investors anyway), is likely no better than a centralized custodial
> setup.
> Focusing on non-custodiality rather than decentralization may be a better
> option in general.
>
> A group of small investors may very well elect a coordinator, and since
> each investor remains in control of its funds until it is transferred to
> the lendee, the coordinator has no special power beyond what it has as one
> of the small investors anyway, thus keeping decentralization in spirit if
> not in form.
>
> Non-custodial Investment Aggregation
> ====================================
>
> In principle, if a small investor finds a potentially-lucrative business
> that needs capital to start or expand its operation, and promises to return
> the loaned capital with interest later, then that small investor need not
> store its money with anyone else: it could just deal with the business
> itself directly.
>
> However, the small investor still needs to determine, for itself, whether
> the business is expected to be lucrative, and that the expected return on
> investment is positive (i.e. the probability of non-default times (1 plus
> interest rate) is greater than 1, and the absolute probability of
> non-default fits its risk profile).
> We will not attempt to fix this problem here, only the requirement (as
> with the current banking system) to trust some bank **in addition to**
> trusting the businesses that are taking on loans to start/expand their
> business.
>
> (again: not your keys not your coins applies, as always; investors are
> taking on risk of default.)
>
> The coordinator need only do something as simple as find a sufficiently
> large set of entities that are willing to indicate their Bitcoin UTXOs as
> being earmarked for investment in a particular business.
>
> The coordinator, upon finding such a set, can then create a transaction
> spending those UTXOs and paying unilaterally to the business taking the
> loan.
> The business provides proof that the destination address is under its
> unilateral control (so that investors know that they only need to trust
> that the business itself will do everything in its power to succeed and pay
> back the loan, without having additional trust in the coordinator to hold
> their funds in custody).
> Then the individual investors sign the transaction, releasing their funds
> to the business.
>
> However, the issue now arises: suppose the business succeeds and is able
> to pay back its loan.
> How does the business pay back the loan?
>
> Thus, prior to the investors ever signing the loan-out transaction, they
> first prepare a loan-payback transaction.
> This loan-payback transaction spends from a multisignature of all the
> investors, equal in value to the loan amount plus agreed-upon interest, and
> distributes the money to each of the involved investors.
> Crucially, this loan-payback transaction is signed with a
> `SIGHASH_ANYPREVOUT` signature.
>
> Now, in order for the business to pay back its loan, it only needs to
> gather enough Bitcoins to pay back the loan, and pay back the exact amount
> to the multisignature address of the investors.
> Then, any of the investors can reclaim their funds, plus interest, by
> re-anchoring the loan-payback transaction to this transaction output and
> broadcasting it.
>
> The coordinator, for its services, may extract a fee from the loan-payback
> transaction that all the investors can agree to; thus, it takes on as well
> the risk of default by the business (the coordinator exerts effort to
> locate investors and encourage them to invest, and would lose the fee paid
> for its efforts if the business it is proposing as a good investment does
> not pay back), which seems appropriate if it also serves as a basic filter
> against bad business investments.
> Finally, by working in Bitcoin, it cannot have a lender of last resort,
> and thus must evaluate possible business investments as accurately as
> possible (as default risks its fee earnings).
>
> (investors also need to consider the possibility that the purported
> "business" is really a sockpuppet of the coordinator; the investors should
> also evaluate this when considering whether to invest in the business or
> not, as part of risk of default.)
>
> (the above risk is mitigated somewhat if the investors identify the
> business first, then elect a coordinator to handle all the "paperwork"
> (txes, transporting signatures/PSBTs, etc.) by drawing lots.)
>
> Thus, ***if*** the business is actually able to pay back its loan, the
> coordinator is never in custodial possession of funds.
>
> Cross-business Aggregation
> ==========================
>
> Nothing in the above setup really changes if the investors would prefer to
> spread their risk by investing sub-sections of their savings into multiple
> different businesses.
> This gives somewhat lower expected returns, but gives some protection
> against complete loss, allowing individual investors to adjust their risk
> exposure and their desired expected returns.
>
> The batch transaction that aggregates the allocated UTXOs of the investors
> can pay out to multiple borrowing businesses.
> And each business can be given a loan-payback address, which is controlled
> by the investors that extended their loans.
> Investors generate an aggregate loan-payback transaction and signature for
> each business they invest in.
>
> Collateralized Loans
> ====================
>
> As observed in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018053.html,
> a Cryptographic Relay would allow collateralized loans.
>
> Nothing prevents the "loan shark" in the collateralized loan example from
> being a MuSig of multiple small investors.
> Practically, a coordinator would help facilitate construction of the
> necessary transactions and interaction with the loanee, but as long as
> ownership remains controlled by the individual investors, there should not
> be any custodial issues.
>
> Of course, if the loan defaults, then the collateral needs to be sold in
> order to recoup the loss incurred in loan default case.
> Coordinating this sale amongst the multiple small investors is now
> potentially harder.
>
> An additional service may be willing to pre-allocate Bitcoin funds into a
> timelocked contract, where the amount can be claimed conditional on
> transfer of the ownership of the collateral to the service in the future,
> or if the fund is not so claimed, to be returned to the service with the
> collateral not claimed (as it might have been reclaimed by the loaner after
> successfully paying back its loan).
> This additional service earns by arbitraging the time preference: in case
> of default, the investors would prefer to recoup their financial losses
> quickly, while the service is now in possession of the collateral that it
> can resell later at a higher rate.
>
> Note that these are all operations that traditional banks perform; again,
> this idea simply removes the necessity for custodial holding of funds, in
> the way traditional banks do.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 11971 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
2020-07-20 14:18 99% [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware ZmnSCPxj
2020-07-21 1:27 99% ` ZmnSCPxj
@ 2020-07-21 5:25 99% ` Andy Schroder
2020-07-21 9:19 99% ` ZmnSCPxj
1 sibling, 1 reply; 47+ results
From: Andy Schroder @ 2020-07-21 5:25 UTC (permalink / raw)
To: ZmnSCPxj via bitcoin-dev
See multiple places below
Andy Schroder
On 7/20/20 10:18 AM, ZmnSCPxj via bitcoin-dev wrote:
> Introduction
> ============
>
> An electrical relay is an electrically-controlled switch, often diagrammed as:
>
> +-------------o
> |
> | \
> | \
> +--o o-------o
>
> o---- |
> ) |
> ) |
> ) |
> o---- |
>
> The terminals at the left feed into a coil.
> When electricity passes through the coil, it magnetizes a core, and the magnetism attracts a switch into a closed position, which would let electricity to pass through the terminals at the right.
> This can be used to "turn on" or supply power to a different electrical device.
>
> If no electricity is passing through the coil via the terminals on the left, then no electricity can pass through the terminals on the right, as the switch is an open position at default.
>
> This is a fairly simple logic circuitry, upon which more complicated circuitry can be made.
>
> Similarly, a Cryptographic Relay is a hardware electrical component that allows control of some electrical circuit.
> It has two terminals which are the two terminals of a switch.
> It can also be contacted, for example via Bluetooth, by an electronic computing device.
> The Cryptographic Relay has a public key, which represents the current owner of the relay.
> If the electronic device is able to provide a proof-of-knowledge of the private key (i.e. a signature) corresponding to the public key that the Cryptographic Relay knows, then it allows the switch to be controlled by that device.
>
> Motivation
> ==========
>
> Suppose I have a car I wish to sell to you, for Bitcoins.
> This car, as it happens, has a Cryptographic Relay: it will only start its engine if it gets a signed message from me using a private key I have on my phone.
> It knows my public key, and will only turn off and on at my command.
>
> Now, you want to be able to know that by paying me Bitcoins, you get sole ownership of the car I am selling.
>
> This is in fact, nothing more than a swap operation.
> I have an asset, a car, and you have an asset, some Bitcoins.
> We want to atomically swap one asset for the other asset, and those assets do not exist in a single asset-assignment system.
>
> Paying Bitcoins For Cars Via Succinct Atomic Swaps
> ==================================================
>
> Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which can be used to create an atomic swap between my car and your Bitcoins.
>
> An important part of this Succinct Atomic Swap is that all timeouts are only in one asset-assignment system.
> The original Succinct Atomic Swap discussion gives an example of swapping Bitcoins for Litecoins.
> Each has its own distinct blockchain, which is a distinct distributed asset-assignment system.
>
> A crucial part of the Succinct Atomic Swap is that all timelocks are only on one asset-assignment system.
> The other asset-assignment system need not support anything other than assigning ownership of assets to (homomorphically additive) public keys.
>
> This is important as a major simplification of the Cryptographic Relay:
> The relay only needs to know its *current owner*, and does not need to know the current time!
>
> Thus, in order for you to buy my car:
>
> * You set up the Succinct Atomic Swap on the Bitcoin blockchain.
> * We generate fresh private keys, then combine them via MuSig, and I transfer the ownership of the car to that MuSig public key.
> * If I claim the funds, that atomically reveals my share of the private key to you, so you can claim the car using your private key plus my share and transfer the car to sole control of you.
> * If I fail to claim the funds, then when you reclaim your funds at timeout, that atomically reveals your share of the private key to me, so that I can claim the car using my private key plus your share and transfer the car back to sole control of me.
>
> This is in fact the same as the Succinct Atomic Swap example, except that instead of me swapping my Litecoins for your Bitcoins, I am swapping my Cryptographic Relay for your Bitcoins.
>
> Cryptographic Relay Operations
> ==============================
>
> Thus, a Cryptographic Relay needs to support only the following basic operations.
> These operations are triggered by its owner sending a message, plus a signature verifiable by the public key, to the Cryptographic Relay.
> (Cryptographer warning: if using Schnorr, the message hashed into the signature also has to include the public key that is signing it, since BIP32 nonhardened derivation allows a Schnorr signature created by one child private key to be trivially malleated into a signature for the same message by a sibling private key; this does not exist in ECDSA due to its nonlinearity.
> message sends need not include the public key, it can be added by the cryptographic relay since it has to know the public key of the owner anyway.
> Of note is that the bip-340 description of Schnorr includes the public key in the hash operation of signatures as well, and does not require this.)
>
> The only operations necessary are:
>
> 1. Turn on.
> 2. Turn off.
> 3. Transfer ownership to new pubkey ___.
>
> Due to Succinct Atomic Swaps not requiring any kind of timelock on one asset-assignment system, the Cryptographic Relay need not have any concept of time, as mentioned above, and transfer of ownership can be done by a simple message signed by the current owner transferring ownership to a new public key.
>
> (Cryptographer warning: turn-on/turn-off messages should be challenge-response: the Cryptographic Relay requests signing with a unique nonce included in the message, otherwise previous messages can be captured by third parties and replayed; ownership-transfer messages should probably also include a nonce, or otherwise we could require non-reuse of keys.
> This can be implemented with a 64-bit incrementing nonce, which should work for the practical lifetime of any Cryptographic Relay.)
>
> (Cryptographer warning: similarly, ownership-transfer messages should probably be indexed as well with an incrementing nonce, otherwise key reuse would allow signature replay; similarly again, each Cryptographic Relay should have a UUID that is included in message hashes, as otherwise key reuse would allow signature replay for commands to one device to be repeated for another device.)
>
> Lightning
> =========
>
> Unfortunately, it seems not possible to transport Succinct Atomic Swap constructions over the Lightning Network.
>
> Succinct Atomic Swaps have an asymmetric setup, unlike the traditional HTLC-based atomic swaps.
> This asymmetry makes it difficult to reason about how a forwarding node on the Lightning Network would be able to accept a Succinct Atomic Swap and then send out another Succinct Atomic Swap.
>
> An observation to make is that the Bitcoin-side construction in the Succinct Atomic Swap description has the following branches:
>
> * B gets the money, and A learns a secret from B.
> * After a timeout, A gets the money back, and B learns a secret from A.
>
> Unfortunately, the above construction, while instantiatable in a single channel (any absolute-timelock contract enforceable on a blockchain can be instantiated in a channel anchored in that blockchain), cannot be safely *forwarded* over the Lightning Network in a sequence of channels forming a route.
>
> This is because we need to have a different timeout at each forwarding hop, in order to allow a forwarding node enough time to discover an event and react accordingly.
> This means that each forwarding node has to have a shorter timeout on its outgoing contract than its incoming contract.
>
> But in the half-Succinct-Atomic-Swap contract, the forwarding node needs to provide a secret in order to reclaim the funds at the timeout.
> And it can only discover that secret at the later timeout of the incoming contract.
> Thus, it is not safe for the forwarding node to forward any half-Succinct-Atomic-Swap contract.
>
> Thus, we either:
>
> * Prevent old, low-value cryptographic cars from being bought using Lightning, reducing their economic veolocity and preventing moon and lambos.
> * OR, we give the Cryptographic Relay a notion of time which makes it compatible with PTLCs that can be routed over Lightning.
> In essence, the PTLC "goes over one more hop", this time transferring ownership of the Cryptographic Relay.
>
> A Cryptographic Notion of Time
> ==============================
>
> Time stops for no one; it will not stop for thee.
>
> Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.
>
> Now, we can observe that block header hashes are, in fact, low-entropy.
> This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.
>
> Now, we can observe that temperature is largely itself also an expression of entropy.
> Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature
, at constant pressure
> .
Or, at constant temperature, higher entropy areas have lower pressure
and lower entropy areas have higher pressure. See the background contour
of the figure on the bottom left here for an example with carbon dioxide:
http://andyschroder.com/CO2Cycle/Explorer?DatasetNumber=1&0_ValueIndex=Optimal&HorizontalAxis=0&1_ValueIndex=Optimal&VerticalAxis=1&2_ValueIndex=Optimal&3_ValueIndex=Optimal&4_ValueIndex=Optimal&5_ValueIndex=0&6_ValueIndex=0&7_ValueIndex=0&8_ValueIndex=0&9_ValueIndex=0&10_ValueIndex=0&11_ValueIndex=0&12_ValueIndex=0&ContourValue=efficiency&LinePlotVerticalAxisValue=efficiency&CyclePlotVerticalAxis=Temperature&CyclePlotHorizontalAxis=Pressure&CyclePlotContourLevel=Entropy
> Overall, the temperature differential across the universe decreases in the direction of future time.
> However, it is possible to implement a sort of Maxwell's Demon.
> Maxwell's Demon is an entity that guards a hole between two containers containing air.
> If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
> It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.
>
> Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.
>
> Of course, we already have implementations of Maxwell's Demon.
> We call such implementations "refrigerators".
Don't know why I never thought of it this way!
>
> Refrigerators, to do their magic, must consume energy and emit heat.
> Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.
Not necessarily "much larger". For example, a good geothermal heat pump
has a COP greater than 8. That means 8 units of heat are removed for 1
unit of work input. That means that the total heat emitted by the
refrigerator is only (1-(8+1)/8) = 12.5% higher than the heat it removes
from inside the refrigerator.
> We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold
and it's temperature does not begin to rise over time.
> But we know that refrigerators, to do their work, must consume
mechanical
> energy and emit heat.
>
> And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.
However, the entropy inside a chamber can still decrease if the pressure
goes up and heat is allowed to conduct away as the temperature tries to
go up. This however, also results in more work being input into the
refrigerator, which means it still consumes energy. Also, if you are
okay with the temperature inside a chamber going up (instead of down),
you can consume energy and compress it adiabatically and the pressure
will rise and so will the entropy rise.
> .
>
> Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
> Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy
production
> greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.
Blocks freeze the transactions in place!
Or, blocks compress transactions in place.
>
> And since we know that:
>
> * The future is where the universal entropy is larger than the past.
> * Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).
>
> ...then we know that a longer proof-of-work header chain represents more actual physical time passing.
>
> Proof-of-work is therefore also an unforgeable proof-of-time-passing.
>
> Thus, all we need for a cryptographically-secure *measure of time* is a header chain.
>
> Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
> The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
> Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.
>
> This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
> Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
> Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
> Thus, it must use this cryptographic notion of time.
Very interesting thought!
>
> Giving Cryptographic Relays a Notion of Time
> ============================================
>
> In order to implement timelocks, we can add an `nLockTime` field to ownership-transfer messages for the Cryptographic Relay.
>
> On manufacturing a Cryptographic Relay, the manufacturer stores in unchangeable memory (e.g. burned diode non-erasable PROMs) the block header hash of a sufficiently-deep block (for example, one that has been buried for 6 or so difficulty adjustment periods), its blockheight, and the difficulty target for the adjustment period.
>
> If the Cryptographic Relay receives an ownership-transfer message with `nLockTime` greater than this recorded block height, it demands a header chain rooted at the prerecorded block up to the specified `nLockTime`.
> It then validates that the header chain has sufficient difficulty for each adjustment period covered, and also emulates the difficulty adjustment at appropriate blockheights.
> This is sufficient proof to it that time has passed since its manufacture, as a header chain is a cryptographic proof of time passing.
>
> This allows me to sell a cryptographic car to you, over Lightning, by this ritual:
>
> * First, we generate fresh keypairs and their combined MuSig pubkey.
> * We perform a MuSig signing operation, signing an ownership-transfer message with a future `nLockTime`, transferring ownership from the MuSig pubkey back to my unilateral pubkey.
> * I transfer control of the car to the MuSig pubkey.
> * We partially perform a second MuSig signing operation, signing an ownership-transfer message with a 0 `nLockTime`, transferring ownership from the MuSig pubkey back to you, but pausing after the `R` exchange.
> * Specifically, after the `R` exchange, you generate the point corresponding to my share of the signature `s`, which you can get from my `R`, your `R`, my public key, and your public key, and the message we agreed on.
> * I generate an invoice for the above signature share point (i.e. pay for signature).
> * You pay the invoice, making sure that the maximum cltv-delta for the outgoing payment does not exceed the pre-agreed timeout (minus some time margin you deem safe).
>
> Then:
>
> * If you successfully pay the invoice (i.e. I release my share of the signature) you can now complete the signature for the transfer to your unilateral control.
> * If you are unable to pay the invoice, then once the future blockheight is reached, I download the Bitcoin block header chain and feed it and the backout ownership-transfer message to the car and regain control of my vehicle.
>
> This provides Lightning-with-PTLCs compatibility (which we expect to be deployed on the network anyway), while still requiring relatively low resources on the Cryptographic Relay hardware (at the cost that timelocked backouts require much bandwidth; but since such backouts are expected to be rare, this may be an acceptable tradeoff).
>
> A Cryptographic Relay accepting this notion of time can continue to be used with Succinct Atomic Swaps, by using ownership-transfer messages with a 0 `nLockTime`, with the advantage that backouts need not download a block header chain to the Cryptographic Relay.
>
> A Case Against Blockchain Proliferation
> =======================================
>
> We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
> In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.
>
> This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
> That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.
>
> However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.
>
> Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.
And you are saying below that risk can be mitigated if manufactures
working very hard to build up enough market share that there is enough
auditing of their devices that appear to be honestly manufactured?
>
> And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.
>
> On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.
>
> The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
> Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.
I would just keep it simple and stick with simple standards for
transistors and then let the user choose many of the parameters their
own by supplying their own electro mechanical relay. Most I/O devices
have a transistor in them, then you need a booster transistor to add on
it to it to get enough current in order to actually drive a relay coil.
This is more complicated for the end user, but gives them more flexibility.
>
> Tr\*st in manufacturers can be acquired, at very high expense, by using cut-and-choose: get a number of Cryptographic Relays, randomly select some of them, then open those and analyze if there are any backdoors, then utilize the rest if the randomly-opened ones do not have any discovered backdoors or other security issues.
>
> Delegated Operators
> ===================
>
> Another useful capability to add to Cryptographic Relays would be to allow adding operators, which are additional public keys that can turn it on or off, but cannot authorize a transfer of ownership or the addition of new operators.
>
> Only the owner of the Cryptographic Relay can add or delete operators.
>
> For example, suppose you, the buyer of my cryptographic car, represent a typical family share-owned between you and all of your husbands.
> Then when purchasing the car from me, you can transfer ownership of the car to a MuSig n-of-n between you and your husbands, rather than unilateral control of yourself.
>
> Of course, practically speaking, only one of you or your husbands can operate the car at once.
> Thus, while the ownership of the vehicle is an n-of-n MuSig, you can assign individual keys of yourself and each of your husbands, as operators of the car.
>
> The Cryptographic Relay would need to allocate a fixed amount of space for the number of allowed operators, thus imposing a practical limit on the number of husbands you can have simultaneously.
> Unfortunately, the Cryptographic Relay cannot store an arbitrary number of public keys, thus there are limits on the number of husbands a human can have.
>
> Whenever an ownership transfer is performed, all operators are deleted, thus preventing one of the previous operators attempting to start the car and drive it off even though it is semantically owned by someone else.
>
> A car purchased by an extended family, such as a company, might be owned by a k-of-n of the stakeholders of the company, and then employees of the company might be assigned as operators.
>
> Practical Deployment
> ====================
>
> By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).
>
> In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
> For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.
>
> Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
> Similarly, many existing cars can be started without keys by hot-wiring.
> Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.
This is true, but if the devices is complicated and interconnected
enough, the cost to hot-wire may outweigh the gains of stealing the
device. For example, in an electric car, the battery pack, inverter,
motor, charge controller, media computer, autopilot computer, bluetooth
radio, cellular radio, FM radio, A/C compressor controller, drivetrain
coolant system controller, charge port controller, anti-lock brake
controller, power window motors, door locks, ignition, etc. all were
locked together, it could become prohibitively expensive to hot wire
given all those components would need to be removed from the vehicle and
a specific chip removed (which likely will be embedded). And, it's
trivial to "bake in" the "cryptographic relays" into every component
during the initial manufacturing process. So, the transfer of ownership
could need to by performed on all components simultaneously in order to
successfully sell/trade the vehicle in order for this transfer to be
really effective.
>
> A Cryptographic Relay is a simple device:
>
> * The design of the device is simple, requiring support for only a few operations.
> * The interface of the device is simple: it is only a switch, and easy to integrate into more complex applications.
> The switch may be used as the route for the power supply, or it may be used simply for an electrical connection that is detected by some control system of the appliance to know whether it should act as "on" or "off".
> This simplicity and generality allows simple interfacing with a variety of electrical devices.
>
> The intent is that:
>
> * It is easy to implement and subsequently manufacture the device, so that risks of backdoors being installed by centralized manufacturers is mitigated by having multiple Cryptographic Relay manufacturers competing and incentivized to discover backdoors and other security failures of their competitors.
> * It is easy to integrate the device into the design of a more complex device intended for use by an end-user.
> It is also easy to integrate the device, post-design, to a more complex existing device that did not include it.
>
> Collateralizing Cryptographic Relay Devices
> ===========================================
>
> Giving Cryptographic Relays a notion of time allows them to be used in more complicated contracts.
>
> Suppose after purchasing the cryptographic car from me, you and your husbands find yourselves in tight financial straits.
> You and your husbands might then want to take a loan from some entity.
>
> Obviously, that entity will not simply loan out precious Bitcoins unless you promise to pay it back with *more* Bitcoins than what it gave out.
> And that entity might want to accept your cryptographic car as collateral for the loan, so that if you are unable to pay, the entity can partially recoup losses by reselling your cryptographic car.
>
> With `SIGHASH_ANYPREVOUT` and Taproot, it becomes possible to trustlessly arrange a collateralized loan on the cryptographic car (to the extent the loan shark tr\*sts that none of you or any of your husbands have replaced the Cryptographic Relay with a backdoored device, at least).
>
> The loan shark arranges a loan in a multi-step process involving multiple PTLC-like constructions:
>
> * First, all of you (you and your husbands, and the loan shark) generate two fresh keypairs.
> * Call the first the "loan-out" keypair.
> * Call the second the "loan-payback" keypair.
> * You generate (but do not sign!) a command to transfer control of the car from you to a MuSig(you, your husbands ..., loan shark) using the "loan-out" pubkeys.
> * Generate the initial backout command, which transfers from the MuSig loan-out pubkey above, back to you and your husbands, but with an `nLockTime` in the future.
> Get a complete signature for this command with the loan shark and your husbands and you.
> * This backout timeout period should be short, and is needed only if the loan shark suddenly aborts before it hands over the loan to you.
> * Sign the transfer of the car from you to the MuSig loan-out and feed it to the car.
> * Generate (but do not sign!) the collateralization command, which transfers from the MuSig loan-out pubkey, to a new MusSig(you, your husbands ..., loan shark) using the "loan-payback" pubkeys.
> * Generate the collateral-claim command, which transfers from the MuSig loan-payback pubkey to the loan shark, but with an `nLockTime` a little after the due date of your loan.
> Generate a complete signature for this command to the loan shark, which the loan shark will now hold and use in case you do not pay back the loan.
> * Generate the collateral-reclaim command, which transfers from the MuSig loan-payback pubkey back to you and your husbands.
> Generate a partial signature for this command from you and your husbands, but with a missing share from the loan shark, and keep this partial signature.
> * Generate a Taproot address (called the loan-payback Taproot address) with two SCRIPT branches, with an internal public key equal to the loan-payback pubkey.
> * One SCRIPT branch allows signing by the internal public key with `SIGHASH_ANYPREVOUT`.
> * The other SCRIPT branch imposes a short `OP_CHECKSEQUENCEVERIFY` timeout, and claiming by the MuSig of you and your husbands.
> * Generate loan-payback Bitcoin transaction, which spends using a `SIGHASH_ANYPREVOUT` signature on the first branch of the above Taproot address, an amount equal to your loan plus interest, and sending unilateral control to the loan shark.
> Demand an adaptor signature for this transaction, which would reveal to you the loan shark signature share of the collateral-reclaim command.
> Then provide the signature shares for you and your husband to the loan shark.
> * If the loan shark completes this signature and reclaims the loan plus interest, you learn the share to complete the collateral-reclaim command and thereby reclaim your car after paying back the loan.
> * Now the loan shark creates (but does not sign!) the loan-out transaction, which pays out the MuSig loan-out pubkey the amount being loaned.
> * Generate the loan-out-revert transaction, which spends the loan-out transaction and pays it back to the loan shark, but with an `nLockTime` in the future, nearer than the `nLockTime` of the initial backout command.
> Sign this transaction with you and your husbands and the loan shark.
> * The loan shark generates a partial signature for the collateralization command, missing the shares from you and your husbands.
> * Generate the loan-out-claim transaction, which spends the loan-out transaction and pays it to you and your husbands.
> The loan shark will demand an adaptor signature for this transaction, which lets it learn the sum of the missing signatures shares for the collateralization command.
> Then the loan shark provides its share of the signature for the loan-out-claim transaction.
> * The loan shark signs the loan-out transaction and broadcasts it.
> * You now complete the signature for the loan-out-claim transaction and broadcast it.
> The loan shark learns the missing signature shares for the collateralization command and performs it, locking your car into collateralization (where it cannot be transferred unless you, your husbands, and the loan shark agree).
> With the loan-out-claim transaction valid, you can now take the loan.
>
> Then, if you are able to pay back the loan before the due date:
>
> * Send the loan amount plus interest, exactly, to the loan-payback Taproot address.
> * If the loan shark accepts the payback of the loan, it reanchors the loan-payback Bitcoin transaction and completes the signature, then claims the paid back loan.
> * With the loan-payback signature completed, you learn the partial signature needed to complete the signature for the collateral-reclaim command, and you can now feed it to the car and regain ownership over it.
> * If the loan shark does not accept payback of the loan, you can at least recover the loan and interest by the second branch of the loan-payback Taproot address.
>
> If you are unable to pay back the loan:
>
> * The collateral-claim command becomes valid a little after the loan due date, and the loan shark takes unilateral possession of your car to recoup its losses.
>
> The above uses onchain Bitcoins.
> Similar setups may be possible over Lightning (there is no need for a `SIGHASH_ANYPREVOUT` in this case, as the loan shark may issue a long-lived invoice that lets you learn its signature share for the collateral-reclaim command signature).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
2020-07-21 5:25 99% ` Andy Schroder
@ 2020-07-21 9:19 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-21 9:19 UTC (permalink / raw)
To: Andy Schroder, Bitcoin Protocol Discussion
Good morning Andy,
> > A Cryptographic Notion of Time
> >
> > ===============================
> >
> > Time stops for no one; it will not stop for thee.
> > Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.
> > Now, we can observe that block header hashes are, in fact, low-entropy.
> > This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.
> > Now, we can observe that temperature is largely itself also an expression of entropy.
> > Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature
>
> , at constant pressure
True.
> > .
>
> Or, at constant temperature, higher entropy areas have lower pressure
> and lower entropy areas have higher pressure. See the background contour
> of the figure on the bottom left here for an example with carbon dioxide:
>
> http://andyschroder.com/CO2Cycle/Explorer?DatasetNumber=1&0_ValueIndex=Optimal&HorizontalAxis=0&1_ValueIndex=Optimal&VerticalAxis=1&2_ValueIndex=Optimal&3_ValueIndex=Optimal&4_ValueIndex=Optimal&5_ValueIndex=0&6_ValueIndex=0&7_ValueIndex=0&8_ValueIndex=0&9_ValueIndex=0&10_ValueIndex=0&11_ValueIndex=0&12_ValueIndex=0&ContourValue=efficiency&LinePlotVerticalAxisValue=efficiency&CyclePlotVerticalAxis=Temperature&CyclePlotHorizontalAxis=Pressure&CyclePlotContourLevel=Entropy
Yes, PVT relation.
> > Overall, the temperature differential across the universe decreases in the direction of future time.
> > However, it is possible to implement a sort of Maxwell's Demon.
> > Maxwell's Demon is an entity that guards a hole between two containers containing air.
> > If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
> > It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.
> > Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.
> > Of course, we already have implementations of Maxwell's Demon.
> > We call such implementations "refrigerators".
>
> Don't know why I never thought of it this way!
>
Yes.
> > Refrigerators, to do their magic, must consume energy and emit heat.
> > Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.
>
> Not necessarily "much larger". For example, a good geothermal heat pump
> has a COP greater than 8. That means 8 units of heat are removed for 1
> unit of work input. That means that the total heat emitted by the
> refrigerator is only (1-(8+1)/8) = 12.5% higher than the heat it removes
> from inside the refrigerator.
>
Granted.
I am now investigating geothermal heat pumps in the context of taking over the world, thank you for your information.
> > We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold
>
> and it's temperature does not begin to rise over time.
>
> > But we know that refrigerators, to do their work, must consume
>
> mechanical
>
> > energy and emit heat.
> > And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.
>
> However, the entropy inside a chamber can still decrease if the pressure
> goes up and heat is allowed to conduct away as the temperature tries to
> go up. This however, also results in more work being input into the
> refrigerator, which means it still consumes energy. Also, if you are
> okay with the temperature inside a chamber going up (instead of down),
> you can consume energy and compress it adiabatically and the pressure
> will rise and so will the entropy rise.
>
> > .
> > Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
> > Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy
>
> production
>
> > greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.
>
> Blocks freeze the transactions in place!
Certainly an interesting thought!
>
> Or, blocks compress transactions in place.
>
> > And since we know that:
> >
> > - The future is where the universal entropy is larger than the past.
> > - Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).
> >
> > ...then we know that a longer proof-of-work header chain represents more actual physical time passing.
> > Proof-of-work is therefore also an unforgeable proof-of-time-passing.
> > Thus, all we need for a cryptographically-secure measure of time is a header chain.
> > Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
> > The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
> > Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.
> > This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
> > Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
> > Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
> > Thus, it must use this cryptographic notion of time.
>
> Very interesting thought!
Thank you very much.
> > A Case Against Blockchain Proliferation
> >
> > ========================================
> >
> > We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
> > In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.
> > This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
> > That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.
> > However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.
> > Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.
>
> And you are saying below that risk can be mitigated if manufactures
> working very hard to build up enough market share that there is enough
> auditing of their devices that appear to be honestly manufactured?
>
Potentially.
A lot of alternative blockchains that are designed for handling asset-assignment of real-world things, are far more centralized due to their non-generic nature: very few entities are interested in those spaces.
A Cryptographic Relay demonstrates that we can do better, by making a generic component, and disposing of the blockchain, and shows that even in the "blockchain for things!" case, you *still have to trust manufacturers anyway*.
After all, CPUs are commoditized enough that we hardly ever wonder if e.g. Intel or AMD or ARM have secreted backdoors into their CPUs.
Hopefully, Cryptographic Relays are commoditized enough as well that the probability of a manufacturer adding secret backdoors is low.
> > And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.
> > On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.
> > The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
> > Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.
>
> I would just keep it simple and stick with simple standards for
> transistors and then let the user choose many of the parameters their
> own by supplying their own electro mechanical relay. Most I/O devices
> have a transistor in them, then you need a booster transistor to add on
> it to it to get enough current in order to actually drive a relay coil.
> This is more complicated for the end user, but gives them more flexibility.
I considered the "relay" interface to be better since a relay can be used as a (very slow) transistor, but if you want to transport say a 220V AC mains supply, you cannot use a transistor.
The slowness of relays (due to their mechanical nature) is acceptable since power-on and power-off events are expected to be rare compared to the operation of the device.
For example, a pre-existing non-cryptographic Smart TV can be upgraded into a cryptographic Smart TV by splicing a DPST Cryptographic Relay in its mains supply cord.
(This voids warranty, but if warranty is already ended, might as well.)
That said, it is possible to start with a relay driver interface instead of a relay interface (though I prefer the latch-type relays due to their better mechanical longevity and lower continuous power use, which requires two relay driver interfaces and timing).
> > Practical Deployment
> >
> > =====================
> >
> > By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).
> > In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
> > For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.
> > Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
> > Similarly, many existing cars can be started without keys by hot-wiring.
> > Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.
>
> This is true, but if the devices is complicated and interconnected
> enough, the cost to hot-wire may outweigh the gains of stealing the
> device. For example, in an electric car, the battery pack, inverter,
> motor, charge controller, media computer, autopilot computer, bluetooth
> radio, cellular radio, FM radio, A/C compressor controller, drivetrain
> coolant system controller, charge port controller, anti-lock brake
> controller, power window motors, door locks, ignition, etc. all were
> locked together, it could become prohibitively expensive to hot wire
> given all those components would need to be removed from the vehicle and
> a specific chip removed (which likely will be embedded). And, it's
> trivial to "bake in" the "cryptographic relays" into every component
> during the initial manufacturing process. So, the transfer of ownership
> could need to by performed on all components simultaneously in order to
> successfully sell/trade the vehicle in order for this transfer to be
> really effective.
Indeed, that would be possible.
Though note that if I am trying to abscond with an electric car, all I need to *hot*wire would be the battery pack, inverter, motor, and ignition.
After absconding the electric car and placing it in a location I control, I can crack (i.e. splice wires across) the Cryptographic Relays of the other components at my leisure.
Thus, this post is simply a prelude to me becoming the next protagonist of Fast and Furious.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Implementing Investment Aggregation
2020-07-21 5:23 99% ` esnierde
@ 2020-07-21 16:28 99% ` ZmnSCPxj
0 siblings, 0 replies; 47+ results
From: ZmnSCPxj @ 2020-07-21 16:28 UTC (permalink / raw)
To: esnierde; +Cc: Bitcoin Protocol Discussion
Good morning Hilda,
> Good Day ZmnSCPxj,
>
> Thanks for sharing the idea! I read through the doc and have some concerns that might be off the topic or outside the scope. Please bear with me.
>
> The traditional banking system provides more than custodial holding of funds in terms of lending & borrowing. One important function is to match long term investments with short or variable term deposits. Alice might be willing to make investments at time 0, but some emergency occurs and she may need (part of) her bitcoins back at time 1 before the loan due date.
This may be possible by using a Decker-Russell-Osuntokun ("eltoo") mechanism.
The laon-payback transaction (the one that is signed with `SIGHASH_ANYPREVOUT`) can, instead of paying out directly to the investors, pay out to a Decker-Russell-Osuntokun mechanism that is signed by a MuSig of the investors plus the coordinator.
The initial state of this mechanism is the payouts of each investor, in proportion to the amounts they lent out.
Thus, if none of the investors need to liquidate early, this initial state is what gets posted on the blockchain ***if*** the loaning business successfully pays back / does not default.
If one of the investors needs to liquidate its position in this loan agreement, the coordinator can offer to buy its position (in whole or in part) for a smaller amount (as the coordinator takes on more risk).
Then all the investors plus the coordinator sign a new state of the Decker-Russell-Osuntokun mechanism, with the coordinator getting more funds, and the liquidating investor losing all or part of its allocation.
The investor doing the liquidation can demand a pay-for-signature, so that its signature share of the new state is only acquired by the coordinator if and only if it actually gets paid with Bitcoins now.
The position need not be bought by the coordinator --- one of the other small investors in the business can "double down" and purchase more of the share of the eventual loan-payback by the same mechanism, from peer investors who need to liquidate their position in the loan-payback early, increasing its risk exposure but potentially getting even more profit in case the invested business pays back the loan.
>
> Also, in the banking system, there are usually sophisticated risk analysis systems covering formulas, due diligence, and funds for loan defaults. Banks can reinvest partial of what they namely have and obtain profits to cover possible losses when borrowers cannot pay back 100%. In this way, they are more resilient to defaults & change of collaterals' value, and borrowers might be able to leverage 1 unit worth of collateral to get 3 units fund instead of 1.
Similar constructions could be done by the coordinator and / or the investors directly; unfortunately I know too little of them to give an idea how this can be done.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Seeking Tech Review of "Learning Bitcoin from the Command Line"
[not found] ` <CANGe=uteSQKtocnb3vQxmZpxhU7gbT9J2OEEYEUZW3a32NbqnA@mail.gmail.com>
@ 2020-07-23 1:52 99% ` Christopher Allen
0 siblings, 0 replies; 47+ results
From: Christopher Allen @ 2020-07-23 1:52 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4990 bytes --]
Dear Bitcoin Experts,
Learning Bitcoin from the Command Line
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/>
was one of Blockchain Common <https://www.BlockchainCommons.com>'s first
offerings, and it remains one of the most popular. Not only has it received
on Github over 100 watches, 300 forks, and 1200 stars, but we also know of
a number of people who learned how to program Bitcoin from the course and
have become full-time developers in our community or have joined your ranks
as bitcoin-core contributors.
We think that it's a unique course precisely because of its command-line
focus, which makes it "intermediate" between the introductory courses and
the more intense summer workshop and internships for bitcoin development.
In the course, we teach the fundamental RPC commands for interacting with
Bitcoin Core, primarily using the bitcoin-cli command line, but also with
later in the course curl and via other programming languages via RPC. By
doing so, we provide a nuts-and-bolts guide to the functionality of
Bitcoin that
really teaches how it works, and so will continue to be useful even if
readers choose to move on to higher levels of abstraction that hide some of
the Bitcoin fundamentals.
We're hoping that we can get your help in reviewing the core material
making up our newest iteration of this course:
https://github.com/BlockchainCommons/Learning-Bitcoin
-from-the-Command-Line/blob/master/README.md
The majority of the original work on Learning Bitcoin was done in 2017, and
despite some interim updates, by the start of this year, it had become
outdated due to the rapid state of Bitcoin development. We've been
expending effort in the last few months to update all of our existing
examples, to change out commands that have been deprecated or defaults
changed to ensure that the outputs that students see match what they'd get
from the command line.
In addition to updating the old course, we've also added major new sections
on descriptors
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_5_Understanding_the_Descriptor.md>
, Segwit
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_6_Creating_a_Segwit_Transaction.md>,
P2WPKH
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/09_5_Scripting_a_P2WPKH.md>,
and Segwit Scripting
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/10_5_Scripting_a_Segwit_Script.md>
and
whole new chapters on PSBTs
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/07_0_Expanding_Bitcoin_Transactions_PSBTs.md>
(including
HWI) and Tor
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/14_0_Using_Tor.md>.
We think that what we have is some of the most accessible explanatory
matter available for these new topics at this intermediate level.
We'd love to get your comments on the whole front part of the course, from
Chapter 0 to 14. That's the complete, finished material on all of
`bitcoin-cli` and Bitcoin Scripting.
However, if you have limited time, the sections and chapters linked above
are the newest and rawest material in the course, and so those are the ones
that we'd like fact-checked the most. Either way, please feel free to
report out thoughts, comments, and corrections on the issues page
<https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues>
or
to enter PRs for specific corrections.
If you don't have time for that either, we are also looking for financial
support to continue this project. Blockchain Commons has already paid out
of pocket for this initial work, as open infrastructure to improve the
blockchain community, but we need to be able to complete this project,
which involves putting together chapters 15 and up on interacting with
Bitcoin RPC using more programming languages (C, C++, Python, Go, Rust
Swift), using LibWally, and onward to using Lightning. (We've got scattered
material for most of these sections right now, but they are very early
drafts and still need to be finished, standardized, and polished.)
You can also support Learning Bitcoin by becoming an ongoing patron for
Blockchain Commons through Github at
https://github.com/sponsors/BlockchainCommons, starting at $20 a month.
This will both help fund Learning Bitcoin and in the future will support
other projects intended to improve blockchain and cryptocurrency
infrastructure, such as #SmartCustody, Bitcoin Standup, LetheKit,
cryptographic libraries and more. A number of bitcoin-core contributors
already have their "badge" of support listed on our Sponsors' page, add
yours!
Alternatively, we can accept one-time Bitcoin contributions directly at our
BTCPay server: https://btcpay.blockchaincommons.com/
Thank you for your help!
Christopher Allen
Principale Architect & Executive Director
Blockchain Commons
[-- Attachment #2: Type: text/html, Size: 6587 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Signet update
@ 2020-07-27 2:35 99% アルム カールヨハン
0 siblings, 0 replies; 47+ results
From: アルム カールヨハン @ 2020-07-27 2:35 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hello,
Some progress (courtesy of ajtowns!) has been made on the Signet
proposal (BIP-325):
* Block signatures are now verified as transactions
Among other things, this means Signet is (probably) compatible with
PSBT (thanks sipa!), and no longer requires the custom "simple
signature verifier/creator" stuff.
This unfortunately means Signet will hard fork, but I don't think
anyone is using it seriously yet, so it shouldn't be an issue.
The BIP pull request is here: https://github.com/bitcoin/bips/pull/947
Feedback welcome.
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Minsc, a Miniscript-based scripting language
@ 2020-07-29 15:10 99% Nadav Ivgi
0 siblings, 0 replies; 47+ results
From: Nadav Ivgi @ 2020-07-29 15:10 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]
Hi all,
I recently released Minsc, a high-level scripting language for expressing
Bitcoin Script spending conditions using a simple and familiar syntax.
Minsc is based on the Miniscript Policy language, with additional features
and syntactic sugar sprinkled on top, including variables, functions, infix
notation, human-readable times and more.
A live compiler (Minsc->Policy->Miniscript->Script) and documentation are
available on the website: https://min.sc
Source code (in Rust) is available on github:
https://github.com/shesek/minsc
Some example Minsc scripts:
- A user and a 2FA service need to sign off, but after 90 days the user
alone is enough
pk(user_pk) && (9@pk(service_pk) || older(90 days))
- Traditional preimage-based HTLC
$redeem = pk(A) && sha256(H);
$refund = pk(B) && older(10);
likely@$redeem || $refund
- Liquid-like federated pegin with emergency recovery keys
$federation = 4 of [ pk(A), pk(B), pk(C), pk(D), pk(E) ];
$recovery = 2 of [ pk(F), pk(G), pk(H) ];
$timeout = older(heightwise 2 weeks);
likely@$federation || ($timeout && $recovery)
- The BOLT #3 received HTLC policy
fn htlc_received($revoke_pk, $local_pk, $remote_pk, $secret, $delay) {
$success = pk($local_pk) && hash160($secret);
$timeout = older($delay);
pk($revoke_pk) || (pk($remote_pk) && ($success || $timeout))
}
htlc_received(A, B, C, H, 3 hours)
- 2FA where the user has a 2-of-2 setup and the service provider is a
3-of-4 federation
fn two_factor($user, $provider, $delay) =
$user && (likely@$provider || older($delay));
$user = pk(user_desktop) && pk(user_mobile);
$providers = [ pk(P1), pk(P2), pk(P3), pk(P4) ];
two_factor($user, 3 of $providers, 4 months)
- Easily add NSA backdoors to everything 🕵️🚪
_backdoor=pk(usgovt), _pk=pk, _older=older, _after=after,
_sha256=sha256, _ripemd160=ripemd160;
fn pk(x) = _pk(x) || _backdoor;
fn older(x) = _older(x) || _backdoor;
fn after(x) = _after(x) || _backdoor;
fn sha256(x) = _sha256(x) || _backdoor;
fn ripemd160(x) = _ripemd160(x) || _backdoor;
(pk(A) && sha256(H)) || (pk(B) && older(10))
Feedback is appreciated!
Nadav
P.S Since every Miniscript Policy is also a valid Minsc expression, the
min.sc web code editor UI could also be useful for experimenting with bare
policies. You'll get syntax highlighting, parentheses matching, real-time
compilation (in a web worker so the browser doesn't freeze) and syntax
error reporting.
[-- Attachment #2: Type: text/html, Size: 3151 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and Package Relay
@ 2020-07-29 20:17 99% Antoine Riard
0 siblings, 0 replies; 47+ results
From: Antoine Riard @ 2020-07-29 20:17 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8171 bytes --]
Hi list,
Security and operations of higher-layer protocols (vaults, LN, CoinJoin,
watchtowers, ...) come with different assumptions and demands with regards
to tx-relay and fee models. As the Bitcoin stack is quite young, it would
be great to make those ones more understood and what p2p/mempool changes we
might adopt at the base layer to better answer them. I would like to
explore this with my current post.
### Time-Sensitive Protocols Security-Model (you can skip this if you know
LN)
Lightning, the most deployed time-sensitive protocol as of now, relies on
the timely confirmations of some of its transactions to enforce its
security model. Like timing out an outgoing HTLC, claiming an incoming HTLC
or punishing a revoked commitment. Ensuring timely confirmation is
two-fold: a) propagating well-transactions across the network to quickly
hit miner mempools b) offering a competitive feerate to get in next coming
blocks.
Updating feerate just-in-time is quite challenging for LN as you can't
resign a commitment once your counterparty is non-responsive or malicious,
and thus any fee strategy assuming interactivity is closed. With current
constraints of maintaining a trustless chain of transactions (no
Parent-Pay-For-Child), the only option is a CPFP. Ongoing update of LN
protocol (anchor-outputs) will allow a channel participant to unilaterally
bump feerate of its commitment/HTLCs txn, assuming there is no
_adversarial_ network mempool conditions like a concurrent broadcast.
Beyond enforcing the need to secure its funds by bumping feerate, an
offchain user might be willingly to accelerate confirmation of a broadcast
for liquidity management in face of mempool-congestion. This issue is
likely shared by any multi-party protocol like Coinjoins where resigning is
painful and a party may have different liquidity preferences than other
participants and would like to express them in an unilateral fee bumping.
### Effective Transaction Propagation and Uniform Relay Policy
Even before competing on feerate, the first and foremost point of the
laid-out security model was the well-propagation of transactions across the
p2p network. Its effectiveness is determined by compliance to 1) consensus
rules 2) policy rules. This second set is a tighter one governing different
aspects of your transactions (like size, output type, feerate,
ancestors/descendants, ...) and introduced to sanitize the p2p network
against a wide scope of resources abuses (RBF bandwidth waste, package
evaluation CPU DoS, economic nonsense outputs, ...)
These rules diverge across implementations/versions and a subset of them
can be tightened or relaxed by node operators. This heterogeneity is
actually where the risk is scored for higher protocols, your LN's full-node
might be connected to tx-relay peers with more constraining policies than
yours and thus will always reject your time-sensitive transactions,
silently breaking security of your channels [0].
Of course, LN protocols devs have always been aware of these issues and
carefully reflect policies enforcement in their codebase. That said an
important subset of them aren't documented or even standardized and thus
hard to incorporate in upper layers specs. Testing them in a black box
approach (i.e `testmempoolaccept`) before production doesn't work as your
broadcast has to be valid against the union of your yet-unknown tx-relay
topology, further static checks are blurred with dynamic ones (the feerate
now is different than the one at a future broadcast), and your transaction
might be malleate by your counterparty (like a ridiculous feerate).
And the other side, AFAIK, Core developers have always acknowledged these
issues and been really conscientious when updating such API policy. The
concerning change with protocol like LN is the severity consequences in
case of incompatible changes. Previously, your basic transaction would have
been rejected by the network and your application could have been updated
before successfully rebroadcasting. Now, such changes potentially outlawing
your time-sensitive broadcasts is a direct, measurable risk of fund loss,
either triggered by mempool-congestion or exploited by a malicious
counterparty.
Therefore, moving towards such stable tx-relay/bumping API, I propose:
a) Identifying and documenting the subset of policy rules on which upper
layers have to rely on to enforce their security model
b) Guaranteeing backward-compatibility of those rules or, in case of
tightening change, making sure there is ecosystem coordination with some
minimal warning period (1 release ?)
Committing to a uniform policy would be a philosophical change, it would
ossify some parts of full-node implementations. Another side-effect means
that upper layer devs would be incentivized to rely on such stable API. In
case of new DoS on the base layer, we might have to tighten them in a short
timeline at the price of breaking some offchain applications [1] On the
other side, full-node operators have an interest to follow such uniform
policy, as it would improve the effective feerate discovery by their
mempools.
### Adversarial Fee Bumping and Package Relay
Assuming anchor-output gets adopted & deployed, even beyond LN, it doesn't
guarantee success of CPFP, where success is defined as letting know the
network mempools of your fee-bid, confirmation being always a function of
concurrent fee-bids from other users. Indeed, if it allows bump at the
transaction-level, there is no guarantee of enforcement at the tx-relay
layer. Mempool acceptance for any transaction is done on its own, a
low-feerate parent can be rejected while a high-feerate child might have to
follow fews microseconds later.
This has consequences both for network nodes, the ones with small mempools
won't discover the best feerate bid, which false their fee-estimator and
for CPFP users, their feerate bump having chances to fail. It's specially
concerning for LN where concurrent broadcast for the same utxo can be
leveraged by a counterparty to steal channel funds. A class of attacks
known as pinning achievable today [2].
Solving this means likely deploying a package relay, an old known
proposition to evaluate the feerate of a whole chain of transactions to
decide their mempool acceptance. Ensuring package relay effectiveness means
making it part of such uniform policy laid out above, thus providing a
censorship-resistant, reliable highway across the p2p network to always
increase feerate of your blockspace bids. It will force a pinning attacker
to enter in a feerate competition with the honest party to maintain the
pin, thus cancelling the threat.
Package relay design is also pending on bumping patterns. Ideally if a LN
hub is closing multiple channels at the same time, you should be able to
spread one CPFP on multiple parents, which is an increase of DoS surface
for the mempol. Also package relay might be the default broadcast policy by
LN nodes for unilateral broadcast, as you can't dissociate if your
transaction is stucking due to congestion or an ongoing pinning without
global view of network mempools. In the future, if LN broadcasts account
for an honest share of the whole tx-relay, it won't be free bandwidth-wise.
To conclude, upper layers of the Bitcoin stack require that single
full-nodes behave in a homogeneous way such that the base network as a
whole system provide a trustworthy propagation/fee bumping API [3]
I'm eager to get feedback on any subject introduced here, especially the
uniform policy proposal which is really worthy of discussion and
controversial for sure.
Cheers,
Antoine
[0] E.g
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017883.html
or https://github.com/bitcoin/bitcoin/issues/13283 when policy break your
broadcast
[1] Again this is not a LN specific issue, timelocked vaults have the same
issue
[2] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
[3] In fact these requirements aren't specifics from the _new_ upper-layer
Bitcoin stack but a fundamental assumption made by anything using
timelocks/concurrent states, i.e also old-school 2013 payment channels
designs
[-- Attachment #2: Type: text/html, Size: 8655 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Smaller Transactions with PubRef
@ 2020-08-01 5:09 99% Mike Brooks
0 siblings, 0 replies; 47+ results
From: Mike Brooks @ 2020-08-01 5:09 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
The attached BIP describes a new opcode that unlocks the ability to have
transactions that are about 37% smaller than a traditional single-source
segwit transaction. (Savings vary based on the number of inputs.)
The pursuit of smaller transactions is vital for Inclusive Accountability
as less data needs to be recorded on chain. Frugality is improved in two
ways; more transactions can be confirmed in a block, and small value
inputs otherwise inaccessible can now be referenced without losing
unrecoverable value due to transaction overhead.
https://github.com/TheRook/bip-pubref/blob/master/bip-PubRef.mediawiki
The variant of this technology on the ethereum side is Ditto Transactions:
https://ethereum-magicians.org/t/eip-ditto-transactions/4455
[-- Attachment #2: Type: text/html, Size: 1033 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Bitcoin Core 0.20.1 released
@ 2020-08-01 12:46 99% Wladimir J. van der Laan
0 siblings, 0 replies; 47+ results
From: Wladimir J. van der Laan @ 2020-08-01 12:46 UTC (permalink / raw)
To: Bitcoin development mailing list, Bitcoin Core development mailing list
Cc: Matt Corallo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
0.20.1 Release Notes
====================
Bitcoin Core version 0.20.1 is now available from:
<https://bitcoincore.org/bin/bitcoin-core-0.20.1/>
Or through BitTorrent:
magnet:?xt=urn:btih:6e2c72d73d763465a725e3ae941b2b937edd0300&dn=bitcoin-core-0.20.1&tr=https%3A%2F%2Fopenbittorrent.com%2F&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969
This minor release includes various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
<https://github.com/bitcoin/bitcoin/issues>
To receive security and update notifications, please subscribe to:
<https://bitcoincore.org/en/list/announcements/join/>
How to Upgrade
==============
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.
Compatibility
==============
Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer. Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.
- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.
Known Bugs
==========
The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:
- - The generated `configure` script is currently missing, and you will need to
install autotools and run `./autogen.sh` before you can run
`./configure`. This is the same as when checking out from git.
- - Instead of running `make` simply, you should instead run
`BITCOIN_GENBUILD_NO_GIT=1 make`.
Notable changes
===============
Changes regarding misbehaving peers
- -----------------------------------
Peers that misbehave (e.g. send us invalid blocks) are now referred to as
discouraged nodes in log output, as they're not (and weren't) strictly banned:
incoming connections are still allowed from them, but they're preferred for
eviction.
Furthermore, a few additional changes are introduced to how discouraged
addresses are treated:
- - Discouraging an address does not time out automatically after 24 hours
(or the `-bantime` setting). Depending on traffic from other peers,
discouragement may time out at an indeterminate time.
- - Discouragement is not persisted over restarts.
- - There is no method to list discouraged addresses. They are not returned by
the `listbanned` RPC. That RPC also no longer reports the `ban_reason`
field, as `"manually added"` is the only remaining option.
- - Discouragement cannot be removed with the `setban remove` RPC command.
If you need to remove a discouragement, you can remove all discouragements by
stop-starting your node.
Notification changes
- --------------------
`-walletnotify` notifications are now sent for wallet transactions that are
removed from the mempool because they conflict with a new block. These
notifications were sent previously before the v0.19 release, but had been
broken since that release (bug
[#18325](https://github.com/bitcoin/bitcoin/issues/18325)).
PSBT changes
- ------------
PSBTs will contain both the non-witness utxo and the witness utxo for segwit
inputs in order to restore compatibility with wallet software that are now
requiring the full previous transaction for segwit inputs. The witness utxo
is still provided to maintain compatibility with software which relied on its
existence to determine whether an input was segwit.
0.20.1 change log
=================
### Mining
- - #19019 Fix GBT: Restore "!segwit" and "csv" to "rules" key (luke-jr)
### P2P protocol and network code
- - #19219 Replace automatic bans with discouragement filter (sipa)
### Wallet
- - #19300 Handle concurrent wallet loading (promag)
- - #18982 Minimal fix to restore conflicted transaction notifications (ryanofsky)
### RPC and other APIs
- - #19524 Increment input value sum only once per UTXO in decodepsbt (fanquake)
- - #19517 psbt: Increment input value sum only once per UTXO in decodepsbt (achow101)
- - #19215 psbt: Include and allow both non_witness_utxo and witness_utxo for segwit inputs (achow101)
### GUI
- - #19097 Add missing QPainterPath include (achow101)
- - #19059 update Qt base translations for macOS release (fanquake)
### Build system
- - #19152 improve build OS configure output (skmcontrib)
- - #19536 qt, build: Fix QFileDialog for static builds (hebasto)
### Tests and QA
- - #19444 Remove cached directories and associated script blocks from appveyor config (sipsorcery)
- - #18640 appveyor: Remove clcache (MarcoFalke)
### Miscellaneous
- - #19194 util: Don't reference errno when pthread fails (miztake)
- - #18700 Fix locking on WSL using flock instead of fcntl (meshcollider)
Credits
=======
Thanks to everyone who directly contributed to this release:
- - Aaron Clauson
- - Andrew Chow
- - fanquake
- - Hennadii Stepanov
- - João Barbosa
- - Luke Dashjr
- - MarcoFalke
- - MIZUTA Takeshi
- - Pieter Wuille
- - Russell Yanofsky
- - sachinkm77
- - Samuel Dobson
- - Wladimir J. van der Laan
As well as to everyone that helped with translations on
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAl8lYXMACgkQHkrtYphs
0l2A/Af+POYB8GbqA/MnjGRk8Uw6togCO+06gydbbCSHiVEXv9KN17eSimeUw7B8
TcatI0d0+Dx2Exv5vhes3rZrX7eh6clma4WMpxKuWlnL8LzeTV5Hz2lxD6Kg9eZO
gyqsYOgQCtAatApO71z6exzhkqxakzTnWEnWijjG1qVnjGhUPIqEv9KisfhQfWRt
CKGazPK3k6KxVsDG7p5s9a5ue7b88t1E6jiWt/OR6U5Z50AVQzc7Keji7wuG9byr
WsDq8w8VuxLtvLbfNJyR9TguiU3vr85Wm3kK9kjDi4t83l1dzbU4hVllb970dzEK
llclXg5rRi2c52uW4qVXGw2oEMmdfw==
=lUXy
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 99%]
Results 1-47 of 47 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2019-11-07 22:35 [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses Pieter Wuille
2019-11-08 2:15 ` David A. Harding
2019-11-10 21:51 ` Pieter Wuille
2019-11-11 1:02 ` Matt Corallo
2019-11-13 2:56 ` Clark Moody
2019-11-13 5:32 ` ZmnSCPxj
2019-11-13 6:30 ` Pieter Wuille
2020-07-15 20:56 99% ` Russell O'Connor
2020-07-15 21:05 99% ` Greg Sanders
2020-07-15 21:11 99% ` Russell O'Connor
2020-06-11 11:51 [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services ZmnSCPxj
2020-06-13 13:38 ` Chris Belcher
2020-06-13 14:06 ` ZmnSCPxj
2020-06-13 23:25 ` Chris Belcher
2020-07-17 6:02 99% ` ZmnSCPxj
2020-06-30 19:01 [bitcoin-dev] Is Bitcoin mempool synchronized? Hilda
2020-07-01 0:53 99% ` ZmnSCPxj
[not found] <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
2020-06-23 6:41 ` [bitcoin-dev] MAD-HTLC Stanga
2020-06-23 9:48 ` ZmnSCPxj
2020-06-23 12:47 ` Stanga
2020-06-28 16:41 ` David A. Harding
2020-07-04 21:05 99% ` ZmnSCPxj
2020-06-28 12:15 ` David A. Harding
2020-06-29 18:05 ` ZmnSCPxj
2020-06-30 6:45 ` Tejaswi Nadahalli
2020-07-01 16:58 99% ` ZmnSCPxj
2020-07-02 12:22 99% ` Tejaswi Nadahalli
2020-07-02 16:06 99% ` ZmnSCPxj
2020-07-03 9:43 99% ` Tejaswi Nadahalli
2020-07-03 10:16 99% ` ZmnSCPxj
2020-07-03 10:44 99% ` Tejaswi Nadahalli
[not found] ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
2020-07-03 12:38 99% ` ZmnSCPxj
[not found] ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
2020-07-04 20:58 99% ` ZmnSCPxj
2020-07-05 9:03 99% ` Stanga
2020-07-06 11:13 99% ` Tejaswi Nadahalli
2020-07-02 12:39 99% ` Tejaswi Nadahalli
2020-07-02 13:51 99% [bitcoin-dev] Tool for checking a wallet's handling of reverted 0-conf transactions Oded Leiba
2020-07-02 16:28 99% [bitcoin-dev] BIP draft: BIP32 Path Templates Dmitry Petukhov
2020-07-03 14:39 99% ` David A. Harding
2020-07-03 16:53 99% ` Dmitry Petukhov
2020-07-03 19:10 99% ` Dmitry Petukhov
2020-07-06 15:24 99% ` Dmitry Petukhov
2020-07-09 21:40 99% [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
2020-07-09 22:30 99% ` Anthony Towns
2020-07-10 7:46 99% ` Christian Decker
2020-07-10 3:29 99% ` ZmnSCPxj
2020-07-12 14:53 99% [bitcoin-dev] Taproot activation discussion Steve Lee
[not found] <f0372f8eec5878fd919b654db76aeff7.squirrel@giyzk7o6dcunb2ry.onion>
2020-07-14 2:58 99% ` [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories Mr. Lee Chiffre
2020-07-14 14:42 99% ` ZmnSCPxj
2020-07-15 15:23 99% ` Jochen Hoenicke
2020-07-14 9:37 99% [bitcoin-dev] Thoughts on soft-fork activation Anthony Towns
2020-07-14 20:46 99% ` Matt Corallo
2020-07-17 2:58 99% ` ZmnSCPxj
2020-07-20 14:18 99% [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware ZmnSCPxj
2020-07-21 1:27 99% ` ZmnSCPxj
2020-07-21 5:25 99% ` Andy Schroder
2020-07-21 9:19 99% ` ZmnSCPxj
2020-07-21 3:40 99% [bitcoin-dev] Implementing Investment Aggregation ZmnSCPxj
2020-07-21 5:23 99% ` esnierde
2020-07-21 16:28 99% ` ZmnSCPxj
[not found] <CANGe=usVQP=qkHNo3PX4Z_Du4v5aP5YkPYeQRQmAuembj4Lpyw@mail.gmail.com>
[not found] ` <CANGe=uteSQKtocnb3vQxmZpxhU7gbT9J2OEEYEUZW3a32NbqnA@mail.gmail.com>
2020-07-23 1:52 99% ` [bitcoin-dev] Seeking Tech Review of "Learning Bitcoin from the Command Line" Christopher Allen
2020-07-27 2:35 99% [bitcoin-dev] Signet update アルム カールヨハン
2020-07-29 15:10 99% [bitcoin-dev] Minsc, a Miniscript-based scripting language Nadav Ivgi
2020-07-29 20:17 99% [bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and Package Relay Antoine Riard
2020-08-01 5:09 99% [bitcoin-dev] Smaller Transactions with PubRef Mike Brooks
2020-08-01 12:46 99% [bitcoin-dev] Bitcoin Core 0.20.1 released Wladimir J. van der Laan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox