Hello ZmnSCPxj,
Thank you for your comments, we are glad for your interest in our work.
Below some answers to your comments.
Concerning the information that intermediary nodes can gather from counters:
We are working under the assumption of a large highly connected network (with
Good morning The Authors,
> Hello ZmnSCPxj,
> Thank you for your comments, we are glad for your interest in our work.
> Below some answers to your comments.
> Concerning the information that intermediary nodes can gather from
> counters: We are working under the assumption of a large
> One of the stated goals of implementing PoDLEs was to be "compatible with
> JoinMarket", but I believe this compatibility goal only extends as far as the
> H2 construction (and not the proof), so we're ok there with this tweak.
Good point about H2 being cross-compatible, but I would not tie
Good morning again The Authors,
> > Concerning the information that intermediary nodes can gather from
> > counters: We are working under the assumption of a large highly connected
> > network (with thousands of nodes and node connection larger than 10, or
> > nodes connected to highly
> Probably so that address reuse is not dinged, i.e. I have two UTXOs with
the same address and want to make two different channels with different
peers.
Having 2 utxos locked to the same pubkey will map to a single H2 value
though, which is what is used to flag utxo reuse. With a PoDLE you're
ZmnSCPxj via Lightning-dev writes:
> Good morning niftynei,
>
>
>> Rusty had some suggestions about how to improve the protocol messages for
>> this, namely adding a serial_id to the inputs and outputs, which can then be
>> reused for deletions.
>>
>> The serial id can then also be used as the
Bastien TEINTURIER writes:
> Hi Rusty,
>
> Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
... Now -rc2. I actually had a RL use for lightning (OMG!), and sure
enough found a bug.
> I've been thinking more about improving my scheme to not require any sender
> change, but I
Good morning Rusty, niftynei, and list,
> > > - Serial ids should be chosen at random
> > >
> > > - For multiparty constructions, the initiator MUST flip the bottom bit
> > > of any received inputs before relaying them to a peer.
> > >
> > > - Collisions of serial ids between peers is a
Good morning waxwing,
>
> https://github.com/privacypass/challenge-bypass-extension/blob/master/docs/PROTOCOL.md
>
> While it's very different from our use-case (harder because not
> client-server),
Am still going through the document, but wanted to react to "not client-server"
thing.
Good morning niftynei, waxwing, and list,
> > Probably so that address reuse is not dinged, i.e. I have two UTXOs with
> > the same address and want to make two different channels with different
> > peers.
>
> Having 2 utxos locked to the same pubkey will map to a single H2 value
> though,
10 matches
Mail list logo
