<unnamed>

Public Key

npub19fnl48y9j4fk9w0a284mqvszq6fuppelqp2tcxf0s37l95avdtussf4wf0

Profile Code

nprofile1qqsz5el6njze25mzh874r6asxgpqdy7qsulsq49uryhcgl0j6wkx47gpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqfr4n5s

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:05:33 CEST

- reply

📅 Original date posted:2022-03-20
📝 Original message:
Good morning everyone,
with regards to zerobasefee, I think that the argument that HTLCs are
costly doesn't quite hold up because they are always free to an
attacker as it stands. However, I fully agree with Zmn's opinion that
it's not necessary to bang our head against any opposition to this
because we can simply follow his excellent method for overweighing
base fee. I believe this is a very natural approach to let the market
decide on the relative importance of optimized routing vs base fees.
As to Martin's approximation research, I have asked myself similar
questions. Unfortunately, the paper you cite is paywalled and not
available at sci-hub, so I haven't read it. FWIW, I believe I have a
simple proof that minimum cost flow preserves approximation FACTORS:
Let O be the original problem and A the approximated problem such that
every flow in O can be mapped 1:1 to a flow in A and vice versa. Let
every edge e in O be represented by a set of edges in A whose total
cost is within a factor (1+epsilon) for every possible flow (could be
over- or underestimating). Note that this means that every flow in O
has cost within a factor (1+epsilon) for the corresponding flow in A
and vice versa.
Now let f_a be the min cost flow in A and f_o the min cost flow in O.
Assume that c(f_o)(1+epsilon)<c(f_a). Then f_o corresponds to a flow
in A that is cheaper than f_a, but that's impossible because f_a is
the min cost flow.
QED.
Problems might arise anyway because we represent probabilities only
logarithmically in the cost, so that a factor of (1+epsilon)
corresponds to an exponent (1+epsilon) for the probabilities. But René
seems optimistic that the resulting flows look good enough in
practice.
I am still optimistic that exact solvers with something like the cost
scaling approach might also be feasible (as long as they produce
integer flows), but I am happy that this simple approximation approach
seems good enough. This should save us a lot of work because there are
many linear min cost solvers available that represent years of
cumulative work in optimization research.
Cheers
Stefan
Am Sa., 19. März 2022 um 22:09 Uhr schrieb Martin via Lightning-dev
<lightning-dev at lists.linuxfoundation.org>:
>
> Dear Carsten, Rene and fellow lightning developers,
>
> Regarding the approximation quality of the minimum convex cost flow formulation for multi-part payments on the lightning network [1] and Carsten's discussion points on Twitter [2] and on the mailing list:
>
> > 8) Quality of Approximation
> >
> > There are some problems in computer science that are hard/impossible to
> > approximate, in the sense that any kind of deviation from the optimum
> > could cause the computed results to be extremely bad. Do you have some
> > idea (or proof) that your kind of approximation isn't causing a major
> > issue? I guess a piece-wise linearization with an infinite number of
> > pieces corresponds to the optimal result. Given a finite number of
> > pieces, how large is the difference to the optimum?
>
> I did some literature research and came across an insightful paper [3] by Dorit Hochbaum from 1993, that proves proximity results for integer and continuous optimal solutions of the minimum convex cost flow as well as proximity results of the optimal solutions for a piecewise linear approximation and the original problem.
>
> Admittedly theoretical results, however, it further underpins that a piecewise linear approximation is a reasonable approach to find optimal flows and even shows that searching for optimal solutions on the continuous domain (e.g. with descent methods from convex optimization) also gives near-optimal solutions on the integer domain.
>
> Cheers,
> Martin
>
> [1] https://arxiv.org/abs/2107.05322
> [2] https://twitter.com/renepickhardt/status/1502293438498234371
> [3] https://www.worldscientific.com/doi/abs/10.1142/9789812798190_0005
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:04:25 CEST

- reply

