On Fri, Jul 3, 2020 at 1:49 PM Itay Tsabary
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 ne
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 ca
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)
> > > -
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
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 re
On Fri, Jul 3, 2020 at 12:17 PM ZmnSCPxj 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 supersede
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 excu
On Thu, Jul 2, 2020 at 6:06 PM ZmnSCPxj 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 wil
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
On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj 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 h
On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj 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 mi
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
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 mine
Hi ZmnSCPxj,
That's a good point. Basically there are two extremes, if everyone is
non-myoptic (rational), they should wait even for a small fee (our mad-htlc
result), and if everyone else is myopic (rational), a non-myopic miner
should only wait for a fairly large fee, depending on miner sizes an
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
>
On Sun, Jun 28, 2020 at 2:16 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 succee
On Tue, Jun 23, 2020 at 03:47:56PM +0300, Stanga via bitcoin-dev wrote:
> On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj wrote:
> > * Inputs:
> > * Bob 1 BTC - HTLC amount
> > * Bob 1 BTC - Bob fidelity bond
> >
> > * Cases:
> > * Alice reveals hashlock at any time:
> > * 1 BTC goes to Alice
On Tue, Jun 23, 2020 at 09:41:56AM +0300, Stanga via bitcoin-dev wrote:
> Hi all,
>
> We'd like to bring to your attention our recent result concerning HTLC.
> Here are the technical report and a short post outlining the main points:
>
> * https://arxiv.org/abs/2006.12031
> * https://ittayeyal.gi
Good morning list,
This is an interesting and simple idea, thanks for sharing this paper!
However I think there are a couple of important issues (but it could be me
misunderstanding):
* the assumption that the mempool is a shared resource is flawed: it's
entirely possible
to have very differen
Hi ZmnSCPxj,
You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.
You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
> I and some number of Lightning devs consider this to be sufficient
disincentive to Bob not attacking in the first place.
An additional disincentive could be introduced in the form of bribery
proofs for failed attempts.
If we assume that "honest" users of the LN protocol won't reveal their
timel
Good morning Nadav,
> > I and some number of Lightning devs consider this to be sufficient
> > disincentive to Bob not attacking in the first place.
>
> An additional disincentive could be introduced in the form of bribery proofs
> for failed attempts.
>
> If we assume that "honest" users of the
Good morning Stanga et al,
> > Hi ZmnSCPxj,
> >
> > Thank you for taking the time to respond, these are very good points.
> > Responses inline.
> >
> > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj wrote:
> >
> > > Good morning Itay, Ittay, and Matan,
> > >
> > > I believe an unstated assumption i
Of course the order at the end should have been switched:
Consider first the case where Alice *does not* publish preimage "A": Bob
can safely publish preimage "B" and get both the Deposit and Collateral
tokens after the timeout.
Now, consider the case where Alice *publishes* preimage "A": If Bob
p
Hi ZmnSCPxj,
Thank you for taking the time to respond, these are very good points.
Responses inline.
On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj wrote:
> Good morning Itay, Ittay, and Matan,
>
> I believe an unstated assumption in Bitcoin is that miners are
> short-sighted.
>
> The reasoning for
Good morning Itay, Ittay, and Matan,
I believe an unstated assumption in Bitcoin is that miners are short-sighted.
The reasoning for this assumption is:
* Deployment of new mining hardware controlled by others may occur at any time
you do not control.
* Thus, any transactions you leave on the
Hi all,
We'd like to bring to your attention our recent result concerning HTLC.
Here are the technical report and a short post outlining the main points:
* https://arxiv.org/abs/2006.12031
* https://ittayeyal.github.io/2020-06-22-mad-htlc
Essentially, we find that HTLC security relies on miners
27 matches
Mail list logo
