Pierre [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-20 to 2022-09-03
💬 Posted a total of 51 messages
📚 Participated in the following categories: Lightning-dev, PATCH v3, RFC, 1.1, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdt

Profile Code

nprofile1qqszprn6g6vhjxszvjsznrl6vpzkc5dv3kyeyzt2rdnn3xt9anxg9lcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswm5fun

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdt

Show more details

Last Notes

2023-06-09 15:04:29

- reply

📅 Original date posted:2021-11-23
📝 Original message:
> so You propose Acinq / Blockstream / Lightning Labs do not have funds to
run a box or 2 ?
Fwiw we already do that with our main node. It's even better than a demo
one because it has real economic activity, and has a lot of channels to a
variety of nodes implementations and versions.
Sometimes our node is behind eclair master branch, but it's always
up-to-date for critical commits and releases. So we eat our own dog food
and will experience force closes before our users do.
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/fa3738a8/attachment.html>

2023-06-09 14:57:08

- reply

📅 Original date posted:2019-11-22
📝 Original message:
> The high-level idea would be that the sender must solve a small PoW puzzle
<insert meme: "Yo dawg I heard you like pow systems..." >

2023-06-09 14:56:39

- reply

📅 Original date posted:2019-10-11
📝 Original message:
Hi Rusty,
That seems reasonable.
Cheers,
Pierre

2023-06-09 14:55:36

- reply

📅 Original date posted:2019-07-18
📝 Original message:
Hi Rusty,
How would bruteforcing on the CSV delay be different from a BIP32
wallet with look ahead keys? Especially given that we could try with
most probable values first.
Cheers,
Pierre

2023-06-09 14:55:03

- reply

📅 Original date posted:2019-06-05
📝 Original message:
Hello Ugam,
The HTLC-Timeout transaction
<https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions>
is timelocked (with locktime=cltv_expiry).
Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190605/df870013/attachment.html>

2023-06-09 14:54:47

- reply

📅 Original date posted:2019-04-03
📝 Original message:
> This is not an issue. Like we discussed for the multi-part payments the HTLCs still resolve correctly
Right! Great, missed that

2023-06-09 14:54:47

- reply

📅 Original date posted:2019-04-03
📝 Original message:
Hello ZmnSCPxj,
> Do you refer to the changing from "H"TLC to "P"TLC point-locked timelocked contracts?
> i.e. instead of payment hash / preimage, we use payment point / scalar.
Yes, that is what I meant. Cryptography isn't my strong suit though,
so I'm not able to go into much more details.
Cheers,
Pierre

2023-06-09 14:54:46

- reply

📅 Original date posted:2019-04-01
📝 Original message:
Hello ZmnSCPxj,
> Unless we propose to massively change the onion packet construction...?
I'm afraid we would have to make some changes. I imagine we would have
two onions:
- one for the adjacent hops (this is the onion we are currently using)
- one for the trampoline hops
The 'trampoline onion' would be contained in the per-hop payload of
the final node of the 'adjacent onion'. So in your example B would:
1) receive the htlc
2) see that it is the last hop in the route, and extract the trampoline payload
3) peel the trampoline onion and see that it should delegate the payment to C
4) find a route to C and set the trampoline onion as payload for C
I haven't studied PR #593 enough to tell how easy that would be
achievable though.
There is another unrelated issue: because trampoline nodes don't know
anything about what happened before they received the onion, they may
unintentionnaly create overlapping routes. So we can't simply use the
payment_hash as we currently do, we would have to use something a bit
more elaborate. (maybe private keys?)
Cheers,
Pierre

2023-06-09 14:54:38

- reply