📅 Original date posted:2021-11-15
📝 Original message:
Actually, if you look into our paper, the theory tells us the following:
1) A weighted sum of different cost aspects is attractive because it
remains convex if all the aspects are convex themselves. This cannot be
said of other methods like the harmonic mean, which kind of forces our hand
if we aim to really calculate optimal flows.
2) even in the single path case, finding a route that optimizes one goal
(say, reliability) while ensuring that another cost aspect remains under
some boundary, is a (weakly) NP hard problem. My interpretation of this
fact is that while it is certainly possible to find suitable factors for
the linear combination (by, say, gradient descent methods), we cannot
expect a method that is simple and works for every conceivable graph every
time. In practice, we have observed that the factor needs to be varied over
multiple orders of magnitude to make a meaningful impact. Mapping this onto
an easy user interface (e.g. your suggestion of a linearly feeling value
between 0 and 1) will need some trial and error engineering, IMHO.
Cheers,
Stefan
René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am Mo., 15. Nov. 2021, 12:50:
> Dear Joost,
>
> First I am happy that you also agree that reliability can and should be
> expressed as a probability as discussed in [0].
>
> The problem that you address is that of feature engineering[1]. Which
> consists of two (or even more) steps:
>
> 1.) Feature selection: That means in payment delivery we will compute a
> min cost flow [2] with a chosen cost function (historically people used
> dijkstra seach for single paths with the cost function representing the
> weights on the edges of the graph -which is what most folks currently still
> do). While [2] and I personally agree with you that the cost function
> should be a combination the two features fees and reliability (as in
> successprobability) Matt Corallo righfully pointed out [3] that other
> features might be chosen in the future to deliver more optimal results. For
> example implementations currently often use CLTV as a feature (which I
> honestly find horrible) and I am currently investigating if one could add
> latency of channels or - for known IP addresses - either the geo distance
> or IP distance.
>
> 2.) Combining features: This is the question that you are asking. Often
> people use a linear weighted sum to combine features. This is what often
> happens implicitly in neural networks. While this is often good enough and
> while it is often practical to either learn the weights or give users a
> choice there are many situation where the weighted linear sum does not work
> well with the selected features. An example for the weighted sum is the
> risk-factor in c-lightning that could have been used to decide if one
> wanted the dijkstra seach to either optimize for CLTV delta or for paid
> routing fees. Also in our paper [2] in which we discuss the same two
> features that you mentioned we explain how a linear sum of two features can
> be optimal due to the lagrangian bounding principle. However in practice
> (of machine learning) it has been shown that using the harmonic mean [4]
> between features often works very well without the necessity to learn a
> weight / parameter. This has for example been done when c-lightnign
> recently switched to probabilistic path finding [5]. In this thread you
> find a long discussion and evaluation how the harmonic mean outperformed
> the linear sum.
>
> I think the main issue that you address here is that there is no universal
> truth for situations like this. In practice only tests and experience will
> help us to make good decisions.
>
> with kind Regards Rene
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-March/002984.html
> [1]: https://en.wikipedia.org/wiki/Feature_engineering
> [2]: https://arxiv.org/abs/2107.05322
> [3]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003219.html
> [4]: https://en.wikipedia.org/wiki/Harmonic_mean
> [5]: https://github.com/ElementsProject/lightning/pull/4771
>
>
>
>
> On Mon, Nov 15, 2021 at 4:26 PM Joost Jager <joost.jager at gmail.com> wrote:
>
>> In Lightning pathfinding the two main variables to optimize for are
>> routing fee and reliability. Routing fee is concrete. It is the sat amount
>> that is paid when a payment succeeds. Reliability is a property of a route
>> that can be expressed as a probability. The probability that a route will
>> be successful.
>>
>> During pathfinding, route options are compared against each other. So for
>> example:
>>
>> Route A: fee 10 sat, success probability 50%
>> Route B: fee 20 sat, success probability 80%
>>
>> Which one is the better route? That depends on user preference. A patient
>> user will probably go for route A in the hope of saving on fees whereas for
>> a time-sensitive payment route B looks better.
>>
>> It would be great to offer this trade-off to the user in a simple way.
>> Preferably a single [0, 1] value that controls the selection process. At 0,
>> the route is only optimized for fees and probabilities are ignored
>> completely. At 1, the route is only optimized for reliability and fees are
>> ignored completely.
>>
>> But how to choose between the routes A and B for a value somewhere in
>> between 0 and 1? For example 0.5 - perfect balance between reliability and
>> fee. But what does that mean exactly?
>>
>> Anyone got an idea on how to approach this best? I am looking for a
>> simple formula to decide between routes, preferably with a reasonably sound
>> probability-theoretical basis (whatever that means).
>>
>> Joost
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> https://www.rene-pickhardt.de
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211115/42fe9021/attachment-0001.html>

