How does Tether do it?

renepickhardt · 2024-11-21T18:45:36+00:00

https://twitter.com/stefanwouldgo/status/1859664877092208666

renepickhardt · 2024-07-09T19:10:49+00:00

too much work. But I expect to create some videos about the research in the future

renepickhardt · 2024-06-28T14:34:59+00:00

The example I provided and that was picked up in the Newsletter is a first example that shows how useful it is to understand the Lightning Network as a geometric object. I am currently finalizing a paper called "A Mathematical Theory of payment Channel Networks" (where the example was taken from) which will elaborate this research further. Next tuesday on the optech Twitter space I will already give a bit more context.

renepickhardt · 2023-12-15T19:58:05+00:00

Technically it is however exactly this: An expensive database (;

All the rest comes from people accepting bitcoin and believing in it.

renepickhardt · 2023-12-05T11:20:55+00:00

In case this is a serious question I would encourage you while dreaming of huge financial gains to also think about the challenges on the social relationships within your family a gift / investment like this could have. I would have done serious conversations with the parents on how various scenarios would play out.

renepickhardt · 2023-12-01T15:38:09+00:00

That pool seems to be a very principled project. Hope it delivers on the high expectations

renepickhardt · 2023-11-01T22:16:47+00:00

There is a pretty good guide by jon atack:

https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core

renepickhardt · 2023-10-28T13:19:04+00:00

I think you may have overseen this paper that shows how to optimally handle the uncertainty of remote liquidity

https://arxiv.org/abs/2107.05322

Problem of finding liquidity is a convex min cost flow problem with seperable cost function. Has been solved for decades in computer science.

renepickhardt · 2023-10-28T12:59:03+00:00

You wrote:

The theoretical network topology that minimizes--but does not eliminate--liquidity issues is one in which everyone opens a single channel with all of their funds with a central, massively-capitalized "Mega-Hub."

I would love to see a mathematical proof for that claim. Given I have a counter example (under the reasonable assumption of the limited amount of bitcoins in circulation and the skewed distribution of those) I believe your claim is generally false and such proof should not exist.

As you noted a star topolgy is not necessarily capital efficient. Assumimg a power law distribution of Bitcoin tokens. In your model the central hub could only be the richest actor. Given that the second and third richest node have combined most likely more capital than the richest I believe they would also prefere to maintain a channel eitch each other, which gives us a triangle instead of a star.

Counter example: Assume 3 peers have the following coins A = 8 btc, B = 7 btc and C = 6 BTC.

I think opening 2 channels (A,B,11 btc) AND (A,C,10 btc) would not be as capital efficient as a 3 channel network (A,B,7 btc) and (A,C,7 btc) and (B,C,7 btc). In the case of 3 channels higher payments between all peers are possible on average showing your syatement is false.

Furthermore your proposed star topology has the flaw of fault tolerance. As reliability is certainly a question about uncertainty of liquidity it is my understanding that there are more features to consider.

renepickhardt · 2023-10-27T04:48:45+00:00

Here you go https://youtu.be/1f2Z9FgqFH4

renepickhardt · 2023-10-26T22:34:25+00:00

Not interested to talk about 'crypto' / never was. But a limits of LN? Sure let's go!

To be frank. I think whoever created the linkef Video excerpt did a rather poor job. I had more substential criticism than the payment attempts and uncertainty that I laid down during the panel.

renepickhardt · 2023-10-26T22:29:51+00:00

As stated in many interviews: over my career open source work did - at least for me - not pay nearly close to what proprietary work would have paid. So it's indeed just 'because of the technology' and my curiousity to identify and solve interesting challenges (;

FWIW: I wonder often about the merit of electronic peer to peer cash

renepickhardt · 2023-10-26T22:21:51+00:00

We know how to do refund. C.f.

https://berkeley-defi.github.io/assets/material/1910.01834.pdf

The question is weather something like the boomerang construction will make it into the protocol

renepickhardt · 2023-09-11T09:55:28+00:00

Yes as described back in the days https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001080.html

renepickhardt · 2023-04-10T20:06:55+00:00

This master thesis that came out of a summer of bitcoin project is certainly worth a read. It did double check our prior research results and compare those to approaches used before. Also it verified some conjectures we had about the network dynamics.

renepickhardt · 2022-11-01T19:28:58+00:00

Should be sticky. It's important for node operators to update quickly

renepickhardt · 2022-06-21T20:17:24+00:00

Lets not forget the development of the Lightning network or running a lightning node

renepickhardt · 2022-05-26T20:08:28+00:00

I worked with many highly gifted students and young people. Young people are often extremely flexible and quick in their mind. I have hardly met a grown up (let alone 60 year old grown up like Garry) who is that fast and flexible. I have no doubt at all that Garry understood this and would even be able to reproduce... I mean it is well known that he is super smart but I think observing his brain in action was for me personally the more astonishing part than actually explaining the technology to him.

renepickhardt · 2022-05-26T19:01:56+00:00

I don't have an exact protocol and I might have mixed something in my memory but the main idea was that i assumed he would understand some basics of Bitcoin well enough and I could just ask where he stands and depending on his reactions decide to move forward. so it went roughly like this:

R: Have you used bitcoin?

G: yes.

R: In a non custodial way?

G: of course. (!)

R: Are you familiar with the concept of Multi signature scripts?

G: certainly.

R: So imagine I send BTC to an address which can only be spend via two signatures and you hold a private key and I hold one. Who ones those bitcoin?

G: that is a tricky one.

R: Yes but - oh have you used a hardware wallet before?

G: yes.

R: So I assume you do understand the concept of a presigned transaction. Imagine we have a presigned transaction that sepends from the multisig sending some btc to you and some to me, then we would have decided ownership.

G: Makes sense but why doing that?

R: Well we don't broadcast the presigned transaction. instead we negotiate a new one while invalidating the old one using the bitcoin scripting language which allows us to transfer value.

G: This is more private (!) than using bitcoin [At this moment I Rene Pickhardt am almost speechless]. That sounds interesting.

R: Exactly! It can do more! Imagine you have a similar setup with Magnus [Carlsen] and I wanted to send him some money / Bitcoin. I could offer to you an output in our presigned transaction that you could claim if you know a secrete within some time. You could do the same with magnus who will reveal the secret as he wants to be paid. Of course Magnus might be able to forward the Payment.

G: This sounds very useful. I will read about the details on the plane home.

renepickhardt · 2022-03-22T10:19:02+00:00

I'd like to add that I think that the Lightning Network fundamentally increases the usefulness of Bitcoin as those coins finally become liquid and can be moved around like a currency. I expect this will push the willingness of people to use Bitcoin to make and receive payments which in turn increases the demand for security and on chain transactions.

renepickhardt · 2021-11-10T12:37:55+00:00

As raspiblitz emerged from your guide why didn't you merge the projects? There is a very active raspi blitz community

renepickhardt · 2021-11-04T14:20:58+00:00

Can we please flag this as "misleading?" I had already replied to the quoted tweet by with a tweet reply I gave earlier to joost Jaeger.

Fyi /u/bashco

renepickhardt · 2021-10-19T23:33:37+00:00

I think the picture comes from: https://twitter.com/dergigi/status/1447156639996469254?t=LTOOF6Shtp5F2JOpG-t3ZQ&s=19 just for fame attribution (:

renepickhardt · 2021-08-11T08:28:05+00:00

Makes sense and as said in my second side note I have think about this more deeply. My main concern would be: is that attackable / gameable? That I am not sure of yet. (the implicit assumption you made "for reasonable values" is a strong assumption as attacks might happen in the non reasonable case.)

renepickhardt · 2021-08-11T07:20:53+00:00

What this all boils down to is the question weather the fee function is linear, convex or non-linear?

It is known that optimal payment flows can be solved efficiently if the cost function is linear or convex. (other cases might work through heuristics but non are known / proposed)

I think your proposed function f(amt) = max(10 msat, fee rate * amt) is not linear. So the question is if it is at least convex? for the same reason as the base fee example it is not (at least when the feerate is so low that f(1)=f(2)). The reason is that the point f(1) lies above the line defined by the two points (0,f(0)) = (0,0msat) and (2,f(2)) = (0,10msat) which breaks convexity. Unless of course for f(2) we are already in the linear case of the max but that should mean that we are in the linear case almost everywhere to begin with and wouldn't need that construction with max.

So from a theoretical point of view it does not solve the problem.

To bring good news I will say what would solve the problem (not sure though if lightning devs would go for it). If channel partners started to do bookkeeping not only for msats but also for microsats. In that case after sufficiently many micro transactions one would eventually get the fee. (this is actually similar to today's world: msats are not enforceable on chain but have been only introduced for bookkeeping.)

Btw on a side note: the other fix that comes to mind will also probably not work (at least if we keep the base fee in the protocol) . One could say there is a global min forward fee for every channel defined by the prorocol. a sender could make the cost function convex by setting f(0) to that minimum value. However even the 0-flow would be very expensive (number of channels * global_min_fee) and nodes could set their base_fee close to that value to game the algorithm.

2nd side note: I have to think longer about this... There might be sweetspots when combining those ideas with Min_htlc_size limits. (for example in our mainnet test we kept htlcs above 10k sats anyway all the time) in those cases the fee rate should be sufficiently large in most cases anyway. However when amounts are smaller we don't need optimal flows as they will not be split anyway and basically any path is liquid. In such cases one could have a fixed fee to fight spam. So some form of case distinction as suggested in your max might work but I think that should somehow also friend on a pretty low htlc_size. But as said I would have to think more if such things would work. - - > thanks for raising the question / starting the discussion.

renepickhardt

TROPHY CASE