📅 Original date posted:2019-03-28
📝 Original message:
Hello List,
I think we can use the upcoming "Multi-frame sphinx onion format" [1]
to trustlessly outsource the computation of payment routes.
A sends a payment to an intermediate node N, and in the onion payload,
A provides the actual destination D of the payment and the amount. N
then has to find a route to D and make a payment himself. Of course D
may be yet another intermediate node, and so on. The fact that we can
make several "trampoline hops" preserves the privacy characteristics
that we already have.
Intermediate nodes have an incentive to cooperate because they are
part of the route and will earn fees. As a nice side effect, it also
creates an incentive for "routing nodes" to participate in the gossip,
which they are lacking currently.
This could significantly lessen the load on (lite) sending nodes both
on the memory/bandwidth side (they would only need to know a smallish
neighborhood) and on the cpu side (intermediate nodes would run the
actual route computation).
As Christian pointed out, one downside is that fee computation would
have to be pessimistic (he also came up with the name trampoline!).
Cheers,
Pierre-Marie
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-February/001875.html

2023-06-09 14:51:33

- reply

📅 Original date posted:2018-10-08
📝 Original message:
> But there's no reason to believe that the invoicer has more knowledge about all but the last hop.
I disagree: there is a good chance that the receiver is a 24/7 running
merchant/website, with a full up-to-date view of the network, whereas
the payer is most likely a mobile wallet with less
accurate/partial/out of date information.
At least this is what we are seeing on the current mainnet. Routing
table sync is hard on mobile clients, and I think that it makes sense
that receivers "help" senders, after all incentives are aligned.
Cheers,
Pierre

2023-06-09 14:51:32

- reply