2023-06-09 15:03:34 CEST

- reply

📅 Original date posted:2021-08-24
📝 Original message:
Good Morning Zmn!
If you'd like to understand the min-cost flow problem and algorithms
better, I would really recommend the textbook we have been citing
throughout the paper.
The algorithm you have found has a few shortcomings. It'll only work for
the linear min-cost flow problem, and it is very slow. In reality, we need
to deal with convex cost functions, and the algorithm we have used so far
uses an approach called capacity scaling in order to be much faster. It is
indeed complex enough that it has taken us about two months to understand
and implement it, discovering a nice heuristic in the process of making
mistakes.
Separable in this context means that you can simply add up the costs of the
edges to get the total costs. On second thought, your definition would
probably work here , by redefining adding up.
Convex here means that for any two amounts x, y, the cost function f in the
interval x, y does not lie below the line connecting the two points (x,
f(x)) and (y, f(y)). The intuition here is that a linear approximation
never overestimates the real cost. I guess one would need a more involved
definition for your more complex coordinates.
Cheers,
Stefan
ZmnSCPxj <ZmnSCPxj at protonmail.com> schrieb am Di., 24. Aug. 2021, 01:06:
> Good morning Stefan,
>
> > Hi Zmn! That is some amazing lateral thinking you have been applying
> there. I'm quite certain I haven't understood everything fully, but it has
> been highly entertaining to read. Will have to give it a closer read when I
> get some time.
> >
> > As a first impression, here are some preliminary observations: While I
> highly like the Haskell-style datatype, and the algorithm we use does
> mostly use Dijkstra pathfinding, I think what is really important in your
> definition is the computeCost definition. This is what we would call the
> cost function IIUC, and in order to be able to solve min-cost flow problems
> it generally has to be separable and convex. I believe your datatype merely
> hides the fact that it is neither.
>
> Well, it really depends on what min flow cost algorithms actually assume
> of the "numbers" being used.
>
> For instance, it is well known that the Dijkstra-A\*-Greedy family of
> algorithms do not handle "negative costs".
> What it really means is that the algorithms assume:
>
> a + b >= a
> a + b >= b
>
> This holds if `a` and `b` are naturals (0 or positive), but not if they
> are integers.
> 1 + -1 = 0, and 0 >= 1 is not true, thus the type for costs in those
> algorithms cannot be integer types, they have to be naturals.
> However if you restrict the type to naturals, `a + b >= a` holds, and
> thus Dijkstra and its family of algorithms work.
>
> Thus, if you are going to use Dijkstra-A\*-Greedy, you "only" need to have
> the following "operations":
>
> `+` :: Cost -> Cost -> Cost
> `<` :: Cost -> Cost -> Bool
> zero :: Cost
>
> With the following derived operations:
>
> a > b = b < a
> a >= b = not (a < b)
> a <= b = not (b < a)
> a == b = (a >= b) && (a <= b)
> a /= b = (a < b) || (a > b)
>
> And following the laws:
>
> forall (a :: Cost) => a + zero == a
> forall (a :: Cost) => zero + a == a
> forall (a :: Cost, b :: Cost) => a + b == b + a
> forall (a :: Cost, b :: Cost, c :: Cost) => (a + b) + c == a + (b + c)
> forall (a :: Cost, b :: Cost) => a + b >= a
> forall (a :: Cost, b :: Cost) => a + b >= b
>
> As a non-mathist I have no idea what "separable" and "convex" actually
> mean.
> Basic search for "convex" and "concave" tends to show up information in
> geometry, which I think is not related (though it is possible there is some
> extension of the geometric concept to pure number theory?).
> And definitions on "separable" are not understandable by me, either.
>
> What exactly are the operations involved, and what are the laws those
> operations must follow, for the data type to be "separable" and "convex"
> (vs."concave")?
>
> I guess my problem as well is that I cannot find easy-to-understand
> algorithms for min cost flow --- I can find discussions on the min cost
> flow "problem", and some allusions to solutions to that problem, but once I
> try looking into algorithms it gets quite a bit more complicated.
>
> Basically: do I need these operations?
>
> `*` :: Cost -> Cost -> Cost
> `/` :: Cost -> Cost -> Cost --- or Maybe Cost
>
> If not, then why cannot `type Cost = UnifiedCost`?
>
>
> For example, this page:
> https://www.topcoder.com/thrive/articles/Minimum%20Cost%20Flow%20Part%20Two:%20Algorithms
>
> Includes this pseudocode:
>
> Transform network G by adding source and sink
> Initial flow x is zero
> while ( Gx contains a path from s to t ) do
> Find any shortest path P from s to t
> Augment current flow x along P
> update Gx
>
> If "find any shortest path" is implemented using Dijkstra-A\*-Greedy, then
> that does not require `Cost` to be an actual numeric type, they just
> require a type that provides `+`, `<`, and `zero`, all of which follow the
> laws I pointed out, *and no more than those*.
> `UnifiedCost` follows those laws (tough note that my definition of `zero`
> has a bug, `successProbability` should be `1.0` not `0`).
>
> In short --- the output of the cost function is a `UnifiedCost` structure
> and ***not*** a number (in the traditional sense).
>
> Basically, I am deconstructing numbers here and trying to figure out what
> makes them tick, and seeing if I can use a different type to provide the
> "tick".
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210824/75aad701/attachment-0001.html>