📅 Original date posted:2018-10-04
📝 Original message:
Ha! I actually came up with the idea two months ago (but you beat me
to it on the implementation so we're even :-)
https://github.com/ACINQ/eclair-wallet/issues/101#issuecomment-408619207
Le jeu. 20 sept. 2018 à 04:12, Rusty Russell <rusty at blockstream.com> a écrit :
>
> Hi all,
>
> I'm considering a change to c-lightning, where `invoice` would
> automatically append an 'r' field for a channel which has sufficient
> *incoming* capacity for the amount (using a weighted probability across
> our peers).
>
> This isn't quite what 'r' was for, but it would be a useful
> hint for payment routing and also potentially for establishing an
> initial channel. This is an issue for the Blockstream Store which
> deliberately doesn't advertize an address any more to avoid
> centralization.
>
> Thoughts welcome!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:48:32

- reply

📅 Original date posted:2018-01-12
📝 Original message:
Hi Johan,
That's an interesting corner case. I think it shares some similarities
with the race condition described in BOLT 2 [1], which handling is
specified in BOLT 3 [2].
Note that what matters really is the timing of the
`commit_sig`/`revoke_and_ack` messages, not the `update_add_htlc`s,
because of the acknowledgment logic that excludes remote's unsigned
updates. A side effect is that there can be multiple HTLCs on each
side.
Each party will end up receiving a commitment tx which has
insufficient (possibly zero) fees. At that point according to [2] it
may decide to fail the channel, using its previous commitment (which
it hasn't yet revoked). Currently eclair won't fail the channel, but I
think we probably should, especially if we are the fundee and would
end up with all funds in an unpublishable tx. The funder could face
the same situation if the pending htlcs have a high value (at this
point its main output is zero anyway).
An appropriate choice of channel parameters (`mainly
max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`,
`max_accepted_htlcs`) could probably reduce the probability of this
happening.
Hope that helps,
Pierre
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee
[2] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment

2023-06-09 14:47:09

- reply

📅 Original date posted:2017-05-02
📝 Original message:
>> On the topic of signatures: as is proposed now, a user isn't able to verify
>> the validity of the signature (and thereby authenticity of the payreq and
>> integrity of the contents) without first having a (direction || chanID) ->
>> pubKey mapping. In my opinion, the payreqs are already so long that
>> optimizing for size is a bit of a waste. By replacing the chanID with the
>> compressed serialized public key, users will be able to immediately verify
>> the signature without the use of an external mapping.
As much as I pushed for using the short chanID in the onion, I too am
a reluctant to use
it here. In addition to laolu's arguments, I would say:
- making the assumption that the network is well-known doesn't take
into account the fact
that announcements take time to propagate through the network
(typically a few minutes with
staggered broadcast every minute); ok it doesn't change often, but now
we will need to worry
about not using our most recently created/closed channels as reference.
- we already know that we won't always be able to have a full view of
the network in
the future, so I feel like we should rely on it as less as possible
- since payment requests are sent out-of-band, optimizing their size
is maybe not as
important as messages exchanged on the p2p network?
>As you pointed out offline, we can do key recovery from the signature[1],
>so the information is there already in fact :) The chanid is really a
>courtesy, from this POV.
That is really amazing! Why not completely ditch the chanid then? ;-)
Cheers,
Pierre
2017-05-02 2:40 GMT+02:00 Rusty Russell <rusty at rustcorp.com.au>:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> Hi Rusty,
>>
>> I was thinking of proposing something similar recently, but looks like you
>> beat me to it!
>>
>> I really like the flexibility of the tag format. Over the past few months, I
>> thought of quite a bit of things application developers can do by utilizing
>> a tag-based payment request format in conjunction with either: the spare
>> bytes of the onion payload or an abuse of the encrypted back errors (in
>> combo with some onion payload bytes).
>
> Yes, I thought about this too, but I'm reluctant to assign those onion
> bytes as they're a limited resource. Easy to add later, though.
>
>> On the topic of bech32: I'm all for piggybacking on existing emerging
>> standards in the space, but I'm not convinced we really gain anything by
>> using it outside of the initial prefix. The human-readable amount within the
>> prefix is nice for UX as you can eyeball exactly how much one is about to
>> pay/receive. However, these payment requests can get rather long, so I don't
>> envision any user typing them out by hand or reading them to someone over
>> the phone. As a result, I don't think we have much use for bech32 character
>> which has been optimized for manual-entry. Additionally, as this proposal
>> includes a signature that covers the entire payreq, what's the use of the
>> added checksum? Detecting 3 characters out of 1024+ is rather
>> insignificant.
>
> I kind of agree, but I think the code reuse outweighs other arguments,
> since codebases are going to have bech32 anyway.
>
> The minimal theoretical size we can do is 20 (payment hash160) + 64
> (signature). We'd have to change the protocol to use hash160 instead of
> sha256 (we already do this onchain). But even that is 135 characters,
> which is not going to be entered by hand, so I don't think it's worth
> it.
>
>> On the topic of signatures: as is proposed now, a user isn't able to verify
>> the validity of the signature (and thereby authenticity of the payreq and
>> integrity of the contents) without first having a (direction || chanID) ->
>> pubKey mapping. In my opinion, the payreqs are already so long that
>> optimizing for size is a bit of a waste. By replacing the chanID with the
>> compressed serialized public key, users will be able to immediately verify
>> the signature without the use of an external mapping.
>
> As you pointed out offline, we can do key recovery from the signature[1],
> so the information is there already in fact :) The chanid is really a
> courtesy, from this POV.
>
>> I think this is a good step in the right direction. However, it utilizes an
>> encoding whose rationale make sense for the Bitcoin address use-case, but in
>> my opinion, doesn't carry over those compelling traits to the LN payreq
>> use-case.
>
> Thanks!
> Rusty.
> [1] You also pointed out that we can use the same technique to remove
> node-id and bitcoin-key from the channel announcement. Which would
> be awesome magic...
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:46:16

- reply

📅 Original date posted:2016-05-18
📝 Original message:
I like it! Let's hope it will suit everyone and we can converge on
something soon.
FWIW I was able to independently implement a toy version of the
protocol and pass your scripted tests [*] so I guess there are no
obvious issues (duh). Maybe it could be the first step towards a LN
nonreg test set?
Just one thing about the "nocommitwait", I wonder why you make it
optional in your test: why would you forbid the sending of two
successive commits, given that the more permissive approach is
perfectly well defined?
Cheers,
Pierre
PS: what does YA mean?
[*] For those interested:
https://gist.github.com/pm47/0c87329dbc5d43d35857e5ba3a20400c

2023-06-09 14:46:10

- reply

📅 Original date posted:2016-04-24
📝 Original message:
Hello,
I am trying to understand how we should handle concurrent signatures,
and I am wondering if we couldn't use an ordering of some sort to
resolve conflicts when they occur, for example by simply comparing
signatures. If two nodes send each other a signature at the same time,
they could agree that the one that sent the "greatest" signature has
to immediately resend a new signature including all pending changes.
This new signature would encompass all the changes both parties wanted
in the first place so everybody would be happy.
For example if "SIG B0 > SIG A0":
NODE A NODE B
Committed: [] Committed: []
Staged: [X] Staged: [Y]
ADD HTLC X ---- ---- ADD HTLC Y
\ /
\ /
Committed: [X] \ / Committed: [Y]
Staged: [] \/ Staged: []
SIG A0 --- /\ --- SIG B0
\ / \ /
\/ \/
/\ /\
<--- \ / --->
Committed: [X] \/ Committed: [Y]
Staged: [Y] /\ Staged: [X]
/ \
/ \
DISCARD SIG A0 <---- -----> DISCARD SIG B0
Committed: [] Committed: []
Staged: [X Y] Staged: [X Y]
Committed: [X Y]
Staged: []
<---------------- SIG B1
Committed: [X Y]
Staged: []
REVOCATION ---------------->
SIG A1 ---------------->
<---------------- REVOCATION
Cheers,
Pierre

2023-06-09 14:46:05

- reply

📅 Original date posted:2016-04-01
📝 Original message:
Hello all,
I noticed in the meantime Rusty recently introduced htlc ids in the
form of absolute "lnd-like 64 bits unique id" vs the previous relative
"order-I-added-them-in" id. I like it better and I think this is
closely related to the issue at hand.
> This is used so we know what the other side has received when they send
>an "update_commit" message, and so we know where to restart the
>conversation after reconnect ("authenticate" message).
To me those two cases should be handled differently because they do
not happen at the same level:
- at the protocol level I would only use the htlc id. It is currently
already used in add/fulfill/fail, so it would make sense to have it in
the update_commit msg as well, instead of relying on the acknowledge
field
- at the transport level (including the reconnect scenario) I would
rely on the acknowledge field to know which messages should be
replayed
Yes it is kind of redundant, and probably less optimal, but it does
separate clearly the transport from the protocol and testing might be
easier.
Also @lnd guys: what's the thing with odd/even htlc ids? Is it just so
that we can use the same keyspace for incoming/outgoing htlcs and
quickly tell the direction of a given htlc, or is there something
else?
Cheers,
Pierre

2023-06-09 14:45:08

- reply

📅 Original date posted:2015-11-19
📝 Original message:
> it will be a talk at Scaling Bitcoin HK.
That's great news! Looking forward to it

2023-06-09 14:45:07

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Hi guys,
Do you know of any available resources on "segregated witness" ? I
couldn't find any.
Cheers,
Pierre

2023-06-09 14:45:00

- reply

📅 Original date posted:2015-10-27
📝 Original message:
Hello aj,
This is very interesting, thanks!
You seem to be considering that bitcoin tx and lightning tx are completely
independent, which is not entirely true because of anchor transactions.
While this is certainly a valid assumption, maybe it would be worth stating
it explicitely ?
Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/704b7bd3/attachment.html>

2023-06-09 14:44:57

- reply