2023-06-09 15:03:33 CEST

- reply

📅 Original date posted:2021-08-21
📝 Original message:
Hi Zmn! That is some amazing lateral thinking you have been applying there.
I'm quite certain I haven't understood everything fully, but it has been
highly entertaining to read. Will have to give it a closer read when I get
some time.
As a first impression, here are some preliminary observations: While I
highly like the Haskell-style datatype, and the algorithm we use does
mostly use Dijkstra pathfinding, I think what is really important in your
definition is the computeCost definition. This is what we would call the
cost function IIUC, and in order to be able to solve min-cost flow problems
it generally has to be separable and convex. I believe your datatype merely
hides the fact that it is neither.
Intuitively, I think that any cost function that implies a fixed cost (that
is, independent of the amount, though it might be different for every edge)
per edge is concave and in theory problematic for min-cost flow algorithms
because you could reduce some kind of NP-hard selection problem to it. I
believe that applies to most if not all of your ideas in the text. Again, I
think we should think more about how much of a problem that is in practice,
because we do have tools like approximation and parameterized algorithms,
as well as heuristics, and I also believe that, say, a moderate base fee
will not change the optimal flow much, because this will always prefer
large Htlcs anyway in order to optimize probability.
I am really grateful that you have been taking the time to read and
understand our paper and have been thinking further in this fascinating
way. I am certain good things will come of it in time.
Cheers,
Stefan
ZmnSCPxj <ZmnSCPxj at protonmail.com> schrieb am Sa., 21. Aug. 2021, 03:49:
>
> > Alternative Pathfinding?
> > ========================
>
>
> Or to put this section more succinctly: Why should cost be a number?
>
> What operations do the minimum cost flow algorithms demand of this thing
> called "cost", and can we provide those operations using something which is
> not a number but is instead a different structure?
> What is the minimal interface that the mincostflow algo demands of this
> "cost" datatype?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210821/02ef209c/attachment.html>

2023-06-09 15:03:28 CEST

- reply

📅 Original date posted:2021-08-16
📝 Original message:
Hi Zmn et al.,
>I propose that the algorithm be modified >as such, that is, it *ignore*
the fee scheme.
We actually started out thinking like this in the event we couldn't find a
proper way to handle fees, and the real world experiments we've done so far
have only involved probability costs, no fees at all.
However, I think it is non-trivial to deal with the many cases in which too
high fees could occur, and in the end the most systematic way of dealing
with them is actually including them in the cost function.
That said, I agree with Matt that more research needs to be done about the
effect of base fees on these computations. We do know they make the
problem hard in general, but we might find a way to deal with them
reasonably in practice.
I tend to agree with AJ, that I don't believe the base fee is economically
helpful, but I also think that the market will decide that rather than the
devs (though I would argue for default Zerobasefee in the implementations).
In my view, nobody is really earning any money with the base fee, so the
discussion is kind of artificial. On the other hand, I would estimate our
approach should lead to liquidity being priced correctly in the
proportional fee instead of the price being undercut by hobbyists as is the
case now. So in the long run I expect our routing method to make running a
well-stocked LN router much more profitable.
Cheers,
Stefan
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am Mo., 16. Aug. 2021, 05:15:
> Good morning matt and aj,
>
> Let me cut in here.
>
> From my reading of the actual paper --- which could be a massive
> misunderstanding, as I can barely understand half the notation, I am more a
> dabbler in software engineering than a mathist --- it seems to me that it
> would be possible to replace the cost function in the planning algorithm
> with *only* the negative-log-probability, which I think is the key point of
> the paper.
>
> That is, the algorithm can be run in a mode where it *ignores* whatever
> fee scheme forwarding nodes desire.
> (@rene: correct me if I am wrong?)
>
>
> However, the algorithm then gets an extra step after getting a payment
> plan (i.e. how to route multiple sub-payments).
> It looks over the payment plan and if the fees involved are beyond some
> user-defined limit (with, say, a default of 0.5% of the total amount, as
> per the C-Lightning `pay` default), to look at the highest-fee channels in
> the payment plan.
> Then, it can rerun the flow algorithm, telling it to *disallow* the
> highest-fee channels identified if the total fees exceed the fee budget.
>
> It seems to me that this modification of the algorithm may be sufficient
> to be resilient against any and all future fee scheme we may decide for
> Lightning.
>
> This still achieves "optimality" in the sense of the paper, in a way
> similar to what is suggested in the paper.
> The paper suggests to basically ignore gossiped channels with non-zero
> basefee.
> The approach I suggest allows us to *start* without ignoring non-zero
> basefee, but to slowly degrade our view of the network by disallowing
> high-fee (whether high basefee or high propfee) channels.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210816/f60fa4a3/attachment.html>

2023-06-09 14:41:04 CEST

- reply

2023-06-08 01:11:34 CEST

- reply