📅 Original date posted:2015-10-27
📝 Original message:
A few more remarks:
> 2) ECDH is used to derive a shared secret. From this we generate
> the following transmission encoding parameters for each side:
> Session AES-128 key: SHA256(shared-secret || my-sessionpubkey || 0)
> Session HMAC key: SHA256(shared-secret || my-sessionpubkey || 1)
> IV for AES: SHA256(shared-secret || my-sessionpubkey || 2)
I suppose we use only the first 16 bytes for aes_key and aes_iv ?
> 3) All packets from then on are encrypted of form:
> /* HMAC, covering totlen and data */
> struct sha256 hmac;
> /* Total data transmitted (including this). */
> le64 totlen;
> /* Encrypted contents, rounded up to 16 byte boundary. */
> u8 data[];
Looking at your code it seems totlen is actually the size of the
unencrypted serialized protobuf message, not the total data
transmitted right ? If so, the comment is a bit misleading, and why
make totlen include the length of itself since it doesn't define the
encrypted message boundaries anyway ?
Also, why encode the length on 64 bits rather than 32 bits ?
Cheers,
Pierre

2023-06-09 14:44:56

- reply

📅 Original date posted:2015-10-27
📝 Original message:
Hi Rusty,
> 5) Unknown protobuf fields are handled in the protocol as follows
> (including in the initial Authenticate packet):
>
> 1) Odd numbered fields are optional, and backwards compatible.
> 2) Even numbered fields are required; abort if you get one.
I don't get it, what is it about ?
Thanks,
Pierre

2023-06-09 14:44:39

- reply

📅 Original date posted:2015-09-24
📝 Original message:
Hi Rusty,
> 1) Close now has an second ACK stage, which means you know the close ack
> has been received.
Argh, I already have trouble understanding the rationale behind all
the existing closing flows and states :-s Would it be possible to
publish an updated version of the svg ? aj, any chance you could do
the same with your 'flat' version ?
> 3) HTLC rejection (eg. bad route, insufficient fees) added.
How about the 'commit tx too big' case ? will that just be an error ?
> As a secondary effect, 32 bits places [an upper bound of 0.04 BTC]
> (currently about $10USD) on each HTLC. That's more than enough to cover
> the micropayment uses of lightning, yet if you lose all your money due
> to a horrible bug in the early days, I can buy you a beer and count us
> about even[1]. And we can change the protocol later if it becomes
> overly limiting.
Such a low ceiling bothers me a little bit, because it kind of states
that the micropayment use case is the primary target. Is it ? To me,
scalability and speed are the most interesting properties of
lightning. I would have preferred a higher (1 BTC ?) limit, but I
understand this can be changed. Regarding the risk of bugs, you can't
loose more than the channel capacity so that's another parameter we
can play with I guess.
Cheers,
Pierre

2023-06-09 14:44:39

- reply

📅 Original date posted:2015-09-24
📝 Original message:
Hi Mats,
I am not sure I understand what you meant, so forgive me if my answer
is a bit off topic.
Let's consider A->B->C->D->E.
The way lightning works is that A does *not* pay B, instead it locks
the corresponding funds in a contract that can end up two ways :
1) B provides a secret R which means E got the funds, and the contract
is fulfilled.
2) a timeout occurs in which case the contract is voided. So there is
no refund because the payment never actually took place.
But what you might have meant is that you are aware how this works,
but you still want a way for A to cancel the contract before the
timeout, in case A and E cooperate and C is unresponsive.
I would say this is a bit contradictory because when A signed the
initial contract, it basically acknowledged the fact that it is
willing to take the risk to have its funds locked for at most $timeout
if things go bad, right ? This is the essence of lightning after all.
That been said, I see two ways for A to reduce the timeout :
- either find a shorter path (maybe even A->E)
- or convince B/C/D to use small timeouts, maybe just a few blocks
between each node. That would reduce A's timeout to a few hours, and I
don't see why that wouldn't work. This might be the real answer to
your problem, but I am certainly missing something!
Now that I think of it, I actually don't know why the default timeout
is 1 day on the original lightning presentation, that seems really
high.
Cheers,
Pierre