📅 Original date posted:2022-07-11
📝 Original message:I very much agree with AJ here. This is something I remember discussing on
Bitcointalk back in 2011: I find it highly intuitive that the amount of
lost coins is not a constant fraction of the supply, because people get
better at keeping their coins with increasing value, distribution and
technology/best practices. I also think that we have observed this effect
in practice since then. The bulk of coins that are supposed to be lost (via
onchain analysis) haven't been moved since at least 2010. Of course, in
most cases, we'll never know, but the assumption of constant loss rate
seems unreasonable.
Cheers
Stefan
Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
schrieb am Mo., 11. Juli 2022, 04:32:
> On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote:
> > title: "Surprisingly, Tail Emission Is Not Inflationary"
>
> > Of course, this isn't realistic as coins are constantly being lost due to
> > deaths, forgotten passphrases, boating accidents, etc. These losses are
> > independent:
>
> This isn't necessarily true: if the losses are due to a common cause,
> then they'll be heavily correlated rather than independent; for example
> losses could be caused by a bug in a popular wallet/exchange software
> that sends funds to invalid addresses, or by a war or natural disaster
> that damages key storage hardware. They're also not independent over
> time -- people improve their key storage habits over time; eg switching
> to less buggy wallets/exchanges, validating addresses before using them,
> using distributed multisig to prevent a localised disaster from being
> catastrophic.
>
> > the *rate* of coin loss at time $$t$$ is
> > proportional to the total supply *at that moment* in time.
>
> This is the key assumption that produces the claimed result.
>
> If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins
> each year, then as soon as the supply increases enough that the constant
> reward, k, corresponds to the constant fraction, ie k = x*N(t), then
> you've hit an equilibrium. (Likewise if you're losing more than you're
> increasing -- you just need to wait until N(t) decreases enough that you
> reach the same equilibrium point) You don't really need any fancy maths.
>
> But that assumption doesn't need to be true; coins could primarily be
> lost in "black swan" events (due to bugs, wars or disasters) rather
> than at a predictable rate -- with actions taken thereafter such that
> the same event repeating is no longer the same level of catastrophe,
> but instead another new black swan event is required to maintain the same
> loss rate. If that's the case, then the rate at which funds are lost will
> vary chaotically, leading to "inflationary" periods in between events,
> and comparatively strong deflationary shocks when these events occur.
>
> Alternatively, losses could be at a predictable rate that's entirely
> different to the one Peter assumes.
>
> One alternative predictable rate that seems plausible to me is if funds
> are lost due to people not be careful about losing small amounts; even
> though they are careful when amounts are larger. So when 10k BTC was
> worth $40, maybe it doesn't matter if you misplace a hard drive with
> 7500 BTC on it since that's only worth $30; but by the time 7500 BTC
> is worth $150M, maybe you take a bit more care with that, but are still
> not too worried if you lose 1.5mBTC, since that's also only worth $30.
>
> To mathematise that, perhaps there are K people holding Bitcoin, and with
> probability p, each loses $100 (in constant 2009 dollars say, so that we
> can ignore inflation) of that Bitcoin a year through carelessness. For
> an equilibrium to occur in that case, you need:
>
> N(t) + k - (100/P * Kp) = N(t)
>
> where P is the price of Bitcoin (again in constant 2009 dollars) and k
> is Peter's fixed tail subsidy. Simplifying gives:
>
> P = K * 100p/k
>
> But k and p are constant by assumption in this scenario, so equilibrium
> is reached only if price (P) is exactly proportional to number of
> users (K). That requires you to have a non-inflationary currency
> (supply is constant) with constant adoption (assume K doesn't change)
> that maintains a constant price (P=K*100p/k) in real terms even if the
> economy is otherwise expanding or contracting.
>
> More importantly, just from a goals point of view, x is something we
> should be finding ways to minimise it over time, not leave constant.
> In fact, you could argue for an even stronger goal: "the real value held
> in BTC lost each year should decrease", that is, x should be decreasing
> faster than 1/(N(t)*P).
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/2289f5fd/attachment-0001.html>

2023-06-07 20:20:21 CEST

- reply

📅 Original date posted:2019-08-21
📝 Original message:Please see the github issues and the twitter discussion (e.g. here:
https://twitter.com/stefanwouldgo/status/1163801056423403520) for similar
points other people including me have made. At this point I feel there are
quite a few unclear points in the presentation and it is not clear to me if
they can be salvaged.
Am Mi., 21. Aug. 2019 um 09:32 Uhr schrieb ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Good morning Maxim,
>
> The Deaf Bob Attack
> ===================
>
> It seems to me that Bob can promote the N3 problem to the N2 problem.
>
> Suppose Alice contacts Bob to get the data.
> However, Bob happens to have lost the data in a tragic boating accident.
>
> Now, supposedly what Alice does in this case would be to broadcast the
> HTLC settlement transaction, whose signature was provided by Bob during
> protocol setup.
>
> But this seems unworkable.
>
> * If Bob managed to sign the HTLC settlement transaction, what `SIGHASH`
> flags did Bob sign with?
> * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected
> the decryption key at setup time.
> * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including
> `<Alice> OP_CHECKSIG`.
>
> If Bob already selected the decryption key at setup time, then Bob can
> ignore Alice.
>
> * If Alice does not publish the HTLC settlement transaction, then Bob will
> eventually enter the N2 state and get the stake+reward.
> * If Alice *does* publish the HTLC settlement transaction, without Bob
> giving the encrypted data, then Bob can just use the hashlock and reveal
> the decryption key.
> * The decryption key is useless without the encrypted data!
>
> It seems this part is not workable?
> As the decryption key is embedded in the HTLC, Alice cannot get a
> signature from Bob without the decryption key already being selected by Bob
> (and thus already claimable even without any data being returned by Bob).
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190821/25a4c8a0/attachment-0001.html>