<unnamed>

Public Key

npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn

Profile Code

nprofile1qqs89n2qxvhv0qkapflk8t9s8caklkh6dkgm6xmpyhxckugh5xacq4cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsa73k7e

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-09-12 10:59:58 CEST

- reply

📅 Original date posted:2023-09-08
🗒️ Summary of this message: A proposal suggests using runes managed by a hardware wallet to authenticate RPC calls, preventing compromised clients from making unauthorized calls.
📝 Original message:
Very interesting proposal, though as Will points out we could implement the
same using runes: have the rune be managed by the hardware wallet, and
commit the rune used to authenticate the RPC call commit to the call's
payload. That way a potentially compromised client cannot authenticate
arbitrary calls, since the hardware wallet is required to associate a rune
with it, giving it a chance for review.
This is similar to how authentication of RPC calls works in greenlight,
where the node host is not trusted, and we need to pass the authenticated
commands forward to the signer for verification before processing any
signature request from the node. We chose to authenticate the payload
rather than the transport (which is what partonnere does) because it
removes the need for a direct connection, and adds flexibility to how we
can deliver the commands. Functionally they are very similar however.
Cheers,
Christian
On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Hi William,
>
> > What is wrong with runes/macaroons for validating and authenticating
> > commands?
>
> Runes/macaroons don't provide any protection if the machine you are
> issuing the RPCs from is compromised. The attacker can change the
> parameters of your RPC call and your lightning node will still gladly
> execute it.
>
> > I can't imagine validating every RPC request with a hardware
> > device and trusted display, unless you have some specific use case in
> > mind.
>
> I think that this is because you have the wrong idea of which RPCs
> this is supposed to protect. This is useful for the RPCs that actually
> involve paying something (channel open, channel close, pay invoice).
> This isn't useful for "read" RPCs (listing channels).
>
> Making an on-chain operation or paying an invoice is something that is
> infrequent enough for the vast majority of nodes that it makes sense
> to validate it manually. Also, this is fully configurable: you can
> choose which RPCs you want to protect that way and which RPCs you want
> to keep open.
>
> Thanks,
> Bastien
>
> Le mer. 6 sept. 2023 à 17:42, William Casarin <jb55 at jb55.com> a écrit :
> >
> > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote:
> > >Hey Zman,
> > >
> > >I saw the announcement about the commando plugin, and it was actually
> > >one of the reasons I wanted to write up what I had in mind, because
> > >while commando also uses a lightning connection to send commands to a
> > >lightning node, it was missing what in my opinion is the most important
> > >part: having all of Bolt 8 handled by the HSM and validating commands
> > >using a trusted display.
> >
> > What is wrong with runes/macaroons for validating and authenticating
> > commands? I can't imagine validating every RPC request with a hardware
> > device and trusted display, unless you have some specific use case in
> > mind.
> >
> > Will
> _______________________________________________
> 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/20230908/57a116fe/attachment-0001.html>

2023-06-19 19:42:22 CEST

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Reputation systems in Lightning Network are susceptible to sudden behavioral changes and whitewashing attacks, making them less useful. Local-only reputation systems may work for large routing nodes, but edges are more vulnerable.
📝 Original message:
Hi Antoine,
this is an intrinsic issue with reputation systems, and the main
reason I'm sceptical w.r.t. their usefulness in lightning.
Fundamentally any reputation system bases their expectations for the
future on experiences they made in the past, and they are thus always
susceptible to sudden behavioral changes (going rogue from a prior
clean record) and whitewashing attacks (switching identity, abusing
any builtin bootstrapping method for new users to gain a good or
neutral reputation before turning rogue repeatedly).
This gets compounded as soon as we start gossiping about reputations,
since now our decisions are no longer based just on information we can
witness ourselves, or at least verify its correctness, and as such an
attacker can most likely "earn" a positive reputation in some other
part of the world, and then turn around and attack the nodes that
trusted the reputation shared from those other parts.
I'd be very interested in how many repeat interactions nodes get from
individual senders, since that also tells us how much use we can get
out of local-only reputation based systems, and I wouldn't be
surprised if, for large routing nodes, we have sufficient data for
them to make an informed decision, while the edges may be more
vulnerable, but they'd also be used by way fewer senders, and the
impact of an attack would also be proportionally smaller.
Cheers,
Christian
On Mon, May 8, 2023 at 10:26 PM Antoine Riard <antoine.riard at gmail.com> wrote:
>
> Hi *,
>
> > Our suggestion is to start simple with a binary endorsement field. As
> > we learn more, we will be better equipped to understand whether a
> > more expressive value is required.
>
> I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.
>
> I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.
>
> Opened an issue on the repository to converge on a threat model:
> https://github.com/ClaraShk/LNJamming/pull/13
>
> I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.
>
> Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.
>
> Best,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>
> Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a écrit :
>>
>> Hi list,
>>
>> Some updates on channel jamming!
>>
>> # Next Call
>> - Monday 01 May @ 15:00 UTC
>> - https://meet.jit.si/UnjammingLN
>> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
>>
>> # Data Gathering
>> During these weekly calls, we've come to agreement that we would like
>> to gather data about the use of HTLC endorsement and local reputation
>> tracking for jamming mitigation. A reminder of the full scheme is
>> included at the end of this email, and covered more verbosely in [1].
>>
>> We have a few goals in mind:
>> - Observe the effect of endorsement in the steady state with
>> logging-only implementation.
>> - Gather real-world data for use in future simulation work.
>> - Experiment with different algorithms for tracking local reputation.
>>
>> The minimal changes required to add HTLC endorsement are outlined in [2].
>> Our suggestion is to start simple with a binary endorsement field. As
>> we learn more, we will be better equipped to understand whether a
>> more expressive value is required.
>>
>> With this infrastructure in place, we can start to experiment with
>> various local reputation schemes and data gathering, possibly even
>> externally to LN implementations in projects like circuitbreaker [3].
>> We'd be interested to hear whether there's any appetite to deploy using
>> an experimental TLV value?
>>
>> # Reputation Scheme
>> - Each node locally tracks the reputation of its direct neighbors.
>> - Each node allocates, per its risk tolerance:
>> - A number of slots reserved for endorsed HTLCs from high reputation
>> peers.
>> - A portion of liquidity reserved for endorsed HTLCs from high
>> reputation peers.
>> - Forwarding of HTLCs:
>> - If a HTLC is endorsed by a high reputation peer, it is forwarded
>> as usual with endorsed = 1.
>> - Otherwise, it is forwarded with endorsed = 0 if there are slots and
>> liquidity available for unknown HTLCs.
>>
>> Endorsement and reputation are proposed as the first step in a two part
>> scheme for mitigating channel jamming:
>> - Reputation for slow jams which are easily detected as misbehavior.
>> - Unconditional fees for quick jams that are difficult to detect, as
>> they can always fall under a target threshold.
>>
>> Looking forward to discussing further in the upcoming call!
>>
>> Best,
>> Carla and Clara
>>
>> [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
>> [2] https://github.com/lightning/bolts/pull/1071
>> [3] https://github.com/lightningequipment/circuitbreaker
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:13:18 CEST

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Reputation systems in Lightning are susceptible to sudden behavioral changes and whitewashing attacks, making their usefulness questionable. Local-only reputation systems may work for large routing nodes, but edges may be more vulnerable.
📝 Original message:
Hi Antoine,
this is an intrinsic issue with reputation systems, and the main
reason I'm sceptical w.r.t. their usefulness in lightning.
Fundamentally any reputation system bases their expectations for the
future on experiences they made in the past, and they are thus always
susceptible to sudden behavioral changes (going rogue from a prior
clean record) and whitewashing attacks (switching identity, abusing
any builtin bootstrapping method for new users to gain a good or
neutral reputation before turning rogue repeatedly).
This gets compounded as soon as we start gossiping about reputations,
since now our decisions are no longer based just on information we can
witness ourselves, or at least verify its correctness, and as such an
attacker can most likely "earn" a positive reputation in some other
part of the world, and then turn around and attack the nodes that
trusted the reputation shared from those other parts.
I'd be very interested in how many repeat interactions nodes get from
individual senders, since that also tells us how much use we can get
out of local-only reputation based systems, and I wouldn't be
surprised if, for large routing nodes, we have sufficient data for
them to make an informed decision, while the edges may be more
vulnerable, but they'd also be used by way fewer senders, and the
impact of an attack would also be proportionally smaller.
Cheers,
Christian
On Mon, May 8, 2023 at 10:26 PM Antoine Riard <antoine.riard at gmail.com> wrote:
>
> Hi *,
>
> > Our suggestion is to start simple with a binary endorsement field. As
> > we learn more, we will be better equipped to understand whether a
> > more expressive value is required.
>
> I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.
>
> I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.
>
> Opened an issue on the repository to converge on a threat model:
> https://github.com/ClaraShk/LNJamming/pull/13
>
> I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.
>
> Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.
>
> Best,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>
> Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a écrit :
>>
>> Hi list,
>>
>> Some updates on channel jamming!
>>
>> # Next Call
>> - Monday 01 May @ 15:00 UTC
>> - https://meet.jit.si/UnjammingLN
>> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
>>
>> # Data Gathering
>> During these weekly calls, we've come to agreement that we would like
>> to gather data about the use of HTLC endorsement and local reputation
>> tracking for jamming mitigation. A reminder of the full scheme is
>> included at the end of this email, and covered more verbosely in [1].
>>
>> We have a few goals in mind:
>> - Observe the effect of endorsement in the steady state with
>> logging-only implementation.
>> - Gather real-world data for use in future simulation work.
>> - Experiment with different algorithms for tracking local reputation.
>>
>> The minimal changes required to add HTLC endorsement are outlined in [2].
>> Our suggestion is to start simple with a binary endorsement field. As
>> we learn more, we will be better equipped to understand whether a
>> more expressive value is required.
>>
>> With this infrastructure in place, we can start to experiment with
>> various local reputation schemes and data gathering, possibly even
>> externally to LN implementations in projects like circuitbreaker [3].
>> We'd be interested to hear whether there's any appetite to deploy using
>> an experimental TLV value?
>>
>> # Reputation Scheme
>> - Each node locally tracks the reputation of its direct neighbors.
>> - Each node allocates, per its risk tolerance:
>> - A number of slots reserved for endorsed HTLCs from high reputation
>> peers.
>> - A portion of liquidity reserved for endorsed HTLCs from high
>> reputation peers.
>> - Forwarding of HTLCs:
>> - If a HTLC is endorsed by a high reputation peer, it is forwarded
>> as usual with endorsed = 1.
>> - Otherwise, it is forwarded with endorsed = 0 if there are slots and
>> liquidity available for unknown HTLCs.
>>
>> Endorsement and reputation are proposed as the first step in a two part
>> scheme for mitigating channel jamming:
>> - Reputation for slow jams which are easily detected as misbehavior.
>> - Unconditional fees for quick jams that are difficult to detect, as
>> they can always fall under a target threshold.
>>
>> Looking forward to discussing further in the upcoming call!
>>
>> Best,
>> Carla and Clara
>>
>> [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
>> [2] https://github.com/lightning/bolts/pull/1071
>> [3] https://github.com/lightningequipment/circuitbreaker
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:12:39 CEST

- reply

📅 Original date posted:2023-02-13
🗒️ Summary of this message: Reputation systems are difficult to get right and easy to exploit. There are three types: first-hand experience, inferred experience, and hearsay. Repeat interactions are rare, and local knowledge gets out of date. Penalizing nodes is not the goal; optimizing the payment process is.
📝 Original message:
Hi Matt,
Hi Joost,
let me chime in here, since we seem to be slowly reinventing all the
research on reputation systems that is already out there. First of all
let me say that I am personally not a fan of reputation systems in
general, just to get my own biases out of the way, now on to the why :-)
Reputation systems are great when they work, but they are horrible to
get right, and certainly the patchworky approach we see being proposed
today will end up with a system that is easy to exploit and hard to
understand. The last time I encountered this kind of scenario was during
my work on Bittorrent, where the often theorized tit-for-tat approach
failed spectacularly, and leeching (i.e., not contributing to other
people's download) is rampant even today (BT only works because a few
don't care about their upload bandwidth).
First of all let's see what types of reputation system exist (and yes,
this is my very informal categorization):
- First hand experience
- Inferred experience
- Hearsay
The first two are likely the setup we all are comfortable with: we ourselves
experienced something, and make some decisions based on that
experience. This is probably what we're all doing at the moment: we
attempt a payment, it fails, we back off for a bit from that channel
being used again. This requires either being able to witness the issue
directly (local peer) or infer from unforgeable error messages (the
failing node returns an error, and it can't point the finger at someone
else). Notice that this also includes some transitive constructions,
such as the backpressure mechanism we were discussing for ariard's
credentials proposal.
Ideally we'd only rely on the first two to make decisions, but here's
exactly the issue we ran into with Bittorrent: repeat interactions are
too rare. In addition, our local knowledge gets out of date the longer
we wait, and a previously failing channel may now be good again, and
vice-versa. For us to have sufficient knowledge to make good decisions
we need to repeatedly interact with the same nodes in the network, and
since end-users will be very unlikely to do that, we might end up in a
situation were we instinctively fall back to the hearsay method, either
by sharing our local reputation with peers and then somehow combine that
with our own view. To the best of my knowledge such a system has never
been built successfully, and all attempts have ended in a system that
was either way too simple or is gameable by rational players.
I also object to the wording of penalizing nodes that haven't been as
reliable in the past. It's not penalizing them if, based on our local
information, we decide to route over other nodes for a bit. Our goal is
optimize the payment process, chosing the best possible routes, not
making a judgement on the honesty or reliability of a node. When talking
about penalizing we see node operators starting to play stupid games to
avoid that perceived penalty, when in reality they should do their best
to route as many payments successfully as possible (the negative fees
for direct peers "exhausting" a balanced flow is one such example of
premature optimization in that direction imho).
So I guess what I'm saying is that we need to get away from this
patchwork mode of building the protocol, and have a much clearer model
for a) what we want to achieve, b) how much untrustworthy information we
want to rely on, and c) how we protect (and possibly prove security)
against manipulation by rational players. For the last question we at
least have one nice feature (for now), namely that the identities are
semi-permanent, and so white-washing attacks at least are not free.
And after all this rambling, let's get back to the topic at hand: I
don't think enshrining the differences of availability in the protocol,
thus creating two classes of nodes, is a desirable
feature. Communicating up-front that I intend to be reliable does
nothing, and penalizing after the fact isn't worth much due to the
repeat interactions issue. It'd be even worse if now we had to rely on a
third party to aggregate and track the reliability, in order to get
enough repeat interactions to build a good model of their liquidity,
since we're now back in the hearsay world, and the third party can feed
us wrong information to maximize their profits.
Regards,
Christian
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Hi Joost,
>
> I’m not sure I agree that lightning is “capital efficient” (or even close to it), but more generally I don’t see why this needs a signal.
>
> If nodes start aggressively preferring routes through nodes that reliably route payments (which I believe lnd already does, in effect, to some large extent), they should do so by measurement, not signaling.
>
> In practice, many channels on the network are “high availability” today, but only in one direction (I.e. they aren’t regularly spliced/rebalanced and are regularly unbalanced). A node strongly preferring a high payment success rate *should* prefer such a channel, but in your scheme would not.
>
> This ignores the myriad of “at what threshold do you signal HA” issues, which likely make such a signal DOA, anyway.
>
> Finally, I’m very dismayed at this direction in thinking on how ln should work - nodes should be measuring the network and routing over paths that it thinks are reliable for what it wants, *robustly over an unreliable network*. We should absolutely not be expecting the lightning network to be built out of high reliability nodes, that creates strong centralization pressure. To truly meet a “high availability” threshold, realistically, you’d need to be able to JIT 0conf splice-in, which would drive lightning to actually being a credit network.
>
> With reasonable volume, lightning today is very reliable and relatively fast, with few retries required. I don’t think we need to change anything to fix it. :)
>
> Matt
>
>> On Feb 13, 2023, at 06:46, Joost Jager <joost.jager at gmail.com> wrote:
>>
>>
>> Hi,
>>
>> For a long time I've held the expectation that eventually payers on the lightning network will become very strict about node performance. That they will require a routing node to operate flawlessly or else apply a hefty penalty such as completely avoiding the node for an extended period of time - multiple weeks. The consequence of this is that routing nodes would need to manage their liquidity meticulously because every failure potentially has a large impact on future routing revenue.
>>
>> I think movement in this direction is important to guarantee competitiveness with centralised payment systems and their (at least theoretical) ability to process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one that works doesn't help with this.
>>
>> A common argument against strict penalisation is that it would lead to less efficient use of capital. Routing nodes would need to maintain pools of liquidity to guarantee successes all the time. My opinion on this is that lightning is already enormously capital efficient at scale and that it is worth sacrificing a slight part of that efficiency to also achieve the lowest possible latency.
>>
>> This brings me to the actual subject of this post. Assuming strict penalisation is good, it may still not be ideal to flip the switch from one day to the other. Routing nodes may not offer the required level of service yet, causing senders to end up with no nodes to choose from.
>>
>> One option is to gradually increase the strength of the penalties, so that routing nodes are given time to adapt to the new standards. This does require everyone to move along and leaves no space for cheap routing nodes with less leeway in terms of liquidity.
>>
>> Therefore I am proposing another way to go about it: extend the `channel_update` field `channel_flags` with a new bit that the sender can use to signal `highly_available`.
>>
>> It's then up to payers to decide how to interpret this flag. One way could be to prefer `highly_available` channels during pathfinding. But if the routing node then returns a failure, a much stronger than normal penalty will be applied. For routing nodes this creates an opportunity to attract more traffic by marking some channels as `highly_available`, but it also comes with the responsibility to deliver.
>>
>> Without shadow channels, it is impossible to guarantee liquidity up to the channel capacity. It might make sense for senders to only assume high availability for amounts up to `htlc_maximum_msat`.
>>
>> A variation on this scheme that requires no extension of `channel_update` is to signal availability implicitly through routing fees. So the more expensive a channel is, the stronger the penalty that is applied on failure will be. It seems less ideal though, because it could disincentivize cheap but reliable channels on high traffic links.
>>
>> The effort required to implement some form of a `highly_available` flag seem limited and it may help to get payment success rates up. Interested to hear your thoughts.
>>
>> Joost
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:08:04 CEST

- reply

📅 Original date posted:2023-02-13
📝 Original message:
Hi Matt,
Hi Joost,
let me chime in here, since we seem to be slowly reinventing all the
research on reputation systems that is already out there. First of all
let me say that I am personally not a fan of reputation systems in
general, just to get my own biases out of the way, now on to the why :-)
Reputation systems are great when they work, but they are horrible to
get right, and certainly the patchworky approach we see being proposed
today will end up with a system that is easy to exploit and hard to
understand. The last time I encountered this kind of scenario was during
my work on Bittorrent, where the often theorized tit-for-tat approach
failed spectacularly, and leeching (i.e., not contributing to other
people's download) is rampant even today (BT only works because a few
don't care about their upload bandwidth).
First of all let's see what types of reputation system exist (and yes,
this is my very informal categorization):
- First hand experience
- Inferred experience
- Hearsay
The first two are likely the setup we all are comfortable with: we ourselves
experienced something, and make some decisions based on that
experience. This is probably what we're all doing at the moment: we
attempt a payment, it fails, we back off for a bit from that channel
being used again. This requires either being able to witness the issue
directly (local peer) or infer from unforgeable error messages (the
failing node returns an error, and it can't point the finger at someone
else). Notice that this also includes some transitive constructions,
such as the backpressure mechanism we were discussing for ariard's
credentials proposal.
Ideally we'd only rely on the first two to make decisions, but here's
exactly the issue we ran into with Bittorrent: repeat interactions are
too rare. In addition, our local knowledge gets out of date the longer
we wait, and a previously failing channel may now be good again, and
vice-versa. For us to have sufficient knowledge to make good decisions
we need to repeatedly interact with the same nodes in the network, and
since end-users will be very unlikely to do that, we might end up in a
situation were we instinctively fall back to the hearsay method, either
by sharing our local reputation with peers and then somehow combine that
with our own view. To the best of my knowledge such a system has never
been built successfully, and all attempts have ended in a system that
was either way too simple or is gameable by rational players.
I also object to the wording of penalizing nodes that haven't been as
reliable in the past. It's not penalizing them if, based on our local
information, we decide to route over other nodes for a bit. Our goal is
optimize the payment process, chosing the best possible routes, not
making a judgement on the honesty or reliability of a node. When talking
about penalizing we see node operators starting to play stupid games to
avoid that perceived penalty, when in reality they should do their best
to route as many payments successfully as possible (the negative fees
for direct peers "exhausting" a balanced flow is one such example of
premature optimization in that direction imho).
So I guess what I'm saying is that we need to get away from this
patchwork mode of building the protocol, and have a much clearer model
for a) what we want to achieve, b) how much untrustworthy information we
want to rely on, and c) how we protect (and possibly prove security)
against manipulation by rational players. For the last question we at
least have one nice feature (for now), namely that the identities are
semi-permanent, and so white-washing attacks at least are not free.
And after all this rambling, let's get back to the topic at hand: I
don't think enshrining the differences of availability in the protocol,
thus creating two classes of nodes, is a desirable
feature. Communicating up-front that I intend to be reliable does
nothing, and penalizing after the fact isn't worth much due to the
repeat interactions issue. It'd be even worse if now we had to rely on a
third party to aggregate and track the reliability, in order to get
enough repeat interactions to build a good model of their liquidity,
since we're now back in the hearsay world, and the third party can feed
us wrong information to maximize their profits.
Regards,
Christian
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Hi Joost,
>
> I’m not sure I agree that lightning is “capital efficient” (or even close to it), but more generally I don’t see why this needs a signal.
>
> If nodes start aggressively preferring routes through nodes that reliably route payments (which I believe lnd already does, in effect, to some large extent), they should do so by measurement, not signaling.
>
> In practice, many channels on the network are “high availability” today, but only in one direction (I.e. they aren’t regularly spliced/rebalanced and are regularly unbalanced). A node strongly preferring a high payment success rate *should* prefer such a channel, but in your scheme would not.
>
> This ignores the myriad of “at what threshold do you signal HA” issues, which likely make such a signal DOA, anyway.
>
> Finally, I’m very dismayed at this direction in thinking on how ln should work - nodes should be measuring the network and routing over paths that it thinks are reliable for what it wants, *robustly over an unreliable network*. We should absolutely not be expecting the lightning network to be built out of high reliability nodes, that creates strong centralization pressure. To truly meet a “high availability” threshold, realistically, you’d need to be able to JIT 0conf splice-in, which would drive lightning to actually being a credit network.
>
> With reasonable volume, lightning today is very reliable and relatively fast, with few retries required. I don’t think we need to change anything to fix it. :)
>
> Matt
>
>> On Feb 13, 2023, at 06:46, Joost Jager <joost.jager at gmail.com> wrote:
>>
>>
>> Hi,
>>
>> For a long time I've held the expectation that eventually payers on the lightning network will become very strict about node performance. That they will require a routing node to operate flawlessly or else apply a hefty penalty such as completely avoiding the node for an extended period of time - multiple weeks. The consequence of this is that routing nodes would need to manage their liquidity meticulously because every failure potentially has a large impact on future routing revenue.
>>
>> I think movement in this direction is important to guarantee competitiveness with centralised payment systems and their (at least theoretical) ability to process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one that works doesn't help with this.
>>
>> A common argument against strict penalisation is that it would lead to less efficient use of capital. Routing nodes would need to maintain pools of liquidity to guarantee successes all the time. My opinion on this is that lightning is already enormously capital efficient at scale and that it is worth sacrificing a slight part of that efficiency to also achieve the lowest possible latency.
>>
>> This brings me to the actual subject of this post. Assuming strict penalisation is good, it may still not be ideal to flip the switch from one day to the other. Routing nodes may not offer the required level of service yet, causing senders to end up with no nodes to choose from.
>>
>> One option is to gradually increase the strength of the penalties, so that routing nodes are given time to adapt to the new standards. This does require everyone to move along and leaves no space for cheap routing nodes with less leeway in terms of liquidity.
>>
>> Therefore I am proposing another way to go about it: extend the `channel_update` field `channel_flags` with a new bit that the sender can use to signal `highly_available`.
>>
>> It's then up to payers to decide how to interpret this flag. One way could be to prefer `highly_available` channels during pathfinding. But if the routing node then returns a failure, a much stronger than normal penalty will be applied. For routing nodes this creates an opportunity to attract more traffic by marking some channels as `highly_available`, but it also comes with the responsibility to deliver.
>>
>> Without shadow channels, it is impossible to guarantee liquidity up to the channel capacity. It might make sense for senders to only assume high availability for amounts up to `htlc_maximum_msat`.
>>
>> A variation on this scheme that requires no extension of `channel_update` is to signal availability implicitly through routing fees. So the more expensive a channel is, the stronger the penalty that is applied on failure will be. It seems less ideal though, because it could disincentivize cheap but reliable channels on high traffic links.
>>
>> The effort required to implement some form of a `highly_available` flag seem limited and it may help to get payment success rates up. Interested to hear your thoughts.
>>
>> Joost
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:05:03 CEST

- reply

📅 Original date posted:2022-01-19
📝 Original message:
Hi Will,
> I noticed you are doing RPC stuff... I'm looking to do RPC over
> lightning itself. I started a C library called lnsocket[1], scrounged
> from clightning parts, so that I can send messages from iOS to control
> my lightning node.
Sounds interesting, and similar to commando's goals. Rusty also has a
summer of bitcoin project attempting to expose a websocket directly to
browsers in order to provide another way to communicate with your node,
and of course there's commando.
> I've got to the point with lnsocket where I can send TLVs to my node,
> and now I'm starting to think about what format the RPC commands should
> be.
>
> I noticed the commando c-lightning plugin just uses the JSON-RPC
> payload, but perhaps something more compact and rpc-friendly like grpc
> would be better... which is why this cln-grpc PR peaked my curiosity.
Yep, JSON-RPC is rather bad with binary data, and doesn't have any
concept of streaming. I personally like grpc because it ticks a lot of
boxes: secure transport over TLS, mutual authentication via mTLS,
possibility to add metadata to calls (technically prohibited by the
JSON-RPC spec) which can help us use macaroons/runes in future,
streaming support and compact binary format.
Having an IDL to describe the interface is also rather nice, even though
for cln-grpc we actually generate that from the JSON-RPC schemas, so
it's a bit less expressive than .proto files.
> I think the end goal of an RPC bolt would be super powerful, so that
> lnsocket could talk to any lightning node, but that could be further
> down the line. Choosing the right data format seemed like an important
> step in that direction. Would love to hear your thoughts on this!
I agree. Exchanging the transport layer underneath grpc doesn't change
semantics, but does unlock a number of potential use-cases. I think
either the JSON-RPC or grpc can serve as a basis for a common RPC
definition that can have any number of bindings, since we generate
conversion code to/from JSON-RPC and grpc we can transparently map them
back and forth.
> I've cc'd clightning/lightning-dev as well to see if anyone else is
> working on this or thinking about this stuff right now.
Definitely open to suggestions, comments and criticism: the cln-grpc [1]
crate is rather new, and will see a number of rebases and fixups, but
should be reviewable as is. The cln-plugin [2] crate is a bit less
well-fleshed-out, but has the core functionality needed for
cln-grpc-plugin which was the goal of this first exploration. The
cln-rpc [4] crate is also missing many RPC commands, but that's just
grunt work that I plan to tackle separately :-)
Cheers,
Christian
[1] https://github.com/ElementsProject/lightning/pull/5011
[2] https://github.com/ElementsProject/lightning/pull/5012
[3] https://github.com/ElementsProject/lightning/pull/5013
[4] https://github.com/ElementsProject/lightning/pull/5010

2023-06-09 15:04:51 CEST

- reply

📅 Original date posted:2021-12-17
📝 Original message:
I was looking into the docs [1] and stumbled over `createinvoice` which
does almost what you need. However it requires the preimage, and stores the
invoice in the database which you don't want.
However if you have access to the `hsm_secret` you could sign in the plugin
itself, completely sidestepping `lightningd`. Once you have that it should
be a couple of days work to get a PoC plugin for the coordination and
testing. From there it depends on how much polish you want to apply and
what other systems you want to embed it into.
Each recipient will have to run the plugin otherwise they'd not understand
how to handle the payment, and creating an invoice requires a bit more work
(each payee needs to coordinate to be part of the Rendez-vous), but from
the senders point of view it's all seamless.
As for whether this is better suited for the protocol itself: could be,
probably not though. We let everybody experiment and then formalize and
standardize the best ideas from the community, so it may make its way into
the spec, but would need to be implemented, tested and popular enough to
warrant everybody having to implement yet another feature. In this case
it's more for a bLiP, which are less formal and better match the fact that
only a small part of the network needs to implement it (only payees need to
coordinate and forward, senders and everybody else doesn't care).
Cheers,
Christian
[1] https://lightning.readthedocs.io/lightning-createinvoice.7.html
On Fri, 17 Dec 2021, 11:22 Ronan McGovern, <Ronan at trelis.com> wrote:
> Hi ZmnSCPxj,
>
> So, are you saying there needs to be a new command "signfakeinvoice" at
> the protocol level?
>
> If that was there, how much work/hours would it be to build the poor man's
> rendez-vous at the application level?
>
> If the above were to be implemented, when the payer pays the invoice, it's
> then automatically split and sent to two (or more) recipients?
>
> Lastly, would it make more sense to have split payments at the protocol
> level?
>
> Thanks, Ronan
>
> On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning William,
>>
>>
>> > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
>> > it be, could it be done with a clightning plugin perhaps?
>>
>> Probably not *yet*; it needs each intermediate payee (i.e. the one that
>> is not the last one) to sign an invoice for which it does not know the
>> preimage.
>> Maybe call such a command `signfakeinvoice`.
>>
>> However, if a command to do the above is implemented (it would have to
>> generate and sign the invoice, but not insert it into the database at all),
>> then intermediate payees can use `htlc_accepted` hook for the "rendez-vous".
>>
>> So to generate the invoice:
>>
>> * Arrange the payees in some agreed fixed order.
>> * Last payee generates a normal invoice.
>> * From last payee to second, each one:
>> * Passes its invoice to the previous payee.
>> * The previous payee then creates its own signed invoice with
>> `signfakeinvoice` to itself, adding its payout plus a fee budget, as well
>> as adding its own delay budget.
>> * The previous payee plugin stores the next-payee invoice and the
>> details of its own invoice to db, such as by `datastore` command.
>> * The first payee sends the sender the invoice.
>>
>> On payment:
>>
>> * The sender sends the payment to the first hop.
>> * From first payee to second-to-last:
>> * Triggers `htlc_accepted` hook, and plugin checks if the incoming
>> payment has a hash that is in this scheme stored in the database.
>> * The plugin gathers `htlc_accepted` hook invocations until they sum up
>> to the expected amount (this handles multipath between payees).
>> * The plugin marks that it has gathered all `htlc_accepted` hooks for
>> that hash in durable storage a.k.a. `datastore` (this handles a race
>> condition where the plugin is able to respond to some `htlc_accepted`
>> hooks, but the node is restarted before all of them were able to be
>> recorded by C-Lightning in its own database --- this makes the plugin skip
>> the "gathering" step above, once it has already gathered them all before).
>> * The plugin checks if there is already an outgoing payment for that
>> hash (this handles the case where our node gets restarted in the meantime
>> --- C-Lightning will reissue `htlc_accepted` on startup)
>> * If the outgoing payment exists and is pending, wait for it to
>> resolve to either success or failure.
>> * If the outgoing payment exists and succeeded, resolve all the
>> gathered `htlc_accepted` hooks.
>> * If the outgoing payment exists and failed, fail all the gathered
>> `htlc_accepted` hooks.
>> * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay`
>> based on its fee budget and delay budget.
>> When the `pay` succeeds or fails, propagate it to the gathered
>> `htlc_accepted` hooks.
>> * The last payee just receives a normal payment using the normal
>> invoice-receive scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/ad84b53b/attachment-0001.html>

2023-06-09 15:04:50 CEST

- reply

📅 Original date posted:2021-12-16
📝 Original message:
This is quite a common request, and we've used a solution I like to call
the "Poor man's rendez-vous". It basically routes a payment through all
the parties that are to be paid, with the last one accepting the payment
for all participants.
The payment is atomic, once the circuit is set up no participant can
cheat the others and it's seamless from the payer's perspective.
Let's say user `A` wants to pay `B` and `C` atomically. `B` gets 10ksat
and `C` gets 90ksat out of a total of 100ksat:
1) `C` creates an invoice with payment hash `H` for 90ksat and sends it
to `B`
2) `B` creates an invoice with payment hash `H` (same as the first
invoice, but `B` doesn't know the preimage) for 100ksat (maybe plus
a tiny bit for routing fees between `B` and `C`).
3) `A` receives an invoice which appears to be from `B` for the
expected total of 100ksat.
4) `A` proceeds to pay the invoice to `B` like normal
5) `B` receives the incoming payment, but doesn't have the preimage for
`H`, so they must forward to `C` if they want to receive their
share. `B` then proceeds to pay the 90ksat invoice from `C`, which
reveals the preimage to them, and they can turn around and claim
the incoming `100ksat` (covering both `B` and `C` share)
It's a poor man's version because it requires creating two invoices and
`B` sees two payments (100ksat incoming, 90ksat outgoing), but the
overall outcome is the desired one: either both parties get paid or
noone gets paid. This can trivially be extended to any number of parties
(with reduced success probability), and will remain atomic. It also
doesn't require any changes on the sender side, and only minimal setup
between the payees. The crux here is that we somehow need to ensure `H`
is always the same along the entire chain of payments, but with a good
coordination protocol that should be feasible.
Regards,
Christian
Ronan McGovern <Ronan at trelis.com> writes:
> Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple
> payment links to accept Lightning).
>
> I'm wondering if there is a way to create an invoice that splits the
> payment to two lightning addresses?
>
> If not, what would be required to develop this?
> * A protocol change?
> * Could it be built with the current protocol (I see an app on LN Bits to
> split but it doesn't seem to work).
>
> Many thanks, Ronan
>
> Ronan McGovern
> www.Trelis.com
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:03:10 CEST

- reply

📅 Original date posted:2021-07-20
📝 Original message:
We'd likely be using an HMAC to ensure the integrity of the data returned
by peers, so we'd only have to guard against them returning an older
version, which in eltoo. Furthermore by retrieving the blobs on reconnect
regardless of whether we need them or not we can verify that peers are
behaving correctly, since they shouldn't be able to distinguish whether
we're just checking or actually need the data. In addition we can store the
same data with multiple peers, ensuring that as long as one node is
behaving we're good.
Cheers,
Christian
On Thu, 15 Jul 2021, 12:28 Martin Habovštiak <martin.habovstiak at gmail.com>
wrote:
> What would happen in 2) if the node has data but the peer returned an
> incorrect state?
>
> On Wed, Jul 14, 2021, 20:13 Christian Decker <decker.christian at gmail.com>
> wrote:
>
>> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
>> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
>> impact only funds that are in a PTLC at the time of the loss-of-state.
>>
>> We have a couple of options here, that don't touch the blockchain, and
>> are therefore rather lightweight:
>>
>> 1) Do nothing and keep the incentive to keep up to date backups. It
>> still is a reduction in risk w.r.t. LN-penalty, since this is just an
>> append only log of secrets, and old secrets don't harm you like
>> attempting to close with an old commitment would.
>> 2) Use the peer-storage idea, where we deposit an encrypted bundle with
>> our peers, and which we expect the peers to return. by hiding the fact
>> that we forgot some state, until the data has been exchanged we can
>> ensure that peers always return the latest snapshot of whatever we gave
>> them.
>>
>> The latter is the encrypted-blob idea that Rusty has been proposing for
>> a while now.
>>
>> Cheers,
>> Christian
>>
>> Anthony Towns <aj at erisian.com.au> writes:
>> > Hello world,
>> >
>> > Suppose you have some payments going from Alice to Bob to Carol with
>> > eltoo channels. Bob's lightning node crashes, and he recovers from an
>> > old backup, and Alice and Carol end up dropping newer channel states
>> > onto the blockchain.
>> >
>> > Suppose the timeout for the payments is a few hours away, while the
>> > channels have specified a week long CSV delay to rectify any problems
>> > on-chain.
>> >
>> > Then I think that that means that:
>> >
>> > 1) Carol will reveal the point preimages on-chain via adaptor
>> > signatures, but Bob won't be able to decode those adaptor signatures
>> > because those signatures will need to change for each state
>> >
>> > 2) Even if Bob knows the point preimages, he won't be able to
>> > claim the PTLC payments on-chain, for the same reason: he needs
>> > newer adaptor signatures that he'll have lost with the state update
>> >
>> > 3) For any payments that timeout, Carol doesn't have any particular
>> > incentive to make it easy for Bob to claim the refund, and Bob won't
>> > have the adaptor signatures for the latest state to do so
>> >
>> > 4) But Alice will be able to claim refunds easily. This is working how
>> > it's meant to, at least!
>> >
>> > I think you could fix (3) by giving Carol (who does have all the adaptor
>> > signatures for the latest state) the ability to steal funds that are
>> > meant to have been refunded, provided she gives Bob the option of
>> claiming
>> > them first.
>> >
>> > However fixing (1) and (2) aren't really going against Alice or Carol's
>> > interests, so maybe you can just ask: Carol loses nothing by allowing
>> > Bob to claim funds from Alice; and Alice has already indicated that
>> > knowing P is worth more to her than the PTLC's funds -- otherwise she
>> > wouldn't have forwarded the PTLC to Bob in the first place.
>> >
>> > Likewise, everyone's probably incentivised to negotiate cooperative
>> > closes instead of going on-chain -- better privacy, less fees, and less
>> > delay before the funds can be used elsewhere.
>> >
>> > FWIW, I think a similar flaw exists even in the original eltoo spec --
>> > Alice could simply decline to publish the settlement transaction until
>> > the timeout has been reached, preventing Bob from revealing the HTLC
>> > preimage before Alice can claim the refund.
>> >
>> > So I think that adds up to:
>> >
>> > a) Nodes should share state on reconnection; if you find a node that
>> > doesn't do this, close the channel and put the node on your enemies
>> > list. If you disagree on what the current state is, share your most
>> > recent state, and if the other guy's state is more recent, and all
>> > the signatures verify, update your state to match theirs.
>> >
>> > b) Always negotiate a mutual/cooperative close if possible, to avoid
>> > actually using the eltoo protocol on-chain.
>> >
>> > c) If you want to allow continuing the channel after restoring an old
>> > state from backup, set the channel state index based on the real
>> time,
>> > eg (real_time-start_time)*(max_updates_per_second). That way your
>> > first update after a restore from backup will ensure that any old
>> > states that your channel partner may not have told you about are
>> > invalidated.
>> >
>> > d) Accept that if you lose connectivity to a channel partner, you will
>> > have to pay any PTLCs that were going to them, and won't be able
>> > to claim the PTLCs that were funding them. Perhaps limit the total
>> > value of inbound PTLCs for forwarding that you're willing to accept
>> > at any one itme?
>> >
>> > Also, layered commitments seem like they make channel factories
>> > complicated too. Nobody came up with a way to avoid layered commitments
>> > while I wasn't watching did they?
>> >
>> > Cheers,
>> > aj
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> _______________________________________________
>> 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/20210720/29630c09/attachment.html>

2023-06-09 15:03:09 CEST

- reply

📅 Original date posted:2021-07-14
📝 Original message:
Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
loss-of-state equates to loss-of-funds, in eltoo this is reduced to
impact only funds that are in a PTLC at the time of the loss-of-state.
We have a couple of options here, that don't touch the blockchain, and
are therefore rather lightweight:
1) Do nothing and keep the incentive to keep up to date backups. It
still is a reduction in risk w.r.t. LN-penalty, since this is just an
append only log of secrets, and old secrets don't harm you like
attempting to close with an old commitment would.
2) Use the peer-storage idea, where we deposit an encrypted bundle with
our peers, and which we expect the peers to return. by hiding the fact
that we forgot some state, until the data has been exchanged we can
ensure that peers always return the latest snapshot of whatever we gave
them.
The latter is the encrypted-blob idea that Rusty has been proposing for
a while now.
Cheers,
Christian
Anthony Towns <aj at erisian.com.au> writes:
> Hello world,
>
> Suppose you have some payments going from Alice to Bob to Carol with
> eltoo channels. Bob's lightning node crashes, and he recovers from an
> old backup, and Alice and Carol end up dropping newer channel states
> onto the blockchain.
>
> Suppose the timeout for the payments is a few hours away, while the
> channels have specified a week long CSV delay to rectify any problems
> on-chain.
>
> Then I think that that means that:
>
> 1) Carol will reveal the point preimages on-chain via adaptor
> signatures, but Bob won't be able to decode those adaptor signatures
> because those signatures will need to change for each state
>
> 2) Even if Bob knows the point preimages, he won't be able to
> claim the PTLC payments on-chain, for the same reason: he needs
> newer adaptor signatures that he'll have lost with the state update
>
> 3) For any payments that timeout, Carol doesn't have any particular
> incentive to make it easy for Bob to claim the refund, and Bob won't
> have the adaptor signatures for the latest state to do so
>
> 4) But Alice will be able to claim refunds easily. This is working how
> it's meant to, at least!
>
> I think you could fix (3) by giving Carol (who does have all the adaptor
> signatures for the latest state) the ability to steal funds that are
> meant to have been refunded, provided she gives Bob the option of claiming
> them first.
>
> However fixing (1) and (2) aren't really going against Alice or Carol's
> interests, so maybe you can just ask: Carol loses nothing by allowing
> Bob to claim funds from Alice; and Alice has already indicated that
> knowing P is worth more to her than the PTLC's funds -- otherwise she
> wouldn't have forwarded the PTLC to Bob in the first place.
>
> Likewise, everyone's probably incentivised to negotiate cooperative
> closes instead of going on-chain -- better privacy, less fees, and less
> delay before the funds can be used elsewhere.
>
> FWIW, I think a similar flaw exists even in the original eltoo spec --
> Alice could simply decline to publish the settlement transaction until
> the timeout has been reached, preventing Bob from revealing the HTLC
> preimage before Alice can claim the refund.
>
> So I think that adds up to:
>
> a) Nodes should share state on reconnection; if you find a node that
> doesn't do this, close the channel and put the node on your enemies
> list. If you disagree on what the current state is, share your most
> recent state, and if the other guy's state is more recent, and all
> the signatures verify, update your state to match theirs.
>
> b) Always negotiate a mutual/cooperative close if possible, to avoid
> actually using the eltoo protocol on-chain.
>
> c) If you want to allow continuing the channel after restoring an old
> state from backup, set the channel state index based on the real time,
> eg (real_time-start_time)*(max_updates_per_second). That way your
> first update after a restore from backup will ensure that any old
> states that your channel partner may not have told you about are
> invalidated.
>
> d) Accept that if you lose connectivity to a channel partner, you will
> have to pay any PTLCs that were going to them, and won't be able
> to claim the PTLCs that were funding them. Perhaps limit the total
> value of inbound PTLCs for forwarding that you're willing to accept
> at any one itme?
>
> Also, layered commitments seem like they make channel factories
> complicated too. Nobody came up with a way to avoid layered commitments
> while I wasn't watching did they?
>
> Cheers,
> aj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:01:20 CEST

- reply

📅 Original date posted:2020-10-13
📝 Original message:
I wonder if we should just go the tried-and-tested leader-based
mechanism:
1. The node with the lexicographically lower node_id is determined to
be the leader.
2. The leader receives proposals for changes from itself and the peer
and orders them into a logical sequence of changes
3. The leader applies the changes locally and streams them to the peer.
4. Either node can initiate a commitment by proposing a `flush` change.
5. Upon receiving a `flush` the nodes compute the commitment
transaction and exchange signatures.
This is similar to your proposal, but does away with turn changes (it's
always the leader's turn), and therefore reduces the state we need to
keep track of (and re-negotiate on reconnect).
The downside is that we add a constant overhead to one side's
operations, but since we pipeline changes, and are mostly synchronous
during the signing of the commitment tx today anyway, this comes out to
1 RTT for each commitment.
On the other hand a token-passing approach (which I think is what you
propose) require a synchronous token handover whenever a the direction
of the updates changes. This is assuming I didn't misunderstand the turn
mechanics of your proposal :-)
Cheers,
Christian
Rusty Russell <rusty at rustcorp.com.au> writes:
> Hi all,
>
> Our HTLC state machine is optimal, but complex[1]; the Lightning
> Labs team recently did some excellent work finding another place the spec
> is insufficient[2]. Also, the suggestion for more dynamic changes makes it
> more difficult, usually requiring forced quiescence.
>
> The following protocol returns to my earlier thoughts, with cost of
> latency in some cases.
>
> 1. The protocol is half-duplex, with each side taking turns; opener first.
> 2. It's still the same form, but it's always one-direction so both sides
> stay in sync.
> update+-> commitsig-> <-revocation <-commitsig revocation->
> 3. A new message pair "turn_request" and "turn_reply" let you request
> when it's not your turn.
> 4. If you get an update in reply to your turn_request, you lost the race
> and have to defer your own updates until after peer is finished.
> 5. On reconnect, you send two flags: send-in-progress (if you have
> sent the initial commitsig but not the final revocation) and
> receive-in-progress (if you have received the initial commitsig
> not not received the final revocation). If either is set,
> the sender (as indicated by the flags) retransmits the entire
> sequence.
> Otherwise, (arbitrarily) opener goes first again.
>
> Pros:
> 1. Way simpler. There is only ever one pair of commitment txs for any
> given commitment index.
> 2. Fee changes are now deterministic. No worrying about the case where
> the peer's changes are also in flight.
> 3. Dynamic changes can probably happen more simply, since we always
> negotiate both sides at once.
>
> Cons:
> 1. If it's not your turn, it adds 1 RTT latency.
>
> Unchanged:
> 1. Database accesses are unchanged; you need to commit when you send or
> receive a commitsig.
> 2. You can use the same state machine as before, but one day (when
> this would be compulsory) you'll be able signficantly simplify;
> you'll need to record the index at which HTLCs were changed
> (added/removed) in case peer wants you to rexmit though.
>
> Cheers,
> Rusty.
>
> [1] This is my fault; I was persuaded early on that optimality was more
> important than simplicity in a classic nerd-snipe.
> [2] https://github.com/lightningnetwork/lightning-rfc/issues/794
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 15:01:12 CEST

- reply

📅 Original date posted:2020-10-13
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>> The LOW-REP node being out of pocket is the clue here: if one party
>> loses funds, even a tiny bit, another party gains some funds. In this
>> case the HIGH-REP node collaborating with the ATTACKER can extract some
>> funds from the intermediate node, allowing them to dime their way to all
>> of LOW-REP's funds. If an attack results in even a tiny loss for an
>> intermediary and can be repeated, the intermediary's funds can be
>> syphoned by an attacker.
>>
>
> The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all
> those failed payments and small losses and start to realize that something
> strange is happening. I know the proposal isn't fully trustless, but I
> think it can work in practice.
>
>
>> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the
>> preimage is even worse:
>>
>> - Attacker node `A` charging hold fees receives HTLC from victim `V`
>> - `A` does not forward the HTLC, but starts charging hold fees
>> - Just before the timeout for the HTLC would force us to settle onchain
>> `A` just removes the HTLC without forwarding it or he can try to
>> forward at the last moment, potentially blaming someone else for its
>> failure to complete
>>
>> This results in `A` extracting the maximum hold fee from `V`, without
>> the downstream hold fees cutting into their profits. By forwarding as
>> late as possible `A` can cause a downstream failure and look innocent,
>> and the overall payment has the worst possible outcome: we waited an
>> eternity for what turns out to be a failed attempt.
>>
>
> The idea is that an attacker node is untrusted and won't be able to charge
> hold fees.
The attacker controls both the sender and the HIGH-REP node. The sender
doesn't need to be trusted, it just initiates a payment that is used to
extract hold fees from a forwarding node. The HIGH-REP node doesn't
lose reputation because from what we can witness externally the payment
failed somewhere downstream. It does require an attacker to have a hold
fee charging HIGH-REP node, yes, but he is not jeopardizing its
reputation by having it fail downstream.
Cheers,
Christian

2023-06-09 14:59:04 CEST

- reply

📅 Original date posted:2020-02-24
📝 Original message:
Hi Bastien,
seems you were a bit quicker than I was with my writeup of my
proposal. I came up with a scheme that allows us to drop a large part of
the partial onion, so that it can indeed fit into an outer onion, and
the rendez-vous node RV can re-construct the original packet from the
included data [1].
The construction comes down to initializing the part of the routing info
string that is not going to be used, in such a way that the incremental
unwrappings at the nodes in the partial onion cancels out. Like you
mentioned in your mail it comes down extending the filler generation to
also cover the unused part and then applying all the encryption streams
xored to the unused space. By doing this we get the middle part of the
onion consisting of only 0x00 bytes.
I then decided to apply an additional ChaCha20 stream to this prefill,
such that the onion will not consist of mostly 0x00 bytes which would be
a dead giveaway to `RV+1` that `RV` was a rendez-vous node.
The process for the partial onion creator boils down to:
- Compute a path from `RV` of its choice to recipient `R`.
- Compute a shared secret using a random ephemeral private key and
`RV`s public key, and then generate a prefill-key
- Compute the prefill by combining the correct substrings of the
encryption streams for the nodes along the path, then add the
ChaCha20 stream keyed with the prefill-key.
- Wrap the onion, including payloads for each of the nodes along path
`RV` to `R`
- Trim out the unused space, which now will match the obfuscation
stream generated with the prefill-key
As an example such an onion, with 5 legacy hops (65 byte each) results
in a 325 + 66 bytes onion, and we save 975 bytes. See [2] for an example
of how this looks like.
The sender `S` then just does the following:
- Compute a route from `S` to `RV`
- Build an onion with the route, specifying the trimmed partial onion
as payload, along with the usual parameters, for `RV`
- Initiate payment with the constructed onion
Upon receiving an incoming HTLC with a partial onion the rendez-vous
node `RV` then just does the following:
- Verify all parameters as usual
- Extract the partial onion
- Use the ephemeral key from the partial onion to generate the shared
secret and the prefill key
- Generate the prefill stream and insert it in the correct place,
before the HMAC. This reconstitutes the original routing packet
- Swap out the original onion with the reconstituted onion and forward.
My writeup [1] is an early draft, but I wanted to get it out early to
give the discussion a basis to work off. I'll revisit it a couple of
times before opening a PR, but feel free to shout at me if I have
forgotten to consider something :-)
Cheers,
Christian
[1] https://github.com/lightningnetwork/lightning-rfc/blob/rendez-vous/proposals/0001-rendez-vous.md
[2] https://gist.github.com/cdecker/ec06452bc470749d9f6d2de73651c5fd
Bastien TEINTURIER via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> writes:
> Good morning list,
>
> After exploring decoys [1], which is a cheap way of doing route blinding,
> I'm turning back to exploring rendezvous.
> The previous mails on the mailing list mentioned that there was a
> technicality
> to make the HMACs check out, but didn't provide a lot of details.
> The issue is that the filler generation needs to take into account some hops
> that will be added *later*, by the payer.
>
> However it is quite easy to work-around, with a few space trade-offs.
> Let's consider a typical rendezvous setup, where Alice wants to be paid via
> rendezvous Bob, and Carol wants to pay that invoice:
>
> Carol -> ... -> Bob -> ... -> Alice
>
> If Alice knows how many bytes Carol is going to use for her part of the
> onion
> payloads, Alice can easily take them into account when generating her
> filler by
> pre-pending the same amount of `0` bytes. It seems reasonable to impose a
> fixed
> number of onion bytes for each side of the rendezvous (650 each?) so Alice
> would
> know that amount.
>
> When Carol completes the onion with her part of the route, she simply needs
> to
> generate filler data for her part of the route following the normal Sphinx
> protocol
> and apply it to the onion she found in the invoice.
>
> But the tricky part is that she needs to give Bob a way of generating the
> same
> filler data to unapply it. Then all HMACs correctly check out.
>
> I see two ways of doing that:
>
> * Carol simply sends that filler (650 bytes), probably via a TLV in
> `update_add_htlc`.
> This means every intermediate hop needs to forward that, which is painful
> and
> potentially leaking too much data.
> * Carol provides Bob with the rho keys used to generate her filler, and the
> length
> used by each hop. This leaks to Bob an upper bound on the number of hops
> and the
> number of bytes sent to each hop.
>
> Since shift-and-xor kind of crypto is hard to read as equations, but very
> easy to
> read as diagrams, I spent a bit of time doing beautiful ASCII art [2].
> Don't hesitate
> to have a look at it to find more details about how that works. You can
> also print
> that on t-shirts to look fancy at conferences. I also have some sample code
> working
> in eclair [3] for those who can read Scala without getting headaches.
>
> Are there other tricks we can use to reconcile both sides of the onion at
> Bob's?
> Maybe cdecker (or someone else) has an ace up his sleeve for me there? :)
>
> One important thing to note is that rendezvous on normal onions will be
> costly to
> integrate into invoices: it takes 1366 bytes to include one onion, and if
> we want
> to handle route failures or let the sender use multi-part, we will need to
> have a
> handful of pre-encrypted onions in the invoice (hence a few kB, which may
> not be
> practical for QR codes).
>
> But I did mention before that doing rendezvous on the trampoline onion
> could have
> better properties [4]. When doing that, having Carol transmit her filler
> data only
> to Bob, via the outer onion payload becomes practical and doesn't leak
> information.
> Multi-part would work with a single trampoline onion in the invoice (~500
> bytes),
> because nodes can do MPP between trampoline nodes thanks to the
> onion-in-onion
> construction. We simply need to decide the size of the trampoline onion to
> allow
> each side of the rendezvous to be able to insert a number of hops we're
> comfortable
> with. You can find more details in the "Rendezvous on a trampoline" section
> of [2].
>
> I'm really interested in other approaches to making rendezvous work with
> the HMACs
> correctly checking out. If people on this list have drafts, intuitions or
> random
> thoughts about possible constructions, please share them, I'd be happy to
> dive into
> them to explore alternatives to the one I found, hoping we can make this
> work and
> provide this feature to our users in the near future.
>
> A small side-note on Hornet. Hornet does offer many features that I believe
> we will
> want in Lightning in the future. It may seem that doing a custom rendezvous
> scheme
> is a waste of time since we'll ditch it once/if we implement Hornet. While
> that is
> true in the long run, I believe that if we're able to find a rendezvous
> scheme that
> isn't too much work to implement, it makes sense to have something
> available soon-ish.
> Hornet will likely be a longer-term effort that we won't get as soon as
> we'd like
> (especially since it will probably require a network-wide update). But who
> knows, maybe
> we may see that we are trying to create many features that are already
> built into Hornet
> (rendezvous, directed message support, etc) and will decide to implement
> Hornet sooner
> than expected?
>
> Cheers,
> Bastien
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002435.html
> [2] https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601
> [3] https://github.com/ACINQ/eclair/tree/sphinx-rendezvous
> [4]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002237.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:57:33 CEST

- reply

📅 Original date posted:2019-12-04
📝 Original message:
That is correct, the chain of noinput/anyprevout transactions is broken
as soon as the signers are online and can interactively bind and sign
without noinput/anyprevout.
Conner Fromknecht <conner at lightning.engineering> writes:
> Good evening,
>
>> I didn't think this was the design. The update transaction can spend any
> prior, with a fixed script, due to NOINPUT.
>
> From my reading of the final construction, each update transaction has a
> unique script to bind settlement transactions to exactly one update.
>
>> My understanding is that this is not logically possible?
> The update transaction has no fixed txid until it commits to a particular
> output-to-be-spent, which is either the funding/kickoff txout, or a
> lower-`nLockTime` update transaction output.
>> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
> txid it can spend, if it is constrained to spend a particular update
> transaction.
>
> This is also my understanding. Any presigned descendants of a NOINPUT txn
> must also use NOINPUT as well. This chain must continue until a signer is
> online to bind a txn to a confirmed input. The unique settlement keys thus
> prevent rebinding of settlement txns since NOINPUT with a shared script
> would be too liberal.
>
> Cheers,
> Conner
>
> On Mon, Dec 2, 2019 at 18:55 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Rusty,
>>
>> > > Hi all,
>> > > I recently revisited the eltoo paper and noticed some things related
>> > > watchtowers that might affect channel construction.
>> > > Due to NOINPUT, any update transaction can spend from any other, so
>> > > in theory the tower only needs the most recent update txn to resolve
>> > > any dispute.
>> > > In order to spend, however, the tower must also produce a witness
>> > > script which when hashed matches the witness program of the input. To
>> > > ensure settlement txns can only spend from exactly one update txn,
>> > > each update txn uses unique keys for the settlement clause, meaning
>> > > that each state has a unique witness program.
>> >
>> > I didn't think this was the design. The update transaction can spend
>> > any prior, with a fixed script, due to NOINPUT.
>> >
>> > The settlement transaction does not use NOINPUT, and thus can only
>> > spend the matching update.
>>
>> My understanding is that this is not logically possible?
>> The update transaction has no fixed txid until it commits to a particular
>> output-to-be-spent, which is either the funding/kickoff txout, or a
>> lower-`nLockTime` update transaction output.
>> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no
>> txid it can spend, if it is constrained to spend a particular update
>> transaction.
>>
>> Unless I misunderstand how update transactions work, or what settlement
>> transactions are.
>>
>> Regards,
>> ZmnSCPxj
>>
> --
> —Sent from my Spaceship
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:57:33 CEST

- reply

📅 Original date posted:2019-12-04
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Good morning Rusty,
>
>> ZmnSCPxj ZmnSCPxj at protonmail.com writes:
>>
>> > Good morning Rusty,
>> >
>> > > > Hi all,
>> > > > I recently revisited the eltoo paper and noticed some things related
>> > > > watchtowers that might affect channel construction.
>> > > > Due to NOINPUT, any update transaction can spend from any other, so
>> > > > in theory the tower only needs the most recent update txn to resolve
>> > > > any dispute.
>> > > > In order to spend, however, the tower must also produce a witness
>> > > > script which when hashed matches the witness program of the input. To
>> > > > ensure settlement txns can only spend from exactly one update txn,
>> > > > each update txn uses unique keys for the settlement clause, meaning
>> > > > that each state has a unique witness program.
>> > >
>> > > I didn't think this was the design. The update transaction can spend
>> > > any prior, with a fixed script, due to NOINPUT.
>> > > The settlement transaction does not use NOINPUT, and thus can only
>> > > spend the matching update.
>> >
>> > My understanding is that this is not logically possible?
>>
>> You're right, no wonder I missed this problem :(
>>
>> OK, so we need to change the key(s) every time. Can we tweak it based
>> on something the watchtower will know, i.e. something in the update tx
>> itself? Obviously not the output, as that would create a circular
>> dependency. Is there some taproot thing we can use to insert some
>> noise in the input?
>
> You could always add a taproot branch with a `OP_RETURN <randomness>` tapscript, which can never be used (thus has no effect on the overall security), but can inject randomness to the outer taproot key.
> This *is* secure, since bip-schnorr indicates that `e` is `h(R | P | m)`, with `P` being the pubkey itself, so that should be enough.
>
> Or why not BIP32 derivation?
> This should be just as secure.
I still fail to see the issue, update_tx and settlement_tx are
self-contained, and there is no need to recover the prevout scriptPubKey
or any value therein. Are we talking about things built on top of eltoo?
If that's the case, we need to use noinput/anyprevout anyway, so why not
just replicate the same logic and ship them bound correctly to the
watchtower?
I'd also argue that it's not a watchtower's job to finalize the entire
off-chain contract. It's main job is to watch the blockchain and react
should anything trigger it, while anything we build on top likely has
absolute locktimes (HTLCs have absolute timeouts), so it the client that
knows when it has to check back in and settle anything that happened.
Cheers,
Christian

2023-06-09 14:56:20 CEST

- reply

📅 Original date posted:2019-10-01
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> To elucidate further ---
>
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
>
> This new opcode ignores any `SIGHASH` flags, if present, on a
> signature, but instead hashes the current transaction without the
> input references, then checks that hash to the signature.
>
> This is equivalent to `SIGHASH_NOINPUT`.
>
> Yet as an opcode, it would be possible to embed in a Taproot script.
>
> For example, a Decker-Russell-Osuntokun would have an internal Taproot
> point be a 2-of-2, then have a script `OP_1
> OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden
> script, but cooperative closes would use the 2-of-2 directly.
>
> Of note, is that any special SCRIPT would already be supportable by Taproot.
> This includes SCRIPTs that may potentially lose funds for the user.
> Yet such SCRIPTs are already targetable by a Taproot address.
>
> If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not
> so concerned about Taproot abuse?
That would certainly be another possibility, which I have not explored
in detail so far. Due to the similarity between the various signature
checking op-codes it felt that it should be a sighash flag, and it
neatly slotted into the already existing flags. If we go for a separate
opcode we might end up reinventing the wheel, and to be honest I feared
that proposing a new opcode would get us into bikeshedding territory
(which I apparently failed to avoid with the sighash flag anyway...).
The advantage would be that with the sighash flag the spender is in
charge of specifying the flags, whereas with an opcode the output
dictates the signature verification modalities. The downside is the
increased design space.
What do others think? Would this be an acceptable opt-in mechanism that
addresses the main concerns?
Cheers,
Christian

2023-06-09 14:56:20 CEST

- reply

📅 Original date posted:2019-10-03
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
>> That is very much how I was planning to implement it anyway, using a
>> trigger transaction to separate timeout start and the actual
>> update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo
>> there shouldn't be an issue here :-)
>
> My understanding is that a trigger transaction is not in fact
> necessary for Decker-Russell-Osuntokun: any update transaction could
> spend the funding transaction output directly, and thereby start the
> relative timelock. At least, if we could arrange the funding
> transaction output to be spendable directly using `SIGHASH_NOINPUT` or
> variants thereof.
This is the case in which we don't have a pre-signed settlement
transaction (or in this case refund transaction) that uses a relative
timelock. In order to have a refund transaction we would need to have
the first update and settlement pair be signed before funding (otherwise
the funder isn't sure she is getting her funds back). Since that first
update and settlement pair do not need to be rebound (they can only ever
be bound to the funding transaction) they can be signed without
noinput/anyprevoutanyscript. If we use output tagging we would mandate
that this first update must be published, so that the funding output is
indistinguishable from a normal output, and the first update switches
from non-noinput/anyprevoutanyscript to enabling it. Collaborative
closes are still indistinguishable, unilateral closes require the
switch, but then would be identifiable anyway.
The one downside I can see is that we now mandate that unilateral closes
also publish the first update, which is a bit annoying.
>> While I do agree that we should keep outputs as unidentifiable as
>> possible, I am starting to question whether that is possible for
>> off-chain payment networks since we are gossiping about the existence of
>> channels and binding them to outpoints to prove their existence anyway.
>
> * Lightning supports unpublished channels, so we do not gossip some outpoints even though they are in fact channels underneath.
> * I confess the existence of unpublished channels in the spec fails to summon any reaction other than incredulity from me, but they exist nonetheless, my incredulity notwithstanding.
That is true, we do however selectively tell others about the channel's
existence (in invoices, our peers, ...) so I wouldn't consider that to
be the most secret information :-)
As for why they exist: nodes need to have the option of not announcing
their channels to reduce the noise in the network with channels that are
unlikely to be useable in order to forward payments. If every node were
to announce their channels we'd have a much larger routing table, mostly
consisting of unusable channels going to leafs in the
network. Furthermore, the sheer threat that there might be unannounced
channels adds uncertainty for attackers trying to profile nodes: "I see
only my channel with my peer, but he might have unannounced channels, so
I can't really tell whether the payment I forwarded to it is destined
for it or one of its unannounced peers".
> * Historical channels that have been cooperatively closed are no longer normally gossiped, so the fact that they used to be channels is no longer widely broadcast, and may eventually be forgotten by most or all of the network.
> * This means anyone who wants to record the historical use of Lightning will have to retain the information themselves, rather than delegating it to fullnodes everywhere.
Good point, it requires storing the ephemeral data from gossip, that's
not all that hard, but I agree that it puts up a small barrier for
newcomers.

2023-06-09 14:56:19 CEST

- reply

📅 Original date posted:2019-10-01
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> I rather strongly oppose output tagging.
>
> The entire point of for example Taproot was to reduce the variability
> of how outputs look like, so that unspent Taproot outputs look exactly
> like other unspent Taproot outputs regardless of the SCRIPT (or lack
> of SCRIPT) used to protect the outputs. That is the reason why we
> would prefer to not support P2SH-wrapped Taproot even though
> P2SH-wrapping was intended to cover all future uses of SegWit,
> including SegWit v1 that Taproot will eventually get.
That is a bit reductive if you ask me. Taproot brings a number of
improvements such as the reduction of on-chain footprint in the
collaborative spend case, the hiding of complex logic in that case, and
yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be
to make everything look identical to the outside observer, but saying
that separating outputs into two coarse-grained domains is equivalent to
throwing the baby out with the bath-water :-)
That being said, I should clarify that I would prefer not having to make
special accomodations on top of the raw sighash_noinput proposal, for
some perceived, but abstract danger that someone might shoot themselves
in the foot. I think we're all old enough not to need too much
handholding :-)
Output tagging is my second choice, since it minimizes the need for
people to get creative to work around other proposals, and minimizes the
on-chain footprint, and finally chaperone signatures are my least
preferred option due to its heavy-handed nature and the increased cost.
> Indeed, if it is output tagging that gets into Bitcoin base layer, I
> would strongly suggest the below for all Decker-Russell-Osuntokun
> implementations:
>
> * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, confirmed onchain
> * A "translator transaction" spending the above and paying out to a SegWit v16 output-tagged output, kept offchain.
> * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` spending the translator transaction output.
> * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` spending the update transaction output.
That is very much how I was planning to implement it anyway, using a
trigger transaction to separate timeout start and the actual
update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo
there shouldn't be an issue here :-)
> The point regarding use of a commonly-known privkey to work around
> chaperone signatures is appropriate to the above, incidentally. In
> short: this is a workaround, plain and simple, and one wonders the
> point of adding *either* chaperones *or* output tagging if we will, in
> practice, just work around them anyway.
Exactly, why introduce the extra burden of chaperone signatures or
output tagging if we're just going to sidestep it?
> Again, the *more* important point is that special blockchain
> constructions should only be used in the "bad" unilateral close case.
> In the cooperative case, we want to use simple plain
> bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot
> SegWit v1 addresses, to increase the anonymity set of all uses of
> Decker-Russell-Osuntokun and other applications that might use
> `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple
> bip-schnorr-signed n-of-n cases when the protocol is completed
> successfully by all participants).
While I do agree that we should keep outputs as unidentifiable as
possible, I am starting to question whether that is possible for
off-chain payment networks since we are gossiping about the existence of
channels and binding them to outpoints to prove their existence anyway.
Not the strongest argument I know, but there's little point in talking
ideal cases when we need to weaken that later again.
>> Open questions
>>
>> ---------------
>>
>> The questions that remain to be addressed are the following:
>>
>> 1. General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout. While at the CoreDev meeting I think everybody agreed that
>> these proposals a useful, also beyond eltoo, not everybody could be
>> there. I'd therefore like to elicit some feedback from the wider community.
>
> I strongly agree that `NOINPUT` is useful, and I was not able to attend CoreDev (at least, not with any human fleshbot already known to you --- I checked).
Great, good to know that I'm not shouting into the void, and that I'm
not just that crazy guy trying to get his hairbrained scheme to work :-)
>> 2. Is there strong support or opposition to the chaperone signatures
>> introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
>> formulate a concrete set of pros and contras, rather than talk about
>> abstract dangers or advantages.
>
> No opposition, we will just work around this by publishing a common
> known private key to use for all chaperone signatures, since all the
> important security is in the `NOINPUT` signature anyway.
>
>>
>> 3. The same for output tagging / explicit opt-in. What are the advantages and
>> disadvantages?
>
> Strongly oppose, see above about my argument.
>
>>
>> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
>> confusion and make for simpler discussions in the end.
>
> Ambivalent, mildly support.
>
>>
>> 5. Anything I forgot to mention :-)
>
> Cats are very interesting creatures, and are irrelevant to `SIGHASH_NOINPUT` discussion, but are extremely cute nonetheless.
Definitely agreed :+1:

2023-06-09 14:56:18 CEST

- reply

📅 Original date posted:2019-10-03
📝 Original message:
ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> Good morning lists,
>
> Let me summarize concerns brought up:
>
> * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`.
> * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output.
>
> I propose the below instead:
>
> * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`.
> * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`.
>
> Then, on usage:
>
> * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence.
> * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`.
>
> This solves both concerns:
>
> * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it.
> * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`.
>
> Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy.
> But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me.
>
> Would this alternate proposal hold better muster?
Intriguing idea, this would be an invisible tagging, since the opt-in to
noinput and friends is hidden inside the committed script, which only
gets revealed whenever we actually need it.
For eltoo this would mean that the funding output would be invisibly
tagged, and the cooperative close would use the taproot pubkey, while
the uncooperative close, which would require noinput opt-in, reveals the
script, proving prior opt-in, and provides a matching signature.
If I'm not mistaken this would require AJ's alternative pubkey encoding
(0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?

2023-06-09 14:56:18 CEST

- reply

📅 Original date posted:2019-10-03
📝 Original message:
Chris Stewart <chris at suredbits.com> writes:
> I do have some concerns about SIGHASH_NOINPUT, mainly that it does
> introduce another footgun into the bitcoin protocol with address reuse.
> It's common practice for bitcoin businesses to re-use addresses. Many
> exchanges [1] reuse addresses for cold storage with very large sums of
> money that is stored in these addreses.
>
> It is my understanding with this part of BIP118
>
>>Using NOINPUT the input containing the signature no longer references a
> specific output. Any participant can take a transaction and rewrite it by
> changing the hash reference to the previous output, without invalidating
> the signatures. This allows transactions to be bound to any output that
> matches the value committed to in the witness and whose witnessProgram,
> combined with the spending transaction's witness returns true.
>
> if an exchange were to once produce a digital signature from that cold
> storage address with a SIGHASH_NOINPUT signature, that signature can be
> replayed again and again on the blockchain until their wallet is drained.
> This might be able to mitigated since the signatures commit to outputs,
> which may be small in value for the transaction that SIGHASH_NOINPUT was
> used. This means that an exchange could move coins from the address with a
> larger transaction that spends money to a new output (and presumably pays a
> higher fee than the smaller transactions).
Thanks for sharing your concerns Chris, I do agree that noinput and
friends are a very sharp knife that needs to be treated carefully, but
ultimately it's exactly its sharpness that makes it useful :-)
> ### Why does this matter?
>
> It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
> protocols like Lightning. This gives us the building blocks for enforcing
> specific offchain states to end up onchain [2].
>
> Since this tool is useful, we can presume that it will be integrated into
> the signing path of large economic entities in bitcoin -- namely exchanges.
> Many exchanges have specific signing procedures for transactions that are
> leaving an exchange that is custom software. Now -- presuming wide adoption
> of off chain protocols -- they will need to have a _second unique signing
> path that uses SIGHASH_NOINPUT_.
>
> It is imperative that this second signing path -- which uses
> SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
> controls an exchanges onchain funds. If this were to happen, fund lost
> could occur if the exchange is reusing address, which seems to be common
> practice.
Totally agreed, and as you point out, BIP118 is careful to mandate
separate private keys be used for off-chain contracts and that the
off-chain contract never be mixed with the remainder of your funds. The
way eltoo uses noinput we selectively open us up to replay attacks
(because that's what the update mechanism is after all) by controlling
the way the transactions can be replayed very carefully, and any other
use of noinput would need to make sure to have the same guarantees.
However, once we have separated the two domains, we can simply use a
separate (hardened) derivation path from a seed key, and never mix them
afterwards. We never exchange any private keys, so even leaking info
across derived keys is not an issue here.
> This is stated here in BIP118:
>
>>This also means that particular care has to be taken in order to avoid
> unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
> used, unless it is explicitly needed for the application, e.g., it MUST NOT
> be a default signing flag in a wallet implementation. Rebinding is only
> possible when the outputs the transaction may bind to all use the same
> public keys. Any public key that is used in a NOINPUT signature MUST only
> be used for outputs that the input may bind to, and they MUST NOT be used
> for transactions that the input may not bind to. For example an application
> SHOULD generate a new key-pair for the application instance using NOINPUT
> signatures and MUST NOT reuse them afterwards.
>
> This means we need to encourage onchain hot wallet signing procedures to be
> kept separate from offchain hot wallet signing procedures, which introduces
> more complexity for key management (two keychains).
This is already the case: off-chain systems always require access to the
signing key in real-time in order to be useful. If any state change is
performed in a channel, even just adjusting fees or receiving a payment,
requires the signature from the key associated with the channel. With
high security on-chain systems on the other hand you should never have a
hot key that automatically signs off on transfers without human
intervention. So I find it unlikely that mandating the on-chain keys to
be kept separate from off-chain keys is any harder than what should be
done with the current systems.
> One (of the few) upsides of the current Lightning penalty mechanism is that
> fund loss can be contained to balance of the channel. You cannot do
> something in the current protocol that will effect your funds outside of
> that channel. With SIGHASH_NOINPUT, that property changes.
Good point, but if the key hygiene is maintained as detailed in BIP118,
i.e., off-chain keys must be kept separate from on-chain keys, and that
each off-chain contract instance uses a separate set of keys, that
property is maintained.
Regards,
Christian

2023-06-09 14:54:59 CEST

- reply

📅 Original date posted:2019-05-15
📝 Original message:
Hi Bastien,
thanks for investigating.
> I have been digging into Anthony Towns' anyprevout BIP
> <https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki>
> proposal
> to verify that it has everything we need for Eltoo
> <https://blockstream.com/eltoo.pdf>.
>
> The separation between anyprevout and anyprevoutanyscript is very handy
> (compared to the previous noinput proposal).
> Unless I'm missing something, it would simplify the funding tx (to a simple
> multisig without cltv/csv) and remove the need for the trigger tx.
I think it makes sense for us to consider both variants, one committing
to the script and the other not committing to the script, but I think it
applies rather to the `update_tx` <-> `settlement_tx` link and less to
the `funding_tx` <-> `update_tx` link and `update_tx` <-> `update_tx`
link. The reason is that the `settlement_tx` needs to be limited to be
bindable only to the matching `update_tx` (`anyprevout`), while
`update_tx` need to be bindable to the `funding_tx` as well as any prior
`update_tx` which differ in the script by at least the state number
(hence `anyprevoutanyscript`).
Like AJ pointed out in another thread, the use of an explicit trigger
transaction is not really needed since any `update_tx` can act as a
trigger transaction (i.e., start the relative timeouts to tick). This
was an oversight of mine, which may have contributed more confusion than
necessary :-)
The `funding_tx` itself doesn't need any form of timeout, in fact
collaborative spending/closing without a timeout should always be
possible. The `settlement_tx`s can have a BIP68-style relative timelock,
which also saves us a few bytes.
> The more tricky part to integrate is the chaperone signature.
> If I understand it correctly (which I'm not guaranteeing), we would need to
> modify the update transactions to something like:
>
> OP_IF
>
> 10 OP_CSV
>
> 1 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
>> byte in this line is 0x02 or 0x03
>
> 2 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
>> byte in this line is 0x00 or 0x01
>
> OP_ELSE
>
> <S(i) + 1> OP_CLTV
>
> 1 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
>> byte in this line is 0x02 or 0x03
>
> 2 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first
>> byte in this line is 0x00 or 0x01
>
> OP_END
We could collapse those 1-of-2 multisigs into a single-sig if we just
collaboratively create a shared private key that is specific to the
instance of the protocol upon setup. That minimizes the extra space
needed.
Something that I notived talking to Jonas Nick is that we might have
some interaction between the taproot and noinput (or any of its aliases
:D). Specifically we can't make make use of the collaborative path where
we override an `update_tx` with a newer one in taproot as far as I can
see, since the `update_tx` needs to be signed with noinput (for
rebindability) but there is no way for us to specify the chaperone key
since we're not revealing the committed script.
> (I ommitted the tapscript changes, ie moving to OP_CHECKSIGADD, to
> highlight only the chaperone changes)
>
> When updating the channel, Alice and Bob would exchange their
> anyprevoutanyscript signatures (for the 2-of-2 multisig).
> The chaperone signature can be provided by either Alice or Bob at
> transaction broadcast time (so that it commits to a specific input
> transaction).
>
> It seems to me that using the same key for both signatures (the chaperone
> one and the anyprevoutanyscript one) is safe here, but if someone knows
> better I'm interested.
> If that's unsafe, we simply need to introduce another key-pair (chaperone
> key).
>
> Is that how you guys understand it too? Do you have other ideas on how to
> comply with the need for a chaperone signature?
>
> Note that as Anthony said himself, the BIP isn't final and we don't know
> yet if chaperone signatures will eventually be needed, but I think it's
> useful to make sure that Eltoo could support it.
I quite like the chaperone idea, however it doesn't really play nice
with taproot collaborative spends that require anyprevout /
anyprevoutanyscript / noinput, which would make our transactions stand
out quite a bit. Then again this is only the case for the unhappy,
unilateral close, path of the protocol, which (hopfully) should happen
rarely.
Cheers,
Christian

2023-06-09 14:54:47 CEST

- reply

📅 Original date posted:2019-04-03
📝 Original message:
On Wed, 3 Apr 2019, 05:42 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Pierre and list,
>
> > 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.
>
> Just to be clear, the issue is for example with a network like:
>
>
> A ------- B -------- C
> / \
> / \
> / \
> / \
> D ------- E
>
> Then, A creates an inner trampoline onion "E->C", and an outer onion
> "A->B->E".
>
> E, on receiving the inner trampoline onion "E->C", finds that E->B
> direction is low capacity, so routes over the outer onion "E->D->B->C" with
> inner trampoline onion "C".
>
> This creates an overall route A->B->E->D->B->C.
>
> When the B->C HTLC is resolved, B can instead claim the A->B HTLC and just
> fail the D->B HTLC, thereby removing D and E from the route and claiming
> their fees, even though they participated in the route.
>
This is not an issue. Like we discussed for the multi-part payments the
HTLCs still resolve correctly, though node B might chose to short circuit
the payment it'll also clear the HTLCs through E And D (by failing them
instead of settling them) but the overall payment remains atomic and
end-to-end secure. The skipped nodes (which may include the trampoline) may
lose a bit of fees, but that is not in any way different than a failed
payment attempt that is being retried from the sender :-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190403/326187f0/attachment.html>

2023-06-09 14:54:28 CEST

- reply

📅 Original date posted:2019-03-14
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> so if you used a tagged output, you could do everything normal taproot
> address could, but also do noinput sigs for them.
>
> So you might have:
>
> funding tx -> cooperative claim
>
> funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
>
> funding tx -> update 3 [TAGGED] ->
> update 4 [TAGGED,NOINPUT] ->
> settlement 4 [TAGGED,NOINPUT] ->
> claim [NOINPUT]
>
> In the cooperative case, no output tagging needed.
I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.

2023-06-09 14:52:24 CEST

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Great proposal ZmnSCPxj, but I think I need to raise a small issue with
it. While writing up the proposal for rendez-vous I came across a
problem with the mechanism I described during the spec meeting: the
padding at the rendez-vous point would usually zero-padded and then
encrypted in one go with the shared secret that was generated from the
previous ephemeral key (i.e., the one before the switch). That ephemeral
key is not known to the recipient (barring additional rounds of
communication) so the recipient would be unable to compute the correct
MACs. There are a number of solutions to this, basically setting the
padding to something that the recipient could know when generating its
half onion.
My current favorite goes like this:
1. Rendez-vous RV receives an onion, performs ECDH like normal to get
the shared secret, decrypts its payload, simultaneously encrypts
the padding.
2. It extracts its per-hop payload and shifts the entire packet over
(shift its payload out and the newly generated padding in)
3. It then notices that it should perform an ephemeral key switch, now
deviating from the normal protocol (which would just be to generate
the new ephemeral key, serialize and forward)
3.1. It zero-fills the padding that it just added (so we are in a
state that the recipient knew when generating its partial onion
3.2 It performs ECDH with the switched in ephemeral key to get a new
shared secret that which is then used to unwrap one additional
layer of encryption, and most importantly encrypt the padding so
the next hop doesn't see the zero-filled padding.
3.3 Only then will it generate the new ephemeral key for the next
hop, based on the switched in ephemeral key and the newly
generated shared secret, serialize the packet and forward it.
This has the advantage of reusing all the existing machinery but
assembling it a bit differently, by adding a little detour when
generating the next onion. It involves one additional ECDH at the
rendez-vous, one ChaCha20 encryption and one scalar multiplication to
generate the next ephemeral keys. It does not need more space than the
single ephemeral key in the per-hop payload.
And now for the reason that I write this as a reply to your post: with
this scheme it is not possible for C to find an ephemeral key that would
end up identical to the one that D would require to decrypt the onion
correctly. This would not be an issue if D is informed about this split
and would basically accept whatever it gets, but that kind of defeats
the transparency that you were going for with your proposal.
I'm open for other proposals but I currently can't think of a way to
make sure that a) the recipient can deterministically generate the same
padding that RV will generate, and b) hide the fact that RV was indeed a
rendez-vous point (e.g., by leaving the padding be a well known
constant).
Sorry for this problem, I had a mental off-by-one at the meeting that I
hadn't considered, the solution should work, but it makes this kind of
things a bit harder.
Cheers,
Christian
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Good morning list,
>
> As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.
>
> It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing.
>
> For instance, consider this below graph:
>
> E<---D--->C<---B
> ^ /
> | /
> |L
> A
>
> In the above, B requests a route from B->C->D->E.
>
> However, C cannot send to D, since the channel direction is saturated in favor of D.
>
> Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing.
>
> This can allow re-routing or payment splitting over multiple hops.
>
> Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:51:45 CEST

- reply

📅 Original date posted:2018-10-15
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Splicing isn't a substitute for allowing multiple channels. Multiple
> channels allow nodes to:
>
> * create distinct channels with distinct acceptance policies.
> * create a mix of public and non-advertised channels with a node.
> * be able to send more than the (current) max HTLC amount
> using various flavors of AMP.
> * get past the (current) max channel size value
> * allow a link to carry more HTLCs (due to the current super low max HTLC
> values) given the additional HTLC pressure that
> AMP may produce (alternative is a commitment fan out)
While these are all good points, I think they are equally well served if
by creating channels to other peers. This has the added benefit of
reducing the node's reliance on a single peer. In fact it seems we are
currently encouraging users to have a small number of fat channels that
are manually maintained (dual-funding, splicing, multiple channels per
peer), rather than making the default to create a diverse set of
channels that allow indirectly routed payments.
Instead of obsessing about that one peer and hoping that that peer is
online when we need it, we should make routed payments a first-class
citizen. If we can route correctly and with confidence we can stop
worrying about that one peer and our connectivity to it. On the other
hand, if routing doesn't work, and people have to worry about that one
channel that connects them directly to the destination, then we're not
much of a network, but rather a set of disjoint channels.
Ultimately users should stop caring about individual channels or peer
relationships, and multipath routing gets us a long way there. I'd
really like to have a wallet that'll just manage channels in the
background and not expose those details to the users which just want to
send and receive payments, and we can start that now by de-emphasizing
the importance of the peer selection.
Regards,
Christian

2023-06-09 14:51:37 CEST

- reply

📅 Original date posted:2018-10-11
📝 Original message:
On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> > * Once we have enough confirmations we merge the channels (either
> > automatically or with the next channel update). A new commitment tx is
> > being created which now spends each output of each of the two funding tx
> > and assigns the channel balance to the channel partners accordingly to
> the
> > two independent channels. The old commitment txs are being invalidated.
> > * The disadvantage is that while splicing is not completed and if the
> > funder of the splicing tx is trying to publish an old commitment tx the
> > node will only be punished by sending all the funds of the first funding
> tx
> > to the partner as the special commitment tx of the 2nd output has no
> newer
> > state yet.
>
> Yes, this is the alternative method; produce a parallel funding tx
> (which only needs to support a single revocation, or could even be done
> by a long timeout) and then join them when it reaches the agreed depth.
>
> It has some elegance; particularly because one side doesn't have to do
> any validation or store anything until it's about to splice in. You get
> asked for a key and signature, you produce a new one, and sign whatever
> tx they want. They hand you back the tx and the key you used once it's
> buried far enough, and you check the tx is indeed buried and the output
> is the script you're expecting, then you flip the commitment tx.
>
> But I chose chose not to do this because every transaction commitment
> forever will require 2 signatures, and doesn't allow us to forget old
> revocation information.
>
> And it has some strange side-effects: onchain this looks like two
> channels; do we gossip about both? We have to figure the limit on
> splice-in to make sure the commitment tx stays under 400kSipa.
>
This is a lot closer to my original proposal for splicing, and I
still like it a lot more since the transition from old to new
channel is bascially atomic (not having to update state on both
pre-splice and post-splice version). The new funds will remain
unavailable for the same time, and since we allow only one
concurrent splice in your proposal we don't even lose any
additional time regarding the splice-outs.
So pulling the splice_add_input and splice_add_output up to
signal the intent of adding funds to a splice. Splice_all_added
is then used to start moving the funds to a pre-allocated 2-of-2
output where the funds can mature. Once the funds are
matured (e.g., 6 confirmations) we can start the transition: both
parties claim the funding output, and the pre-allocated funds, to
create a new funding tx which is immediately broadcast, and we
flip over to the new channel state. No need to keep parallel
state and then disambiguating which one it was.
The downsides of this is that we now have 2 on-chain
transactions (pre-allocation and re-open), and splice-outs are no
longer immediate if we have a splice-in in the changeset as well.
The latter can be remediatet with one more reanchor that just
considers splice-ins that were proposed.
>
> > I believe splicing out is even safer:
> > * One just creates a spent of the funding tx which has two outputs. One
> > output goes to the recipient of the splice out operation and the second
> > output acts as a new funding transaction for the newly spliced channel.
> > Once signatures for the new commitment transaction are exchanged
> (basically
> > following the protocol to open a channel) the splicing operation can be
> > broadcasted.
> >
> > * The old channel MUST NOT be used anymore but the new channel can be
> > operational right away without blockchain confirmation. In case someone
> > tries to publish an old state of the old channel it will be a double
> spent
> > of the splicing operation and in the worst case will be punished and the
> > splicing was not successful.
> >
> > if one publishes an old state of the new
> > channel everything will just work as normal even if the funding tx is not
> > yet mined. It could only be replaced with an old state of the previous
> > channel (which as we saw is not a larger risk than the usual operation
> of a
> > lightning node)
>
> Right, you're relying on CPFP pushing through the splice-out tx if it
> gets stuck. This requires that we check carefully for standardness and
> other constraints which might prevent this; for example, we can't allow
> more than 20 (?) of these in a row without being sufficiently buried
> since I think that's where CPFP calculations top out.
>
We shouldn't allow more than one pending splice operation anyway, as
stated in your proposal initially. We are already critically reliant on our
transaction being confirmed on-chain, so I don't see this as much of an
added issue.
> > As mentioned maybe you had this workflow already in your mind but I don't
> > see why we need to send around all the messages twice with my workflow.
> We
> > only need to maintain double state but only until it is fair / safe to do
> > so. I would also believe that with my approach it should be possible (but
> > not really necessary) to have multiple splicing operations in parallel.
>
> The extra sigs are only needed in transition, though; once splicing is
> over the channel looks exactly like a newly created one, which is nice.
>
I'm less worried about the bandwidth overhead, rather the
parallel state updates are error prone and there might be
corner-cases that we simply don't see right now. Having parallel
state-updates just for the sake of saving some on-chain
fees (fees that we'd spend in purely on-chain cases anyway) has a
direct impact on the channel state machine.
> > One other question: What happens to the short_channel_id of a channel to
> > which founds have been spliced in?
>
> In the parallel splice world, they look like two channels. In my
> proposal it looks like a new channel, with a channel_update to make sure
> modern nodes know that the transition is happening.
>
With the pre-allocation the final effect is the same, we've just
pulled some of the waiting time above the re-anchoring and added
one more TX.
This is one of the cases where a simpler solution (relatively
speaking ^^) is to be preferred imho, allowing for future
iterations.
Cheers,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181011/f7fa9632/attachment.html>

2023-06-09 14:51:31 CEST

- reply

📅 Original date posted:2018-09-20
📝 Original message:
That might not be so desirable, since it leaks the current channel
capacity to the user. Depending on how fine grained the amount in the
invoice is and how the user can control it, he could do a binary search
over capacities and very reliably tell how much capacity you have and
track it over time. That is still the case for a single channel, but if
you always chose the same channel it reduces how much info is leaked.
Cheers,
Christian
Johan Torås Halseth <johanth at gmail.com> writes:
> Any reason not to include _all_ (up to a limit) incoming channels with
> sufficient capacity?
>
> Cheers,
> Johan
>
> On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <rusty at blockstream.com> wrote:
>
>> 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
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:50:20 CEST

- reply

📅 Original date posted:2018-05-03
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Ha, no, looking at the detailed `SIGHASH_NOINPUT` spec, `hashPrevouts`, which normally commits to the other inputs, is blanked, so we do not commit to them either. This means that `SIGHASH_NOINPUT` implicitly has a `SIGHASH_ANYONECANPAY`.
>
> (the BIP `SIGHASH_NOINPUT` in the eltoo pdf does not mention `hashSequence`, but it seems you managed to add that to your github BIP repository)
Yeah, Russell O'Connor pointed that difference out and I saw no point in
committing to the hashSequence, so I amended both the paper and the
BIP. The paper will get updated in a few days with the typos people have
found, but I thought that the BIP discussion was more urgent to keep up
to date, so I pushed that directly :-)

2023-06-09 14:50:19 CEST

- reply

📅 Original date posted:2018-05-01
📝 Original message:
Excellent summary ZmnSCPxj, I'll try to address the points inline (if
there is anything to add that is):
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Hi Christian,
>
> Let me know if I have summarized the paper accurately below:
>
> 1. SIGHASH_NOINPUT removes all inputs of the transaction copy before
> signing/verifying.
It sets them to a known constant, in this case we just blank
them. Removing could entail more costly serialization depending on the
implementation. bitcoind serializes into a hash accumulator so it'd not
make a difference there, but others may do it differently.
> 2. SIGHASH_NOINPUT can be combined with SIGHASH_SINGLE. It is
> dangerous to combine it with SIGHASH_NONE (as this also deletes all
> outputs of the transaction copy, so the signature only commits to
> nLockTime) and possibly pointless to combine it with
> SIGHASH_ANYONECANPAY (which deletes other inputs, but since there are
> no inputs after SIGHASH_NOINPUT, there is nothing else to delete).
> The BIP only mentions combining it with SIGHASH_SINGLE, in any case.
`SIGHASH_SINGLE` really is only singled out (no pun intended) because it
is usefull for the fee feature that Rusty came up with. It's not our
intention to exclude other uses, but you're right, it's hard to come up
with a use-case for `SIGHASH_NOINPUT` in combination with
`SIGHASH_NONE` or `SIGHASH_ANYONECANPAY` :-)
In particular we don't want to exclude potential future sighash types,
but those will have to be dealt with when they come up.
> 3. We have these kinds transactions: (1) funding transaction paying
> out to an ordinary N-of-N multisig (confirmed onchain); (2) offchain
> trigger transaction spending a funding transaction and paying out to
> the "update transaction script"; (3) offchain update transaction
> spending a trigger or update transaction and paying out to the "update
> transaction script" (the same script template as in trigger
> transaction); (4) offchain settlement transaction spending a trigger
> or update transaction and paying out to the counterparties according
> to the final agreed distribution of funds. Update and settlement
> transactions are signed with SIGHASH_NOINPUT flags.
>
> 4. The update transaction script has two branches: a CSV-encumbered
> N-of-N "settlement" branch, and a CLTV-encumbered N-of-N "update"
> branch. Crucially, we use past Unix timestamps for the CLTV
> encumberance on the update. The CLTV-encumberance starts with a
> minimum time value on the trigger transaction, and increments by 1 for
> every update transaction.
Really any monotonically increasing sequence of increments will work,
but incrementing by 1 maximizes the number of updates we can perform,
yes.
> 5. The CLTV-encumberance ensures that if a past update transaction is
> confirmed, we can spend it using any later update transaction, since
> CLTV uses `stackTop <= nLockTime`. The actual `nLockTime` we use is a
> past Unix timestamp so they are not actually time-encumbered, but the
> `OP_CLTV` still ensures that any later update transaction can be used
> to spend from any earlier update transaction, but not vice versa.
> This is actually quite clever.
Correct, the only reason to use `nLocktime` here is that we need the
signature of the update transaction to commit to the state number, so we
can't put it in the script itself.
> 6. The pubkeys on the settlement branch of each update transaction
> are different, and are derived using any hierarchical derivation
> method (trivially we can simply use the CLTV-encumberance value as the
> derivation index). This ensures that each settlement transaction can
> only spend a particular update transaction. Or in other words: There
> is a one-to-one correspondence between update and settlement
> transaction, and a settlement transaction can only confirm if the
> corresponding update transaction can be confirmed deeply enough
> without having its output re-spent.
Other bindings are possible, e.g., compare the `nLocktime` again, but
binding through pubkeys minimizes the script size.
> 7. The pubkeys on the update branch are all the same in all update
> transactions. This lets any update transaction replace any other
> update transaction, as long as the CLTV-encumberance (which is used
> for ordering rather than actual absolute locktime) is respected;
> together they mean that any later update transaction can replace any
> earlier update transaction.
>
> 8. If an old update transaction is confirmed, the settlement
> transaction corresponding to it is still encumbered by CSV and cannot
> be confirmed immediately. During this time, a later update
> transaction can spend it and be confirmed. If that update transaction
> is still not the latest available, it can be further replaced with
> any, later transaction (since the CLTV-encumberance and the
> `nLockTime` increase in lockstep with each other) until the latest
> update transaction is confirmed.
Notice that the update transactions are actually paying their keep,
i.e., they have fees attached, so we think that participants will simply
jump to the latest state and not waste fees on things that have no
chance of getting them closer to getting an old state enforced.
> 9. When the latest update transaction gets confirmed, no other update
> transaction can successfully spend its "update" branch (as their
> `nLockTime` is less than the CLTV-encumberance on that branch). This
> lets the CSV-encumbered settlement transaction be confirmable after
> some blocks.
>
> 10. Update transactions pay no fees! Instead, for update
> transactions (but not settlement transactions) we additionally give
> SIGHASH_SINGLE: thus, no matter what transaction they end up in, the
> signatures for the update transaction will always be verified against
> only the update transaction output that pays out to the update
> transaction script. We join update transactions with a spend of some
> onchain UTXO we control, which pays for the fees of the joined the
> update transactions, and may have a second output that is the
> remainder of the fund after paying the fees.
>
> 11. Settlement transactions can carry contracts (in much the same way
> that Poon-Dryja commitment transactions); however contracts that
> contain absolute timelock components will be affected by the
> CSV-encumberance of the settlement transaction.
Exactly, the timeouts need to be chosen high enough in order to allow an
orderly resolution on-chain, should one party become uncooperative.
> ---
>
> Some pros and cons relative to Poon-Dryja (LN-penalty) channels:
>
> - Requires more transactions in the worst-case: trigger, update,
> settlement. Compare to Poon-Dryja: commitment, claim.
> Decker-Russell-Osuntokun channels can be trigger-settlement but only
> in the degenerate case where the channel was never updated (indeed for
> implementation simplicity we might rather prefer to make an initial
> update transaction at the start, instead of starting with a
> trigger-settlement).
Actually the trigger can also be replaced in the cooperative case,
meaning that the settlement in that case is just a single transaction,
identical to LN-penalty. It is true that we've split the unilateral
commitment from LN-penalty into two transactions, but we removed the
need for a claim transaction, since funds directly go to the recipient
and we have no our_unilateral/to_us or their_unilateral/to_them delay
that needs to be sweeped (technically also not necessary, but all
implementation do that if I'm not mistaken). Even if funds are not
sweeped, the UTXO state is larger due to the bigger script that our
simple outputs for the settlement.
> - Dropping unilaterally onchain requires the party doing the drop to
> have some onchain funds it controls completely, since update
> transactions do not pay fees by themselves. We cannot have an
> autopilot that puts all onchain funds on channels, we need to reserve
> some small amount for paying fees of unilateral closes.
That is true, and I think this falls into the same category as the
reserve funds in the LN-penalty mechanism, i.e., funds that are there
but can't be used. There may be a clever way to build a penalty on top
of eltoo and then combine the fees and the penalties. Then again, a
misbehaving participant risking their on-chain fees for an outdated
update transaction may be a sufficient deterrent.
> + The above is counterbalanced by the fact that we can easily adjust
> onchain fees for update transactions, unlike the case for Poon-Dryja
> commitment transactions which once signed cannot have fees updated.
>
> = The onchain reserve (for paying fees for unilaterally dropped
> channels) is roughly equivalent to the channel reserve under
> Poon-Dryja; such a channel reserve no longer exists under
> Decker-Russell-Osuntukun channels, but is replaced by the onchain
> fee-paying reserve. Possibly the fee-paying reserve here might be
> feasibly smaller than the channel reserve under Poon-Dryja.
The one downside that this has is that the channel participants have
very little control over the fees that a misbehaving node may get
punished with. As one endpoint I can no longer impose an arbitrary
minimum loss in case of breach.
> - The CSV-encumberance on settlement transactions, which are the ones
> which carry the contracts in the channel, affects all
> absolute-timelocked contracts transported on the channel. Compare to
> Poon-Dryja, where commitment transactions themselves are unencumbered
> by CSV, and we simply insert the revocation to spends of the contracts
> being transported (i.e. the reason why we have HTLC-success and
> HTLC-timeout transactions in BOLT spec).
True, but as I argued in another mail, this is a fixed offset, that is
in the same range as today's CLTV deltas for some nodes. So for the
network of today using eltoo is roughly equivalent of adding another hop
to our path :-)
> + Like invalidation trees, we can use N-party funds rather than just
> 2-party funds (channels). We can even use M-of-N, so if there is at
> least some amount of trust you have with a group of entities (family,
> close friends, conglomeration partners, ZmnSCPxj, politicians...) it
> would be possible to have funds that require say only a majority of
> its owners to be updated.
The trust really comes down to a tradeoff between group size and
liveness: the bigger the group and the more churn you have in that
group, the less reliable the system becomes. Loss of liveness means that
the funds in the contract become unavailable for a know period of time.

2023-06-09 14:50:18 CEST

- reply

📅 Original date posted:2018-05-01
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Christian,
>
> This is very interesting indeed!
>
> I have started skimming through the paper.
>
> I am uncertain if the below text is correct?
>
>> Throughout this paper we will use the terms *input script* to refer to `witnessProgram` and `scriptPubKey`, and *output script* to refer to the `witness` or `scriptSig`.
>
> Figure 2 contains to what looks to me like a `witnessProgram`, `scriptPubKey`, or `redeemScript` but refers to it as an "output script":
>
>> OP_IF
>> 10 OP_CSV
>> 2 As Bs 2 OP_CHECKMULTISIGVERIFY
>> OP_ELSE
>> 2 Au Bu 2 OP_CHECKMULTISIGVERIFY
>> OP_ENDIF
>>
>> Figure 2: The output script used by the on-chain update transactions.
>
> Regards,
> ZmnSCPxj
Darn last minute changes! Yes, you are right, I seem to have flipped the
two definitions. I'll fix that up and push a new version.

2023-06-09 14:49:29 CEST

- reply

📅 Original date posted:2018-03-13
📝 Original message:
Hi René,
very good question. I think the simple answer is that this is exactly
the reason why not having a participant in the network that can 51%
attack over a prolonged period is one of the base assumptions in
Lightning. These attacks are deadly to all blockchains, and we are
certainly no different in that regard.
More interesting is the assertion that this may indeed be more dangerous
than a classical 51% attack, in which an attacker can only doublespend
funds that she had control over at some point during the attack
(duration being defined as the period she can build a hidden fork of). I
think the case for Lightning is not more dangerous since what they could
do is enforce an old state in which they had a higher balance than in
the final state, without incurring in a penalty. The key observation is
that in this old state they actually had to have the balance they are
stealing on the channel. So this maps directly to the classical
scenario in which an attacker simply doublespends funds they had control
over during the attack, making the attack pretty much the same.
Another interesting observation is that with Lightning the state that
the attacker is enforcing may predate the attack, e.g., an attacker
could use a state that existed and was replaced before it started
generating its fork. This is in contrast to the classical doublespend
attack in which invalidated spends have to happen after the fork
started, and the attacker just filters them from its fork.
But as I said before, if we can't count on there not being a 51%
attacker, then things are pretty much broken anyway :-)
Cheers,
Christian
René Pickhardt via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> writes:
> Hey everyone,
>
> disclaimer: as mentioned in my other mail (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html
> ) I am currently studying the revocation system of duplex micropayment
> channels in detail but I am also pretty new to the topic. So I hope the
> attack I am about to describe is not possible and it is just me overseeing
> some detail or rather my lack of understanding.
> That being said even after waiting one week upon discovery and double
> checking the assumptions I made I am still positive that the revocation
> system in its current form allows for a new form of a 51% attack. This
> attack seems to be way more harmful than a successful 51% attack on the
> bitcoin network. Afaik within the bitcoin network I could 'only double
> spend' my own funds with a successful 51% attack. In the lightning case it
> seems that an attacker could steal an arbitrary amount of funds as long as
> the attacker has enough payment channels with enough balance open.
>
> The attack itself follows exactly the philosophy of lightning: "If a tree
> falls in the forest and no one is around to hear it. Does it make a sound?"
> In the context of the attack this would translate to: "If a 51% attacker
> secretly mines enough blocks after fraudulently spending old commitment
> transactions and no one sees it during the the *to_self_delay* period,
> have the commitment transactions been spent? (How) Can they be revoked?"
>
>
> As for the technical details I quote from the spec of BOLT 3:
> "*To allow an opportunity for penalty transactions, in case of a revoked
> commitment transaction, all outputs that return funds to the owner of the
> commitment transaction (a.k.a. the "local node") must be delayed for *
> *to_self_delay** blocks. This delay is done in a second-stage HTLC
> transaction (HTLC-success for HTLCs accepted by the local node,
> HTLC-timeout for HTLCs offered by the local node)*"
>
> Assume an attacker has 51% of the hash power she could open several
> lightning channels and in particular accept any incoming payment channel
> (the more balance is in her channels the more lucrative the 51% attack).
> Since the attacker already has a lot of hash power it is reasonable (but
> not necessary) to assume that the attacker already has a lot of bitcoins
> and is well known to honest nodes in the network which makes it even more
> likely to have many open channels.
>
> The attacker keeps track of her (revocable) commitment transactions in
> which the balance is mostly on the attackers side. Once the attacker knows
> enough of these (old) commitment transactions the attack is being executed
> in the following way:
> 0.) The max value of to_self_delay is evaluated. Let us assume it is 72
> blocks (or half a day).
> 1.) The attacker secretly starts mining on her own but does not broadcasts
> any successfully mined block. Since the attacker has 51% of the hash power
> she will most likely be faster than the network to mine the 72 blocks of
> the safety period in which fraudulent commitment transactions could be
> revoked.
> 2.) The attacker spends all the fraudulent (old) commitment transactions in
> the first block of her secrete mining endeavor.
> 3.) Meanwhile the attacker starts spending her own funds of her payment
> channels e.g on decentralized exchanges for any other (crypto)currency.
> 4.) As soon as the attacker has mined enough blocks that the commitment
> transactions cannot be revoked she broadcasts her secretly minded
> blockchain which will be accepted by the network as it is the longest
> chain. (In Particular she includes all the other bitcoin transactions that
> are also in the original public blockchain so that other people don't even
> realize something suspicious has happened.)
>
> Since according to the spec channels should never be balanced worse than
> 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated
> in the sum of all payment channels the attacker was connected to. This
> amount could obviously be way higher than just double spending her own
> funds. This attack would be interesting in particular for the power nodes
> created by the Barabasi-Albert model of lnd's autopilot (c.f.:
> https://github.com/lightningnetwork/lnd/issues/677 ).
>
> I understand that with the growth of the bitcoin (mining) network a 51%
> attack becomes less and less likely. Also I am very happy to be proven
> false about the attack that I am describing.
>
> Another sad thing about this attack is that I currently do not see any
> (reasonable) way of preventing this form of a 51% attack (other than
> creating payment channels that don't offer the possibility of revocation)
> as it is abusing exactly the core idea of lightning to do something in
> secret without broadcasting it.
>
> Best regards Rene
>
> ---
>
> http://www.rene-pickhardt.de
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:49:04 CEST

- reply

📅 Original date posted:2018-02-12
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
> Can you give a use case for this?
>
> Usually, especially in the common case that a payment is done in
> exchange for some non-cryptographic asset (e.g. physical goods), there
> already is some kind of trust between payer and payee. So, if a payment
> is split non-atomically into smaller transactions, and only a part
> succeeds, presumably they can cooperatively figure out some way to
> settle the situation.
The scenario that is commonly used in these cases is a merchant that
provides a signed invoice "if you pay me X with payment_hash Y I will
deliver Z". Now the user performs the payment, learns the payment_key
matching the payment_hash, but the merchant refuses to deliver, claiming
it didn't get the payment. Now the user can go to a court, present the
invoice signed by the merchant, and the proof-of-payment, and force the
merchant to honor its commitment.

2023-06-09 14:48:49 CEST

- reply

📅 Original date posted:2018-02-05
📝 Original message:
Hi everyone
When we started drafting the specification we decided to postpone the
topology syncronization mechanism until we have a better picture of the
kind of loads that are to be expected in the network, e.g., churn and
update rate, and instead implement a trivial gossip protocol to
distribute the topology updates. This includes the dreaded initial
synchonization dump that has caused some issues lately to all
implementations, given that we dump several thousands of updates, that
may require block metadata (short channel ID to txid conversion) lookup
and a UTXO lookup (is this channel still active?).
During the last call we decided to go for an incremental improvement,
rather than a full synchronization mechanism (IBLT, rsync, ...). So
let's discuss how that improvement could look like.
In the following I'll describe a very simple extension based on a
highwater mark for updates, and I think Pierre has a good proposal of
his own, that I'll let him explain.
We already have the `initial_routing_sync` feature bit, which (if
implemented) allows disabling the initial gossip synchronization, and
onyl forwarding newly received gossip messages. I propose adding a new
feature bit (6, i.e., bitmask 0x40) indicating that the `init` message
is extended with a u32 `gossip_timestamp`, interpreted as a UNIX
timestamp. The `gossip_timestamp` is the lowest `channel_update` and
`node_announcement` timestamp the recipient is supposed to send, any
older update or announcement is to be skipped. This allows the `init`
sender to specify how far back the initial synchronization should go.
The logic to forward announcements thus follows this outline:
- Set `gossip_timestamp` for this peer
- Iterate through all `channel_update`s that have a timestamp that is
newer than the `gossip_timestamp` (skipping replaced ones as per BOLT
07)
- For each `channel_update` fetch the corresponding
`channel_announcement` and the endpoints `node_announcement`.
- Forward the messages in the correct order, i.e.,
- `channel_announcement`, then `channel_update`, and then `node_announcement`
The feature bit is even, meaning that it is required from the peer,
since we extend the `init` message itself, and a peer that does not
support this feature would be unable to parse any future extensions to
the `init` message. Alternatively we could create a new
`set_gossip_timestamp` message that is only sent if both endpoints
support this proposal, but that could result in duplicate messages being
delivered between the `init` and the `set_gossip_timestamp` message and
it'd require additional messages.
`gossip_timestamp` is rather flexible, since it allows the sender to
specify its most recent update if it believes it is completely caught
up, or send a slightly older timestamp to have some overlap for
currently broadcasting updates, or send the timestamp the node was last
connected with the network, in the case of prolonged downtime.
The reason I'm using timestamp and not the blockheight in the short
channel ID is that we already use the timestamp for pruning. In the
blockheight based timestamp we might ignore channels that were created,
then not announced or forgotten, and then later came back and are now
stable.
I hope this rather simple proposal is sufficient to fix the short-term
issues we are facing with the initial sync, while we wait for a real
sync protocol. It is definitely not meant to allow perfect
synchronization of the topology between peers, but then again I don't
believe that is strictly necessary to make the routing successful.
Please let me know what you think, and I'd love to discuss Pierre's
proposal as well.
Cheers,
Christian

2023-06-09 14:48:36 CEST

- reply

📅 Original date posted:2018-01-18
📝 Original message:
Mark Friedenbach <mark at friedenbach.org> writes:
> It is not the case that all instances where you might have negative
> fees would have loops.
If we don't have a cycle we can hardly talk about rebalancing
channels. At that point you're paying for someone else's payment to go
through your channel, and I'm unclear what the motivation for that might
be. Anyway, this is still possible by communicating this out of band
with the payment creator, and should not be baked into the gossip
protocol itself, in my opinion. It's obscure enough to not be worth the
extra effort.
> One instance where you want this feature is when the network becomes
> too weighted in one side of the graph.
There is little you can do to prevent this: if we have a network with a
small cut, with a source and sink on opposite sides of that cut, no
amount of voluntary sacrifice from the nodes along the cut will have a
lasting effect. The better solution would be to change the topology of
the network to remove the cut, or balance traffic over it, e.g., moving
a sink to the other side of the cut.
> Another is when the other side is a non-routable endpoint. In both
> cases would be useful to signal to others that you were willing to pay
> to rebalance, and this hand wavy argument about loops doesn’t seem to
> apply.
I'm not sure I understand what you mean with non-routable endpoint, so
correct me if I'm wrong. I'm assuming that non-routable endpoint is a
non-publicly announced node in the network? In that case no fee tricks
will ever get people to route over it, since they can't even construct
the onion to talk to it. Notice that the payment requests allow for
recipients of payments to get paid by explicitly including the necessary
information to construct the onion to talk to that node.
Not trying to be dismissive here, and I might be getting this wrong, so
let me know if I did and what use-cases you had in mind :-)
Cheers,
Christian

2023-06-09 14:48:36 CEST

- reply

📅 Original date posted:2018-01-17
📝 Original message:
Benjamin Mord <ben at mord.io> writes:
> It isn't obvious to me from the BOLTs if fees can be negative, and I'm
> finding uint in the go source code - which suggests not. In scenarios where
> the funding of a payment channel has been fully committed in one direction,
> why not allow negative fees to incent unwinding, in scenarios where nodes
> consider that cheaper than on-chain rebalancing?
After discussing this for a while we decided not to allow negative fees
in channel announcements (for now), because they actually do not add to
the flexibility and require special handling for route finding.
The main argument for negative fees has always been that they allow a
channel operator to rebalance its channels. However it is neither
required, nor is it really all that helpful. If a node wants to
rebalance he needs to find a cycle, that it can use to rebalance. The
simplest rebalancing is that the node itself sends a payment along that
cycle back to itself, giving the rebalancing node full control over the
amount to rebalance, timing and costs.
The negative fees were intended to encourage other participants to use
any cycle and rebalance for the node offering the negative fees. However
that results in less control over the rebalancing for the node, e.g.,
how many payments to incentivize, amounts, etc. This is compounded by
the inherent delay of channel updates being disseminated in the
network. So if a rebalancing node gets too many payments that try to
take advantage of the negative fees, what should it do? It'd result in
either losses for the node, or many forward rejections. So why not use
the funds one would have used towards negative fees for the active way
of rebalancing.
It is preferable to have payments be routed around an exhausted channel,
after all if there is a cycle there must be an alternative route, rather
than trying to artificially rebalance.
So overall, allowing only positive fees makes routing simpler, and still
allows for active rebalancing. As for other applications some have
alluded to, this constraint is only for the routing gossip. Should there
be a good reason to allow increasing the amount forwarded by a peer,
e.g., node n receives x from the previous hop and forwards x+e to the
next hop, that can still be negotiated out of band or even in the onion
payload for that node.
Cheers,
Christian

2023-06-09 14:48:13 CEST

- reply

📅 Original date posted:2017-12-30
📝 Original message:
Hi Andy,
just one minor point regarding your comparison with the bitcoin block
size: while the bitcoin block size is a consensus critical parameter
that cannot be modified without every participant agreeing, the capacity
limit is not consensus critical and can be changed at any point in
time. It can be negotiated by the two endpoints of a channel and no
other party is involved.
I quite like the comparison to training wheels, it's there as long as
you don't feel safe, and you can get rid of them once you're confidence
in the system and yourself increases :-)
Cheers,
Christian
Andy Schroder <info at AndySchroder.com> writes:
> Hello,
>
> Thanks for all of the discussion on this topic. In general, I don't have
> a solid opinion formed yet, but I understand all of the points that
> everyone has made. I think the bottom line is that a limit doesn't hurt
> right now unless the purchasing power of bitcoin dramatically declines.
> This limit is like the block size limit in that it is conservative and
> we need to have some experience in order to determine whether the limit
> is needed at all. It proved to be very clear over time that a block size
> limit was needed as one force against centralization. Maybe a limit is
> needed for lightning channels, maybe it isn't, but we need to first see
> how the network starts to evolve. My main concern long term is that a
> large business couldn't operate using lightning, because the channel
> sizes and payment sizes are too small. What if you're buying an oil rig,
> a locomotive, a gas turbine, a load of coal, or a herd of cattle. Should
> a blockchain transaction be used for everyone in the world for these
> types of purchases? But then again, maybe different types of users will
> use different kinds of lightning networks.
>
> Another reason against accepting large incoming channels yourself would
> be that you may not want to encourage people paying you to route through
> one of the super nodes. Super nodes are likely spies or targets of spies
> and users won't naturally want to deal with those types of actors.
>
> Also, the Eclair implementation supports push_msat too.
>
> Other than as "training wheels", I'm still not sure why we need a
> payment limit if we have a channel limit. It seems as though the channel
> limit puts an implicit payment limit in place.
>
> Andy Schroder
>
> On 12/27/2017 03:13 PM, ZmnSCPxj wrote:
>> Good morning Daniel,
>>
>>
>>
>>> -------- Original Message --------
>>> Subject: Re: [Lightning-dev] General questions about channels
>>> Local Time: December 27, 2017 10:30 PM
>>> UTC Time: December 27, 2017 2:30 PM
>>> From: therealsangaman at gmail.com
>>> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>> Andy Schroder <info at andyschroder.com>,
>>> lightning-dev at lists.linuxfoundation.org
>>> <lightning-dev at lists.linuxfoundation.org>
>>>
>>> I've only really been getting my hands into LN the past few weeks but
>>> I thought I'd share my thoughts here.
>>>
>>> ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org
>>> <mailto:lightning-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Perhaps some day, in the LONG TERM, the limits may be increased
>>>
>>>
>>> I was always under the impression that the channel and payment limits
>>> were intended to be training wheels, this is the first I've heard of
>>> them intended to stick around long term. I find the channel limit to
>>> be particularly restrictive, as it hinders some use cases I'd envision
>>> where large payment channels between two parties are useful and can
>>> also be used for routing LN payments. Large payments afaik can be
>>> broken up into smaller ones without incurring too much cost or
>>> trouble,
>>
>> Splitting up large payments would require multiple invoices at least
>> for now (whether this is troublesome or not may be a matter of
>> opinion, bit I suspect juggling more than a few invoices would be
>> painful as a user experience). Routing larger payments over multiple
>> routes automatically while using a single invoice, is harder as
>> multiple routes need to be set up, and each route must have different
>> preimages: further it is likely you want the entire large payment to
>> be done atomically, which would be harder to arrange.
>>
>>> but that's not the case for creating channels. As the channel
>>> itself involves only two parties - and in sticking to my general
>>> political/philosophical mantra - there is really no justification for
>>> limits to be imposed on this. Which brings me to my next point.
>>>
>>
>> Perhaps our definition of "long term" is askew. A year after mainnet
>> release, I doubt anyone would feel safe implementing removal of the
>> limit; this is my "long term". Five years, I imagine quite a few will
>> use the nonlimited version and may form a subnetwork among
>> themselves. But possibly by then it would be unlikely that most
>> people using Bitcoin at all would evem be capable of putting 150 mBTC
>> in spending money on a hot wallet, in which case whether there is a
>> 167 mBTC limit per channel or not is largely a moot point. Or perhaps
>> I simply imagine hyperbitcoinization by then, with people putting
>> entire bitcoins into hot wallets equivalent to people putting
>> thousands of USD today in their back pockets as invitation to be attacked.
>>
>>>
>>> There is also again the wisdom, that one should keep most of the
>>> funds in
>>> cold storage, and only a small amount for spending in hot wallets
>>> like
>>> Lightning nodes
>>>
>>>
>>> I think this is a top-down way of thinking that runs counter to the
>>> spirit of bitcoin. The "wisest" thing to do in fact may be to simply
>>> buy inflation-adjusted treasury bonds and not mess with bitcoin at
>>> all, much less the experimental lightning network. As advice this is
>>> perfectly fine to share with others for them to follow on a voluntary
>>> basis, but I don't see why this ought to be enforced as a rule on a
>>> protocol level.
>>>
>>
>> Possibly. At the protocol level, a limit encourages the growth of the
>> network towards a mesh network rather than more central forms,
>> however. I merely put this since it is unlikely that most people
>> following this "wisdom" would have an incentive to even run software
>> with the limit removed: that is, by the time Lightning becomes fully
>> deployed the limit may not even be reached in practice.
>>
>>>
>>> Also, I personally can't see a reason why a node would reject a large
>>> channel being made with it, where is the downside or risk? The party
>>> committing funds to the channel is the one risking loss or delay of
>>> funds.
>>>
>>
>> But the party committing funds to the channel is known via node
>> gossip, and it is known also who the other end of the channel is. If
>> you were to propose opening for example a 5BTC channel to me with the
>> funds coming from you, I would consider the possibility that I might
>> get attacked in order to get to your funds (and I might not have the
>> resources to protect against such an attack on my end, even if you
>> might). Further, putting 5BTC implies that at some point there is the
>> future possibility, due to routing and so on, that the channel will
>> have around 5BTC belonging to me, and at some point before you can
>> spend the entire 5BTC I would want to close the channel and commit the
>> funds that I now own into cold storage (so that the ability to channel
>> 5BTC from you to me is a moot point).
>>
>>
>> Regards,
>> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:48:11 CEST

- reply

📅 Original date posted:2017-12-28
📝 Original message:
Mark Friedenbach <mark at friedenbach.org> writes:
> Splitting a single payment into multiple invoices has bad semantic
> properties. Beyond implementation difficulties it also makes the
> payment no longer atomic. You can end up in a situation where part of
> a transaction has gone through but then channel capacity has been
> exhausted. The. What do you do?
We are indeed working on a solution for multipath payments, and they are
pretty simple to implement if the sender and recipient know how to
handle them. Re-use the same HTLC secret along all paths and the
atomicity is re-established. The only blocker is that it increases
complexity on the recipient, e.g., how do I tell whether the partial
payment is all I'll ever get, or whether there is more incoming, when do
I abort waiting, and similar concerns. That's the reason it didn't make
it into the v1.0 spec, but we are confident that it'll be added soon.
It is technically already possible to do so, if you hack together the
recipient node to wait for all parts of the payment before releasing the
secret. No need for multiple invoices.
> While an annoying (and potentially exploitable) edge case for
> payments, it also makes it basically impossible in practice to build
> higher level smart contracts on top of lightning channels as
> primitives, since those constructs typically use a single HTLC
> revelation as the decision gate between multiple contingent outcomes.
Absolutely, that's why we want to have the payment contingent on a
single secret, or on secrets that can be derived from one another.
> I had always assumed the protocol limits were training wheels, and
> would be shocked and dismayed if that were not the case (and would
> immediately begin work on an alternative fork because such limits
> would make lightning useless for my intended applications).
They are training wheels, we just decided for our own implementations
that we want to limit individual potential losses due to bugs. It is
trivial to change that on a per-channel level, and we have all the
pieces in place to perform an upgrade using the feature bits, no need to
fork lightning just yet :-) You just need to agree on using larger
amounts with your peer, on the peer layer, there is nothing preventing
the use of large channels in the multi-hop layer.
HTH,
Christian

2023-06-09 14:46:49 CEST

- reply

📅 Original date posted:2016-10-05
📝 Original message:
Hi everybody
The following blog post describes our recent use of an v0.5 C lightning
prototype, showcasing a completed transaction that included invoicing,
multi-hop payment, and item delivery. The included links provide additional
content and supporting code, as well as a short video. This will be going
live on Blockstream’s blog shortly.
Regards,
Rusty Russell
Dr. Christian Decker
Lightning First Strike: Christian Bought a Cat
Rusty Russell, October 5, 2016
https://blockstream.com/blog/
This story of feline acquisition begins with the demonstration of v0.5 of
the C lightning prototype, a lightning-fast micropayment system we've been
working on here at Blockstream (see
https://github.com/ElementsProject/lightning). To test the impending
prototype, we set up a web server to create invoices for test bitcoin
payments over the lightning network, and in return to offer a cat, or at
least an ASCII cat picture.
Dr. Christian Decker, another Blockstream developer working with me,
purchased the feline picture using 0.01 test bitcoin to open a lightning
channel with the server (see
http://tbtc.blockr.io/tx/info/c909f1fb5e971e32ae20e34cf6cf766f7237bfadf75aa6646a42063b9acba82b),
which was mined in test block 928335 (see
http://tbtc.blockr.io/block/info/928335). After a single confirmation, he
paid the invoice with a 100 satoshi transfer. Afterward, he accessed the
link to find his cat picture (see
http://128.199.80.48/?43744e221d794dcc0e61f8a757fa0346). He discovered it
was an ASCII picture, with a nice bonus. Two cats! Christian promptly
opened another node, connected to the first node, and bought a second copy
of the cat picture by routing through the previous node.
What Happened Behind The Scenes?
A Digital Ocean server runs Apache, bitcoind, and lightningd. When
accessed, a CGI script calls 'lightning-cli invoice 100000' to create an
invoice, which is presented to the user (see
https://github.com/rustyrussell/lightning-cat/blob/cc206788c552e2f7feb616170178c7ec38ccedb5/catsearch.sh).
The user clicks through a unique link, and if 'lightning-cli listinvoice'
indicates that the invoice was paid, the script presents the picture.
This is the first end-to-end test of a lightning micropayment network,
including invoicing, multi-hop payment, and item delivery. It is very
different from Acinq's recent simulation (see
http://www.coindesk.com/bitcoins-lightning-network-milestone-acinq-routing/)
of a lightning routing algorithm called Flare (See
http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf).
Their work shows how, by way of simple analogy, one can create a streetmap
to get from A to B in an efficient way, while the test we've demonstrated
here with v0.5 of the C lightning prototype has us actually walking that
path on the street.
What's Next?
We found a few bugs in corner cases and hit some known FIXMEs, but also
made lightningd more robust against misconfiguration. There are a few rough
edges that we'd still like to smooth and some documentation that we'd like
to write before the 0.5 release. Then, we want to create libraries to allow
web developers to play with constructing their own cat picture stores!
In the meantime, here's a short video that shows this working (see
https://asciinema.org/a/ergldrzd43j08klix08hf9yl3). The low production
value fits with the ASCII art.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161005/05e0db9d/attachment.html>

2023-06-07 20:23:36 CEST

- reply

📅 Original date posted:2020-03-26
📝 Original message:Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Regarding modification 1, I agree with ZmnSCPxj that
> Decker-Wattenhofer is your next best option, given that eltoo is not
> yet available. But if you are going to use a kickoff transaction, keep
> in mind that every previous owner will have a copy of it. Because of
> this, you can't include a fee, and will instead need to have a second
> output for CPFP. This way a previous owner will at least have to pay
> the fee if they want to publish it. Note that it's still an
> improvement, because even if the kickoff transaction gets posted, it
> basically becomes no different than what it would have been, had you
> not used a kickoff transaction at all.
It might be worth adopting the late fee binding we have in eltoo by
having the kickoff transaction input spending the funding tx signed with
sighash_single. This works because we only have 1 input and 1 output
that we really care about, and can allow others to attach fees at
will. That'd at least remove the need to guess the feerate days or
months in advance and thus having to overestimate.
> Regarding modification 2, I like it a lot conceptually. It hadn't
> occurred to me before, and it's a clear security improvement. The only
> question is something Greg Sanders mentioned: whether it's enough to
> justify the added complexity of using 2P ECDSA. The alternative would
> be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> possibly).
Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?
> I'm looking forward to seeing statechains become a reality.
That'd indeed be great :-)
Cheers,
Christian

2023-06-07 20:20:50 CEST

- reply

📅 Original date posted:2019-10-03
📝 Original message:ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> Good morning lists,
>
> Let me summarize concerns brought up:
>
> * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`.
> * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output.
>
> I propose the below instead:
>
> * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`.
> * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`.
>
> Then, on usage:
>
> * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence.
> * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`.
>
> This solves both concerns:
>
> * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it.
> * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`.
>
> Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy.
> But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me.
>
> Would this alternate proposal hold better muster?
Intriguing idea, this would be an invisible tagging, since the opt-in to
noinput and friends is hidden inside the committed script, which only
gets revealed whenever we actually need it.
For eltoo this would mean that the funding output would be invisibly
tagged, and the cooperative close would use the taproot pubkey, while
the uncooperative close, which would require noinput opt-in, reveals the
script, proving prior opt-in, and provides a matching signature.
If I'm not mistaken this would require AJ's alternative pubkey encoding
(0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?

2023-06-07 20:20:49 CEST

- reply

📅 Original date posted:2019-10-03
📝 Original message:Chris Stewart <chris at suredbits.com> writes:
> I do have some concerns about SIGHASH_NOINPUT, mainly that it does
> introduce another footgun into the bitcoin protocol with address reuse.
> It's common practice for bitcoin businesses to re-use addresses. Many
> exchanges [1] reuse addresses for cold storage with very large sums of
> money that is stored in these addreses.
>
> It is my understanding with this part of BIP118
>
>>Using NOINPUT the input containing the signature no longer references a
> specific output. Any participant can take a transaction and rewrite it by
> changing the hash reference to the previous output, without invalidating
> the signatures. This allows transactions to be bound to any output that
> matches the value committed to in the witness and whose witnessProgram,
> combined with the spending transaction's witness returns true.
>
> if an exchange were to once produce a digital signature from that cold
> storage address with a SIGHASH_NOINPUT signature, that signature can be
> replayed again and again on the blockchain until their wallet is drained.
> This might be able to mitigated since the signatures commit to outputs,
> which may be small in value for the transaction that SIGHASH_NOINPUT was
> used. This means that an exchange could move coins from the address with a
> larger transaction that spends money to a new output (and presumably pays a
> higher fee than the smaller transactions).
Thanks for sharing your concerns Chris, I do agree that noinput and
friends are a very sharp knife that needs to be treated carefully, but
ultimately it's exactly its sharpness that makes it useful :-)
> ### Why does this matter?
>
> It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
> protocols like Lightning. This gives us the building blocks for enforcing
> specific offchain states to end up onchain [2].
>
> Since this tool is useful, we can presume that it will be integrated into
> the signing path of large economic entities in bitcoin -- namely exchanges.
> Many exchanges have specific signing procedures for transactions that are
> leaving an exchange that is custom software. Now -- presuming wide adoption
> of off chain protocols -- they will need to have a _second unique signing
> path that uses SIGHASH_NOINPUT_.
>
> It is imperative that this second signing path -- which uses
> SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
> controls an exchanges onchain funds. If this were to happen, fund lost
> could occur if the exchange is reusing address, which seems to be common
> practice.
Totally agreed, and as you point out, BIP118 is careful to mandate
separate private keys be used for off-chain contracts and that the
off-chain contract never be mixed with the remainder of your funds. The
way eltoo uses noinput we selectively open us up to replay attacks
(because that's what the update mechanism is after all) by controlling
the way the transactions can be replayed very carefully, and any other
use of noinput would need to make sure to have the same guarantees.
However, once we have separated the two domains, we can simply use a
separate (hardened) derivation path from a seed key, and never mix them
afterwards. We never exchange any private keys, so even leaking info
across derived keys is not an issue here.
> This is stated here in BIP118:
>
>>This also means that particular care has to be taken in order to avoid
> unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
> used, unless it is explicitly needed for the application, e.g., it MUST NOT
> be a default signing flag in a wallet implementation. Rebinding is only
> possible when the outputs the transaction may bind to all use the same
> public keys. Any public key that is used in a NOINPUT signature MUST only
> be used for outputs that the input may bind to, and they MUST NOT be used
> for transactions that the input may not bind to. For example an application
> SHOULD generate a new key-pair for the application instance using NOINPUT
> signatures and MUST NOT reuse them afterwards.
>
> This means we need to encourage onchain hot wallet signing procedures to be
> kept separate from offchain hot wallet signing procedures, which introduces
> more complexity for key management (two keychains).
This is already the case: off-chain systems always require access to the
signing key in real-time in order to be useful. If any state change is
performed in a channel, even just adjusting fees or receiving a payment,
requires the signature from the key associated with the channel. With
high security on-chain systems on the other hand you should never have a
hot key that automatically signs off on transfers without human
intervention. So I find it unlikely that mandating the on-chain keys to
be kept separate from off-chain keys is any harder than what should be
done with the current systems.
> One (of the few) upsides of the current Lightning penalty mechanism is that
> fund loss can be contained to balance of the channel. You cannot do
> something in the current protocol that will effect your funds outside of
> that channel. With SIGHASH_NOINPUT, that property changes.
Good point, but if the key hygiene is maintained as detailed in BIP118,
i.e., off-chain keys must be kept separate from on-chain keys, and that
each off-chain contract instance uses a separate set of keys, that
property is maintained.
Regards,
Christian

2023-06-07 20:15:45 CEST

- reply

📅 Original date posted:2018-12-20
📝 Original message:Johnson Lau <jl2012 at xbt.hk> writes:
> Correct me if I’m wrong.
>
> For the sake of simplicity, in the following I assume BIP118, 143, and
> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible
> optimisations.
>
> 1. A and B are going to setup a channel.
>
> 2. They create one setup tx, with a setup output of the following
> script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
If we are using a trigger transaction the output of the setup
transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV
in there we would not have an option to later attach a collaborative
close transaction that is valid immediately. Furthermore the timeout of
the CLTV would start ticking down the exact moment the setup transaction
is confirmed, hence whatever effect we are trying to achieve with that
timelock is limited, and we have a limit to the total lifetime of the
channel.
> 3. They create the update tx 0, spending the setup output with NOINPUT
> and locktime = s+1, to the update-0 output with the script: IF 2 As0
> Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
Update 0 is usually what I call the trigger transaction. It takes the
2-of-2 multisig from the setup transaction and translates it into the
two-branch output that further updates or settlements can be attached
to. The settlement transaction attached to the trigger / update 0
reflects the initial state of the channel, i.e., if A added 2 BTC and B
added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1
respectively, with the user's keys (this can also be considered the
refund in case of one party disappearing right away).
The second branch in the script you posted is the update branch, which is
not encumbered by a CSV, while the first branch is the one encumbered
with the CSV and is called the settlement branch since we'll be
attaching settlement txs to it.
The CLTV looks correct to me and ensures that we can only attach any
state >= s+1.
So just to show the output script for state `i` how I think they are
correct:
```
OP_IF
<timeout> OP_CSV 2 <As_i> <Bs_i> 2 OP_CHECKMULTISIG
OP_ELSE
<s+1> OP_CLTV OP_DROP 2 <Au> <Bu> 2 OP_CHECKMULTISIG
```
And the input scripts for the update tx and the settlement tx
respectively would be:
```
OP_FALSE <Sig_Bu> <Sig_Au>
```
and
```
OP_TRUE <Sig_Bs_i> <Sig_As_i>
```
> 4. They create the settlement tx 0, spending the update-0 output with
> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH
equivalent) since segwit witnesses only allow pushes. Hence the script
in point 3 needs to add that :-)
> 5. They sign the setup tx and let it confirm
They also need to sign (but not broadcast) update_0, in order to allow
either party to initiate the closure if the counterparty become
unresponsive. The order in which settlement_0 and update_0 are signed is
not important by the way, so we can just batch these. The important part
is that signing the setup acts as a commitment.
> 6. To update, they create the update tx 1, spending the setup output
> with NOINPUT and locktime = s+2, to the update-1 output with the
> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2
> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the
> update-1 output with As1 and Bs1 using relative-locktime, with 2
> settlement outputs
The output script of the updates are identical to the ones in the
trigger or update_0 transaction, so they'd also need a CSV (this is why
committing to the script structure with masking still works).
> 7. To close the channel, broadcast update tx 1. Wait for several
> confirmations. And broadcast settlement-tx-1
We have to differentiate 2 cases: collaborative close and unilateral
close. In the collaborative close we come to a mutual agreement that
we'd like to take this latest state and settle. So we create a new
transaction that spends the setup output, and add outputs according to
the state we agreed upon, and we sign it. This transaction is
immediately valid, and does not need to be signed with NOINPUT. So all
the chain sees is a setup transaction with some inputs and one multisig
output (singlesig with Schnorr) and a collaborative close transaction
that spends the setup (also not signed with NOINPUT). About as normal as
transactions in Bitcoin can get.
In the unilateral case, one party isn't there anymore, or refuses to
sign. So we take the trigger transaction (not signed with NOINPUT) and
the latest update_n transaction (signed with NOINPUT) and broadcast
them. Then we wait for the CSV timeout to expire, and then send the
settlement transaction, which gives us the enforcement of the latest
state that we agreed on. The chain sees a setup transaction and a
trigger transaction (normal transactions for all intents and purposes,
except for the output script of the trigger, but we can hide that with
taproot), followed by two more transactions which are signed with
NOINPUT. So 4 transactions in the worst case, of which 2 are special,
and 2 transactions in the good case.
So all in all I think it's a tradeoff between having a larger on-chain
footprint (4 txs vs 3 txs in the worst case) and putting a fixed
lifetime on the channel for the refund case if one party disappears
right away. We'll probably find out what acceptable parameters are for
these and where the cutoff points are :-)

2023-06-07 20:15:44 CEST

- reply

📅 Original date posted:2018-12-19
📝 Original message:Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Hi Johnson,
>
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].
>
>>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?
I'm not aware of a way to combine the setup and trigger transaction. The
trigger transaction was introduced in order to delay the start of the
timeouts until a later time, to avoid having an absolute lifetime limit
and having really huge timeout. If we were to combine the trigger
transaction with the setup transaction (which is broadcast during
channel creation), all of those timeouts would start counting down
immediately, and we could just skip the trigger transaction
altogether. It'd be more interesting to combine update and trigger
transactions in a sort of cut-through combination, but that doesn't seem
possible outside of Mimblewimble.
Cheers,
Christian

2023-06-07 20:15:17 CEST

- reply

📅 Original date posted:2018-11-23
📝 Original message:Anthony Towns <aj at erisian.com.au> writes:
> Commiting to just the sequence numbers seems really weird to me; it
> only really prevents you from adding inputs, since you could still
> replace any input that was meant to be there by almost any arbitrary
> other transaction...
It's a really roundabout way of committing to the inputs, I
agree. I'm actually wondering if it makes sense to correct that
additional blanked field in BIP118 at all since it seems there is no
real use-case for NOINPUT that doesn't involve blanking the
`hashSequence` as well.
> I could see this *maybe* making sense if you at least committed to the
> values of each input's outpoint; since that would be an actual constraint?
BIP118 still commits to the value of the input being spent, i.e.,
6. value is not being blanked in the current proposal. This is on
purpose since we commit to the outputs, not committing to the input
values could end up with unexpected fees.
>> As for your proposal, I really like the `sighash_scriptmask` proposal,
>> and committing to the fees (with the `nofee` escape hatch) also works
>> seems also a nice fix. My one concern is that introducing a new opcode
>> to mask things in the sighash looks like a similar layering violation as
>> `codeseparator` was, but that's just a minor issue imho.
>
> I think OP_MASK is okay as far as layering goes, if you just think of it
> as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
> pseudocode a script like:
>
> <n> OP_CSV OP_DROP <p> OP_CHECKSIG
>
> and then decide <n> needs to be masked, you rewrite it as:
>
> [n] OP_CSV OP_DROP <p> OP_CHECKSIG
>
> indicating n is masked, and don't worry about the exact bytes that will
> encode the push, anymore than you currently worry about whether it's
> OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.
>
> As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
> not to be immediately followed by that PUSH, I think that all works
> out fine.
Agreed, that makes more sense :-)

2023-06-07 20:15:16 CEST

- reply

📅 Original date posted:2018-11-21
📝 Original message:Hi Pieter,
great proposal, I think this may address some of the (perceived)
downsides of BIP118, by committing to the script when possible
(always?). One minor thing that I noticed a while ago and that I meant
to fix on BIP118 is that `hashSequence` does not need to be blanked for
eltoo to work (since where it is needed we also use `sighash_single`),
so I'm tempted to remove that redundant blanking. It may not make a lot
of difference but it'd limit the ability to change the number of inputs
to a NOINPUT transaction (this now being the only field that commits to
the set of inputs).
As for your proposal, I really like the `sighash_scriptmask` proposal,
and committing to the fees (with the `nofee` escape hatch) also works
seems also a nice fix. My one concern is that introducing a new opcode
to mask things in the sighash looks like a similar layering violation as
`codeseparator` was, but that's just a minor issue imho.
Cheers,
Christian
Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Hello everyone,
>
> For future segwit versions, I think it would be good add a few things
> to the sighash by default that were overlooked in BIP143:
> * Committing to the absolute transaction fee (in addition to just the
> amount being spent in each input) would categorically remove concerns
> about wallets lying about fees to HW devices or airgapped signers.
> * Committing to the scriptPubKey (in addition to the scriptCode) would
> prevent lying to devices about the type of output being spent, even
> when the scriptCode is correct. As a reminder, the scriptCode is the
> actually executed script (which is the redeemscript in non-segwit
> P2SH, and the witnesscript in P2WSH/P2WPKH).
>
> As this implies additional information that may not be desirable to
> commit to in all circumstances, it makes sense to make these optional.
> This obviously interacts with SIGHASH_NOINPUT, which really adds two
> different ways of rebinding signatures to inputs:
> * Changing the prevout (so that the txid doesn't need to be known when
> the signature is created)
> * Changing the script (so that the exact scriptPubKey/redeemScript/...
> doesn't need to be known when the signature is created)
>
> Of course, the second implies the first, but do all use cases require
> both being able to change the prevout and (arbitrarily) changing the
> scriptPubKey? While BIP118 correctly points out this is secure if the
> same keys are only used in scripts with which binding is to be
> permitted, I feel it would be preferable if signatures/scripts would
> explicitly state what can change. One way to accomplish this is by
> indicating exactly what in a script is subject to change.
>
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> and SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, but:
> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> the subsequent opcode/push is removed.
> * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
> * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:15:16 CEST

- reply

📅 Original date posted:2018-11-21
📝 Original message:Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> Given this implementation, NOINPUT effectively implies ANYONECANPAY,
> I think. (I think that is also true of BIP 118's NOINPUT spec)
I mentioned this in my reply to Pieter, but this may not be true if we
remove the blanking of the `hashSequence` field. Anyonecanpay would
allow changing the number of inputs in an arbitrary fashion, while
`noinput` without the blanking would (in a weird roundabout way) still
commit to the number of inputs. Maybe we want to make that more explicit
by also hashing the number of inputs? But I can't think of a good
usecase for keeping that, with noinput.
Cheers,
Christian

2023-06-07 20:11:42 CEST

- reply

📅 Original date posted:2018-04-30
📝 Original message:(cross-posting to bitcoin-dev since this serves as motivation behind the
sighash_noinput proposal)
> TL;DR: we announce a new, simple, update mechanism for off-chain protocols,
> see the announcement [1] and the paper [2] :-)
A little over a year ago, the three Lightning Network implementation
teams joined forces to work on a common specification for the protocol
stack. Now that both that specification and our three implementations
are becoming stable and usable, it is time to look forward: to further
improve the protocol, to add new features, to simplify, and to fix
downsides.
One of the core innovations that enabled Lightning in the first place was an
off-chain update mechanism to renegotiate a new state and ensure that the old
state can not be settled on-chain. Today, we're excited to release our latest
research paper on a new, simplified, update mechanism for layer 2 protocols,
called eltoo.
eltoo is a drop-in replacement for the penalty based invalidation
mechanism that is used today in the Lightning specification. It is
similar in many ways to the sequence number mechanism that was already
present in the original Bitcoin implementation. But, while sequence
numbers were unenforceable on the blockchain, eltoo is enforceable by
overriding subsequent states on-chain.
Unlike the current mechanism used in Lightning so far, it is not penalty
based, i.e., publishing an old state does not result in the faulty node
to automatically lose funds, and is most similar to the duplex
micropayment channels construction. It is a symmetric scheme, i.e., all
participants share an identical set of transactions, and it ensures that the
last agreed upon state is settled on-chain, with similar tradeoffs as
today's Lightning (timelock vs. online requirement).
eltoo addresses some of the issues we encountered while speficying and
implementing the Lightning Network. For example outsourcing becomes very
simple since old states becoming public can't hurt us anymore. We
completely remove the need to estimate fees ahead of time. The
construction allows us to attach fees when settling, and even allows for
fees to be bumped using CPFP or RBF.
Beyond Lightning, eltoo can be used as a generic update mechanism for an
off-chain contract, for a larger number of participants. This was not
possible in the current update mechanism since reactions to a
misbehaving participant needed to be tailore to that participant. This
enables other protocols such as the channel factories, and in
combination with Schnorr signatures allows for very large off-chain
contracts with minimal on-chain footprint.
Before we can implement eltoo, we need a minor change to Bitcoin: the
introduction of the SIGHASH_NOINPUT flag for signatures. This was first
discussed a few months ago in the context of watchtowers to help secure
Lightning channels, but was not formally proposed. A formal proposal may
now be found in the eltoo paper.
We invite the community to consider our proposal and to participate in
its discussion. We hope to arrive at a consensus for the usage of
SIGHASH_NOINPUT, so that it can be accepted and included in a future
soft fork of Bitcoin Script. Doing so will put us on the road to a more
reliable and simpler Lightning Network, incorporating a new update
mechanism that can also be used for many other applications.
The full official announcement can be found at [1] and the paper with the full
details can be found at [2].
Looking forward to the communities feedback,
Christian
[1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[2] https://blockstream.com/eltoo.pdf

2023-06-07 19:55:10 CEST

- reply

📅 Original date posted:2017-01-05
📝 Original message:On Wed, Jan 04, 2017 at 11:45:18PM -0800, Eric Voskuil via bitcoin-dev wrote:
> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
> > The best way is to connect to the mempool of each miner and check to
> > see if they have your txid in their mempool.
> >
> > https://www.antpool.com/api/is_in_mempool?txid=334847bb...
> > https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> > https://bw.com/api/is_in_mempool?txid=334847bb...
> > https://bitfury.com/api/is_in_mempool?txid=334847bb...
> > https://btcc.com/api/is_in_mempool?txid=334847bb...
> >
> > If each of these services return "True", and you know those services
> > so not engage in RBF, then you can assume with great confidence that
> > your transaction will be in the next block, or in a block very soon.
> > If any one of those services return "False", then you must assume that
> > it is possible that there is a double spend floating around, and that
> > you should wait to see if that tx gets confirmed. The problem is that
> > not every pool runs such a service to check the contents of their
> > mempool...
> >
> > This is an example of mining centralization increasing the security of
> > zero confirm.
>
> A world connected up to a few web services to determine payment validity
> is an example of a bitcoin security catastrophe.
>
> e
>
And it's a great way to tell every miner who you are and what
transactions you are sending/receiving. An absolute privacy
nightmare...
-- cdecker

2023-06-07 19:43:45 CEST

- reply

📅 Original date posted:2015-10-22
📝 Original message:Indeed the reason I got started with all of this is the use of normalized
transaction IDs within smart contracts with multiple signers. Sorry if I
was perceived as overselling it :-)
So to summarize the discussions that have been on-going here as well as in
the PR so far, most people seem to agree that the BIP is an improvement for
smart-contracts as well as the third-party modification scenario. It comes
at the cost of increased UTXO size due to the additional hash being stored
per transaction with unclaimed outputs and some additional computations.
The additional computation is for the normalized ID computation and the
swapping in of normalized IDs during verification. No additional coin
lookups are needed as they are retrieved and cached anyway when verifying
the transaction. Would everybody agree with this assessment so far?
On the PR there were some additional suggestions of treating singlesig
transactions as 1-of-1 transactions and using Schnorr signatures for the
new opcode. Schnorr has been in the works for a long time and gives a
multitude of advantages, e.g., batch validation, and seems like a good
addition. Since the verify flag is mandatory due to the soft-fork migration
and we might merge singlesig and multisig into a single opcode we can
replace the bitmap of flags with a simple version number. Clients would
fall back to OP_NOP behaviour for versions they do not implement,
maintaining soft-fork semantics to build more future signing and
verification methods.
On Thu, Oct 22, 2015 at 10:57 AM Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Normalized transaction IDs do help in the case that the single signer
> wants
> > to immediately follow up its transaction with another transaction
> spending
> > the first one's change output, and it prevents any modification in the
> > multi-signer scenario.
>
> For ordinary transactions which are not performing interesting smart
> contracts that particular is better addressed via canonical encoding,
> which is immediately available and doesn't have the associated costs
> (new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
> to fixup txid references, etc.).
>
> Please, as I said up-thread: this is good and importantstuff to work
> on, but it shouldn't be oversold.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/f94cd31f/attachment.html>

2023-06-07 19:43:43 CEST

- reply

📅 Original date posted:2015-10-21
📝 Original message:Hm, that is true as long as the signer is the only signer of the
transaction, otherwise he'd be invalidating the signatures of the other
signers. That can however be fixed by having a canonical ordering of Inputs
and Outputs, which has been discussed before in order to decrease
information that can be gained about the spender. Maybe we can defer to
that effort?
On Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr <luke at dashjr.org> wrote:
> On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke at dashjr.org> wrote:
> > > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at dashjr.org> wrote:
> > > > > This doesn't completely close malleability (which should be
> > > > > documented
> > >
> > > in
> > >
> > > > > the BIP), so I'm not sure it's worth the cost, especially if
> closing
> > > > > malleability later on would need more. How about specifying flags
> > >
> > > upfront
> > >
> > > > > in the UTXO-creating transaction specifying which parts the
> signature
> > > > > will cover? This would allow implementation of fully
> > > > > malleability-proof wallets.
> > > >
> > > > As far as I see it the only remaining venues for malleability are the
> > > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the
> > > > BIP. Any
> > >
> > > use
> > >
> > > > of non-sighash_all flags is already an explicit permission to modify
> > > > the transactions, by adding and removing inputs and outputs, so I
> > > > don't see
> > >
> > > how
> > >
> > > > these can be made non-malleable. Am I missing something?
> > >
> > > Signer malleability is still a notable concern needing consideration.
> > > Ideally,
> > > wallets should be trying to actively CoinJoin, bump fees on, etc any
> > > pending
> > > transactions in the background. These forms of malleability affect
> nearly
> > > as
> > > many real use cases as third-party malleability.
> > >
> > > Luke
> >
> > How is signer malleability still a problem if we remove the signatures
> from
> > the transaction ID of the transaction and all preceding transactions? The
> > signer can re-sign a transaction but it won't change the transaction ID.
>
> The signer can also change the order of the inputs, the inputs themselves,
> add/remove outputs, etc... all which should be possible without becoming a
> different logical transaction. The only unique property of the logical
> transaction is the scriptPubKey/address.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/c06fc8ff/attachment.html>

2023-06-07 19:43:43 CEST

- reply

📅 Original date posted:2015-10-21
📝 Original message:On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke at dashjr.org> wrote:
> On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at dashjr.org> wrote:
> > > This doesn't completely close malleability (which should be documented
> in
> > > the BIP), so I'm not sure it's worth the cost, especially if closing
> > > malleability later on would need more. How about specifying flags
> upfront
> > > in the UTXO-creating transaction specifying which parts the signature
> > > will cover? This would allow implementation of fully malleability-proof
> > > wallets.
> >
> > As far as I see it the only remaining venues for malleability are the use
> > of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any
> use
> > of non-sighash_all flags is already an explicit permission to modify the
> > transactions, by adding and removing inputs and outputs, so I don't see
> how
> > these can be made non-malleable. Am I missing something?
>
> Signer malleability is still a notable concern needing consideration.
> Ideally,
> wallets should be trying to actively CoinJoin, bump fees on, etc any
> pending
> transactions in the background. These forms of malleability affect nearly
> as
> many real use cases as third-party malleability.
>
> Luke
>
How is signer malleability still a problem if we remove the signatures from
the transaction ID of the transaction and all preceding transactions? The
signer can re-sign a transaction but it won't change the transaction ID.
It is still possible to double-spend transactions that do not have enough
fees, so just starting a new round of CoinJoin is sufficient to bump fees
for all parties that participate, and that would also result in the
double-spent low fee transaction to be discarded, resolving the state of
all coins in the first CoinJoin tx.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/87444434/attachment.html>

2023-06-07 19:43:42 CEST

- reply

📅 Original date posted:2015-10-21
📝 Original message:On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at dashjr.org> wrote:
> On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev
> wrote:
> > The proposal is implemented (see below), by computing the normalized
> > transaction ID when adding them to the UTXO and storing them along with
> the
> > coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> > OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> > how to best refactor the common functionality into reusable blocks. And
> the
> > annotating incoming transactions with their normalized inputs is a bit
> > cumbersome, maye somebody has some pointers here as well?
> This doesn't completely close malleability (which should be documented in
> the
> BIP), so I'm not sure it's worth the cost, especially if closing
> malleability
> later on would need more. How about specifying flags upfront in the UTXO-
> creating transaction specifying which parts the signature will cover? This
> would allow implementation of fully malleability-proof wallets.
>
As far as I see it the only remaining venues for malleability are the use
of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use
of non-sighash_all flags is already an explicit permission to modify the
transactions, by adding and removing inputs and outputs, so I don't see how
these can be made non-malleable. Am I missing something?
>
> Additionally, you have a flag to control whether the opcode behaves as
> VERIFY
> or not. Non-VERIFY is not possible as a softfork (without doing a
> second/new
> P2SH) since it can be negated.
>
Yes, this is my mistake and has been pointed out in the PR, I will amend
the PR to make the verify flag mandatory, which also guarantees that the
top of the stack contains a non-null element, thus resulting in a
successful evaluation on non-updated clients.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3a229156/attachment.html>

2023-06-07 19:43:41 CEST

- reply

📅 Original date posted:2015-10-19
📝 Original message:Yes, this has been pointed out in the PR as well. Transactions inputs must
also be normalized by replacing malleable hashes with the normalized
hashes. I will fix the spec and the implementation to reflect this :-)
Regards,
Christian
On Mon, Oct 19, 2015 at 5:24 PM Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As with the previous version, which was using a hard-fork, the normalized
>> transaction ID is computed only considering the non-malleable parts of a
>> transaction, i.e., stripping the signatures before computing the hash of
>> the transaction.
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> Is this proposal recursive?
>
>
> *Coinbase transaction *
>
> * n-txid = txid
>
>
> *Non-coinbase transactions*
> * replace sigScripts with empty strings
> * replace txids in TxIns with n-txid for parents
>
> The 2nd step is recursive starting from the coinbases.
>
> In effect, the rule is that txids are what they would have been if n-txids
> had been used right from the start.
> _______________________________________________
> 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/20151019/5df79d73/attachment.html>

2023-06-07 19:43:41 CEST

- reply

📅 Original date posted:2015-10-20
📝 Original message:On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So what exactly is used to create the normalized txid (sha256 hash of
> what data)? I've read in the linked BIP draft that it will strip the
> 'malleable parts' but didn't understand what exactly will be used to
> calculate the normalized transactions ids and how will the change apply
> retro-active for the transactions so deep buried in the blockchain?
>
The normalization involves two steps:
- strip the scriptSig scripts in the inputs, i.e., the only part whose
integrity is not guaranteed by the signature itself, by replacing the
scripts with empty strings (var length string of size 0)
- replace the hashes referencing the outputs being spent with the
normalized hashes of the transaction that created the outputs. This is done
recursively down to the first v2 transactions.
The second part is not yet explained in the draft, but I will amend it as
soon as possible.
> Pubkeys (addresses) can be reused infinitely so what guarantees us
> unique normalized txids all the time and protection against replay
> attacks? The question is not if this issue is covered or not, I know it
> is, I am just asking how, in simpler terms.
>
Non-coinbase transactions can still not be replayed since the normalized
transaction still includes a the normalized transaction hashes of claimed
outputs, hence any attempt to replay a transaction would fail since the
outputs were already spent. For coinbase transactions it is indeed possible
that we create multiple transactions with the same hash (only one of which
would be spendable), hence we do not strip coinbase transactions and rely
on BIP 34 to make the coinbase transactions unique (except for blocks 91842
and 91880 which are the reason we introduced BIP 34 in the first place).
Clarifying the way the normalized transaction ID is computed should remove
any ambiguities I hope.
>
> SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.
>
> Will it also fix > third level malleability (a tx which spends from
> another unconfirmed tx which spends from yet another unconfirmed tx)?
>
Yes, if the computation of the normalized transaction ID includes replacing
input hashes with their normalized counterpart makes a chain of any depth
non-malleable.
HTH,
Christian
>
>
> On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote:
> > On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > As with the previous version, which was using a hard-fork, the
> > normalized transaction ID is computed only considering the
> > non-malleable parts of a transaction, i.e., stripping the signatures
> > before computing the hash of the transaction.
> > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
> >
> > Is this proposal recursive?
> >
> > *Coinbase transaction
> > *
> >
> > * n-txid = txid
> >
> > *Non-coinbase transactions
> > *
> > * replace sigScripts with empty strings
> > * replace txids in TxIns with n-txid for parents
> >
> > The 2nd step is recursive starting from the coinbases.
> >
> > In effect, the rule is that txids are what they would have been if
> > n-txids had been used right from the start.
> >
> >
> _______________________________________________
> 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/20151020/2655d737/attachment.html>

2023-06-07 19:43:40 CEST

- reply

📅 Original date posted:2015-10-19
📝 Original message:After spending some more time on the normalized transaction ID proposal and
reworking it to be a soft-fork (thanks sipa for helping me figuring out
how), I'd like to propose the BIP again.
As with the previous version, which was using a hard-fork, the normalized
transaction ID is computed only considering the non-malleable parts of a
transaction, i.e., stripping the signatures before computing the hash of
the transaction. This ensures that if a transaction is modified, either by
a third party fishing transactions from the network and re-injecting
modified versions or by one of the signers re-signing it, any transaction
that builds on top of it still remains valid. Furthermore it allows the use
of template transactions, unsigned transactions upon which further
transaction can be built before signing the template transaction and
locking the contract.
Unlike the previous proposal, this is a softfork proposal that redefines
OP_NOP4 with an extensible and parameterized version of the signature
checking opcodes, called OP_CHECKSIGEX. Among other things the parameters
allow to specify that an output with an OP_CHECKSIGEX is to be referenced
by the normalized transaction ID that created it, instead of the instance
transaction ID containing malleable signatures. This BIP uses the
normalized transaction IDs exclusively while signing or checking
signatures, they are not used in any network level message as the previous
version would have done, hence there is no change at network level and old
clients should be able to exchange transactions as before and blocks still
reference the transaction instances.
The proposal is implemented (see below), by computing the normalized
transaction ID when adding them to the UTXO and storing them along with the
coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
how to best refactor the common functionality into reusable blocks. And the
annotating incoming transactions with their normalized inputs is a bit
cumbersome, maye somebody has some pointers here as well?
BIP Pull request: https://github.com/bitcoin/bips/pull/224
Implementation: https://github.com/cdecker/bitcoin/commits/normtx
I think in the discussion of my previous proposal, most of you welcomed the
introduction of normalized transaction IDs, were it not for the hardfork. I
hope this proposal adresses the previous concerns and that we can move
forward in adding the normalized transaction IDs to the bitcoin protocol.
That being said, I'm always open to suggestions :-)
Regards,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151019/2ed7395d/attachment-0001.html>

2023-06-07 17:48:55 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:I hacked together a simple tracking page for the 'block votes', it
currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for
generic size:
http://bitcoinstats.com/network/votes/
On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Nicolas,
>
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
> >> A visualization I would like to see would include:
> >
> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
> >> sipa
> > etc) based on what's published in blocks.
> >
> > If such a vote existed, I would gladly show the pie on BIPxDevs.
> > However there is no standard way for miners to vote informally BIP
> > they support.
>
> What about formal votes? Is there a way to visually have them appear
> in a pie chart as the votes become apparent in blocks?
>
> I appreciate good visualizations and am trying to get a (visual)
> comparison of the votes on these competing proposals.
>
> >
> >
> >
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
> =AHv3
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150821/4a0ebce0/attachment.html>

2023-06-07 17:09:57 CEST

- reply

📅 Original date posted:2013-11-24
📝 Original message:Since this came up again during the discussion of the Cornell paper I
thought I'd dig up my measurement code from the Information
Propagation paper and automate it as much as possible.
The result is the Network Propagation page on bitcoinstats.com
(http://bitcoinstats.com/network/propagation/). It takes a daily
snapshot of the situation, then calculates the time until blocks and
transactions reach a certain percentile of the nodes in the network.
There is also a detailed page showing the density function describing
at what times nodes learn about the existence of a block/transaction
(for example yesterdays distribution:
http://bitcoinstats.com/network/propagation/2013/11/23).
I intend to add more information and plots over time, but I wanted to
push this out quickly as there were some people asking for it. Hope
this helps getting the blockchain fork rate down :-)
Regards,
Chris
--
Christian Decker

2023-06-07 12:09:52 CEST

- reply

📅 Original date posted:2012-05-25
📝 Original message:How about a simple proof of work test? This one though does not ask for CPU
work but asks the miner for a random old transaction. If the miner really
stores the entire blockchain he will not have any problem answering to that
getdata request, whereas a botnet would have to ask someone else for it,
which could be detected if the response time deviates too much from what
has been previously measured (compare it against getdata for the block they
advertise). It's not perfect but it allows an estimate of whether it is a
chainless miner.
Regards,
Chris
--
Christian Decker
On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
> > Block times are not accurate enough for that.
>
> The times in your log are very accurate, assuming your system clock is
> remotely accurate.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/a927acc7/attachment.html>

2023-06-07 04:50:45 CEST

- reply

📅 Original date posted:2011-12-22
🗒️ Summary of this message: Using negative announces in Bitcoin may lead to a DoS attack if a malicious node triggers verification for every transaction.
📝 Original message:At first the idea of using negative announces seems attractive, but
remember that a malicious node might trigger verification for every
transaction, which may lead to a DoS.
Regards,
Chris
On Thu, Dec 22, 2011 at 1:14 PM, Joel Joonatan Kaartinen <
joel.kaartinen at gmail.com> wrote:
> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > Why should they have to? Joining the network as a node is very low cost
> to
> > the other nodes. You can't force any node not to be lazy, since their
> option
> > is to disconnect themselves. As to maliciousness, that is defended
> against
> > because when a node negative announces a transaction, that transaction is
> > going to be checked (note that there is still no implicit trust) -- if a
> node
> > is incorrectly negative-announcing then it can justifiably be kicked.
>
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.
>
> - Joel
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/8c9c7828/attachment.html>

2023-06-07 04:50:26 CEST

- reply

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Supernodes will verify transactions and be owned by miners. A hierarchical network will form with miners/supernodes at the top and lightweight clients at the bottom. DHTs may be used for block storage, but IP addresses should be used with caution. Broadcasting transactions may not be necessary, and caching could be used to reduce load on responsible nodes.
📝 Original message:For the future evolution without considering DHTs:
While I think we will sooner or later have supernodes, I don't think they
will need to be trusted too much.
Supernodes will be those nodes that verify all transactions and make them
available to miners. Since miners will become more and more specialized
these supernodes are likely to be owned by the miners themself. To be a
miner either you need to verify all the transactions you include (otherwise
others might be able to find an error in your block and thus drop it) or
have someone that verifies them for you. In the end I think we'll end up
with a hierarchical network, with the miners/supernodes tighly
interconnected at the top and the lightweight clients that simply verify
transactions (or their inputs to be precise) that are destined for them at
the bottom.
As for the DHT we had a few brainstorming sessions a while back on the
forum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)
Forcing someone to participate in a fixed position in the block storage
network is a good way to reduce the risk of a sybil attack as Michael said.
The hash should include only information that cannot be changed by the
user, so IP can be used, but including the port is risky.
Broadcasting the transactions would not need to be done, since miners fetch
them from their storage place, alternatively we could use the inv broadcast
to notify peers about a new block/transaction and let it retrieve them from
the permanent storage (DHT or block storage network). If we route traffic
internally in the DHT we could even start caching at nodes leading to the
real location, since announcements would lead to flashcrowds, putting heavy
load on the responsible nodes. Caching is not a risk since the hash of the
object to be retrieved is already known.
Regards,
Chris
On Wed, Dec 21, 2011 at 1:41 PM, Michael Grønager <gronager at ceptacle.com>wrote:
> I find it likely that we will at some point have supernodes. If we have
> browser based wallets then the server for these automatically becomes
> supernodes. Further, if we move along that direction, it becomes much
> simpler to use both the scheme I proposed or to use a a lot of other
> schemes for sharing the validation work on a farm constituting the
> supernode.
>
> However, if we want to keep bitcoin in a real p2p setup and enable
> scalability in terms of ensuring both thin and fat client to connect then
> we need to go along the path I propose.
>
> Actually, after thinking a bit more about the possible new attack vector I
> don't find it that alarming - if you still require 7 confirmations of any
> bigger transaction before you, as receiver accepts the transaction as payed
> you will not risk anything. The question is then if it is sufficiently easy
> to fake small transaction to e.g. gain access to micropayment based web
> services. I would again say no - the requirement that you have ok from e.g.
> 8 different A.B nodes will make it extremely difficult to cheat, and that
> would even require you to gain some level of control over the network that
> the service you want to cheat is connected through.
>
> This means that you should not divide the hash space more finely than you
> would at all times be able to find 8 different A.B nodes. As the number of
> clients grows you can then divide the hash space further. (with 100000
> nodes today and a division into 512 parts you would have approx 200 nodes
> to choose from).
>
> Cheers,
>
> M
>
>
>
> On 21/12/2011, at 12:42, Eric Lombrozo wrote:
>
> > Is it just me or does it seem inevitable that at some point supernodes
> > will emerge that other nodes trust to validate transactions for them?
> > Supernodes needn't even store the entire block chain and transaction
> > pool...it would be sufficient that they keep lists of IP addresses of
> > other trustworthy nodes and partition them into a hashspace.
> >
> > Anonymous peers have no reputation to defend...but a trusted supernode
> > would, which could provide just enough incentive for the supernode to
> > do its best to ensure the nodes it vouches for are indeed legit. Of
> > course, unless the supernode is validating the entire block chain and
> > transaction pool itself, it could only assess the trustworthiness of
> > other nodes by performing random sampling.
> >
> > Michael, I really like your ideas and the clarity you bring to the
> > issue. Regarding the potential attack vector you mention, would it be
> > possible to partition the hashspace to minimize the risk that an
> > attacker can manage to disproportionately gain control over a part of
> > the hashspace?
> >
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111221/c8347296/attachment.html>

2023-06-07 04:49:56 CEST

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Chris proposed a hypercube network structure to reduce network load, but Gregory advised presenting a working implementation to solve attack resistance problems.
📝 Original message:Criticism accepted, although I'd appreciate it if you supply some reasons
about why it's such a bad idea :-)
The idea was never really popular and before starting work on a real
implementation I wanted to test the water, and should it turn out it's
complete non-sense I'm happy to accept that.
I don't want to have a DHT for the DHTs sake, I was more interested in
reducing the number of messages that need to be sent around the network,
since network load is going to be a major problem if we ever grow beyond a
certain point.
Just wanting to brainstorm.
Regards,
Chris
On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > My idea was to structure the network in a hypercube and use prefixes to
> > address different parts of the network, and use those prefixes also to
> find
> > the location where an item (transaction, block, ...) should be stored.
> Each
> > vertex in the hypercube is a small, highly connected, cluster of nodes.
>
> I strongly advise people who are not me to use this sort of scheme, so
> that I may enjoy the benefits of robbing you blind.
>
>
> .... But really, saying "some sort of DHT" without basically
> presenting a working implementation that demonstrates the feasibility
> of solving the very difficulty attack resistance problems these
> schemes have basically triggers my time-wasting-idiot filter. (Or
> likewise, presenting a fixed network structure that would have a nice
> small and easily identifiable min-cut...)
>
> I don't doubt I'm completely alone in this, though perhaps I'm more
> of a jerk about it. Even if your actual proposal might have some
> merit you should be aware that every fool who has operated a
> bittorrent client has heard of "DHT" and, although they may not even
> understand what a hash table is, many have no reservation going around
> suggesting them for _every_ distributed systems problem. Want to scale
> matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network
> syncup slow (because It's bound on validation related local IO)? DHT!
> I suggest people solve the real problems first, then worry what name
> to give the solutions. ;)
>
> To address gavin's tragedy of the commons concern, one useful feature
> would being able to mutually authenticate a peer... then full nodes
> could pick and choose which lite nodes they're willing to do (a lot
> of) hard work for. This would also be valuable because some modes of
> lite operation require non-zero trust of the full node being queried.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111217/6edf419e/attachment.html>

2023-06-07 04:49:49 CEST

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: A proposed idea to structure the network in a hypercube and use prefixes to address different parts of the network, reducing the need for broadcasts.
📝 Original message:A while back I had proposed a similar idea to the DHT, although my main
goal was to reduce the need for broadcasts.
My idea was to structure the network in a hypercube and use prefixes to
address different parts of the network, and use those prefixes also to find
the location where an item (transaction, block, ...) should be stored. Each
vertex in the hypercube is a small, highly connected, cluster of nodes. The
storage would be distributed, messages are routed on behalf of others,
which makes finding the origin of the query hard to find (think Tor), each
node would have to store only O(log(p)) items, with p being the prefix
length, maximum number of hops is equal to the dimension of the hypercube
O(log(n)).
Newly created transaction will be sent directly to the location they'll be
stored and miners retrieve new transactions at regular intervals. It might
increase delays to the confirmations, but it reduces the number of
broadcasts and storage requirements on nodes greatly.
Regards,
Chris
On Sat, Dec 17, 2011 at 2:13 PM, Michael Grønager <gronager at ceptacle.com>wrote:
> Hey Eric,
>
> Two comments.
>
> 1.
> The ability to query for transactions belonging to pubkeys or bitcoin
> addresses is supported today by several implementations:
> * blockexplorer.com
> * bitcoin-js
> * my own libBTC (will more on this soon)
>
> To query for transactions you need to use json-rpc and not the bitcoin
> protocol, however. But still the purpose is the same: to be able to build
> thin clients that can rely on a server for storing the blockchain and
> keeping connected on the p2p network.
>
> The reason for not having these queries part of the standard protocol (I
> think) are as they breaks anonymity, and that you would actually encourage
> people to participate in the p2p.
>
> 2. The second part you mention, to some how move the storage of the
> blockchain into a DHT based storage would be quite nice. The benefit of
> this is that it could be a way to integrate the smaller clients into the
> network without breaking the anonymity. But it should be thought out quite
> carefully. Further, if each client only store a fraction of the blockchain
> we should work out what fraction that need to be in order to ensure a
> similar service level. I would be happy to work with you on this.
>
> Cheers,
>
> Michael
>
> On 17/12/2011, at 08:41, Eric Lombrozo wrote:
>
> > Hey, guys.
> >
> > I haven't posted here before so I'll introduce myself. My name's Eric,
> > I've been developing cryptocurrency-related
> > software for several months now, I've implemented some libraries for
> > dealing with core bitcoin datastructures, made
> > some custom builds of bitcoind and interfaced it with a few apps I've
> written.
> >
> > In doing so, I've come to appreciate just how little of the potential
> > for the bitcoin protocol is being exploited right now...
> > not only in terms of the script features but in terms of the potential
> > commands and node types that could exist.
> >
> > For instance, the protocol spec at
> > https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands
> > listed and
> > only one service type...despite having a full 12 bytes for a command
> > code and a full eight bytes for a services
> > type.
> >
> > The fact that only one node service type is specified is probably due
> > to the fact that the satoshi client was written
> > to be a standalone monolithic app that took care of all the essential
> > needs for a network of peers.
> > i.e. block chain storage/management, transaction signing/verification,
> > key generation/wallet management, block mining, etc...
> > However, I think there's an urgent need for breaking up all these
> > different tasks into separate components that can run as independent
> > services on different types of devices.
> >
> > One of the big issues I'm dealing with now pertains to block chain
> > storage. As of right now, it is implemented as sequential
> > disk files using Berkeley DB in the satoshi client. Then you have
> > other projects that have been using SQL tables, etc...
> > But I believe the direction this really needs to move towards is some
> > sort of distributed hash table...and the database queries
> > should be performed using the bitcoin protocol itself. Perhaps adding
> > a few more commands. As things stand right now,
> > the only way to query for transactions or blocks is by their hash. And
> > once a transaction gets incorporated into a block and
> > removed from the transaction pool, one can no longer query it by the
> > transaction hash without stepping outside the bitcoin protocol.
> > We need access to the disk file that stores the blocks whether it be
> > via Berkeley DB or SQL or whatever.
> >
> > I propose an extension to the bitcoin protocol to provide methods for
> > performing more sophisticated queries, such as "Give me
> > an inventory of transactions involving this particular public key" or
> > "Give me an inventory all transactions in the last n blocks with
> > unredeemed outputs." This could be done by adding a few more commands.
> >
> > Furthermore, I propose a new network services type for nodes that
> > serve as block chain/transaction pool storage.
> >
> > Of couse, any peer that wishes to verify the integrity of the block
> > chain would still have to download at the very least
> > all the block headers...and to be completely sure, also all the blocks
> > themselves...and verify everything. But it would be
> > very nice to be able to run thin services that can rely on other
> > network peers to do this work. It is still possible to attain
> > a high level of confidence in the integrity by querying multiple peers
> > for similar objects and comparing. It is also possible
> > to run your own dedicated block chain storage servers which you trust.
> >
> > There are other ideas I have for other types of services, too.
> >
> > Anyhow, I'm just throwing this out there...if anyone's interested I'd
> > love to develop these ideas further and help put together some
> > specs.
> >
> > -Eric Lombrozo
> >
> >
> ------------------------------------------------------------------------------
> > Learn Windows Azure Live! Tuesday, Dec 13, 2011
> > Microsoft is holding a special Learn Windows Azure training event for
> > developers. It will provide a great way to learn Windows Azure and what
> it
> > provides. You can attend the event by watching it streamed LIVE online.
> > Learn more at http://p.sf.net/sfu/ms-windowsazure
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111217/000eef2b/attachment.html>

2023-06-07 04:46:15 CEST

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Proposal for a way for merchants to translate a human-readable address into a bitcoin address, using HTTP(S) requests to a merchant-specified URL. Allows for per-transaction or fixed addresses.
📝 Original message:I think the scope of this BIP is not so well defined right now. We need a
way for merchants to translate a human readable, and more importantly
human-writeable, address into a bitcoin address. I agree with Mike that a
fixed address is not the way to go, because addresses should be used once
for a single transaction to be able to track payments.
While firstbits sounds attractive at first, I think we can all agree that
it just isn't feasible and would not allow per-transaction addresses. DNS
sounds interesting for fixed addresses, but caching and propagation make it
difficult to use for per-transaction addresses that are to be generated
ad-hoc.
HTTP(S) is the best option I think, merchants are probably using HTTP
anyway for their shops. So something like
http://merchant.com/btc/transaction/1234 sounds reasonable. But I think it
should not be over-engineered, it should be a simple HTTP(S) request to a
merchant specified URL that returns an ASCII document containing either a
bitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no
use to start defining URL schemes, it should be left to the merchants to
define how to structure them.
This would allow a merchant to decide if he prefers per-transaction
addresses, per-user transactions, fixed addresses or any combination.
Regards,
cdecker
On Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn <mike at plan99.net> wrote:
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the
>> wall a picture of their QR code and a bitcoin address. I don't own a mobile
>> phone so the QR code is
>> useless.
>
>
> Fixed addresses like that are a temporary thing during Bitcoins maturation
> period. They lead to merchants exposing data they probably don't realize
> they're exposing, like their income, which is basically unacceptable for
> any payment system.
>
> There's no point trying to optimize a case where:
>
> 1) You are in the minority (no phone?)
> 2) The "perfect experience" leaks private data in such a way that would be
> deemed a gross security breach by any serious payment processor.
>
> OK, some thoughts on the general proposal, from the POV of what it'd take
> for a large deployment, like for every Gmail or every Facebook user. In
> terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing
> by a large margin. Big sites, even small sites, typically have high-speed
> load balancing and demuxing already implemented for HTTP[S] and it's
> usually easy to add new endpoints. The same is *not* true of DNS, and
> whilst coding up a custom DNS server is possible it's definitely a worse
> fit.
>
> FirstBits seems out of the question for the same privacy reasons as given
> above. No banking system worth its salt would let everyone look up other
> peoples income.
>
> The simplest approach would be to request a full public key with an HTTPS
> request like
>
> foo at domain ->
> https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob
>
> If you then want to turn the resulting public key into an address before
> creating a transaction you can obviously do that.
>
> BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a
> big pile of source code. I think it's the same as above, but it's hard to
> tell without more effort.
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111213/2f4582b5/attachment.html>

2023-06-07 04:37:29 CEST

- reply

📅 Original date posted:2011-11-05
🗒️ Summary of this message: A proposal to modify user-agent strings for Bitcoin protocol versioning is opposed, as it could lead to developers making communication choices based on client type.
📝 Original message:Sorry for shooting this approach down, but I'm against it. User-agent
strings are an extremely bad idea as it would lead developers to start
making communication choices depending on the client type. User-Agents in
HTTP are only useful if the clients (browsers) do not adhere to a well
defined behavior. I see the version string more as a kind of vanity point
(xyz peers are using my network code) and it would be bad to base choices
on it.
For protocol choices we already have a good mechanism in place (nServices)
to negotiate capabilities.
I for one vote for keeping it as simple as possible, just a simple string,
without any further meaning.
On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> From talking with Patrick Strateman (phantomcircuit), he suggested this
> idea (which I will elaborate more on in the BIP):
>
> User-agent strings are a good starting point, however they aren't easy for
> parsing so we'll make a small modification to them.
>
> We need a hierarchy from protocol, variant, gui, flavour, build
>
> /Satoshi:314700/bitcoin-qt:0.4/
>
> How does that sound? In BitcoinJ's case:
>
> /BitcoinJ:0.2/AndroidBuild:0.8/
>
> Thoughts:
>
> - Do we need a freely defined comments field?
>
> /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/
> /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/
>
> ------------------------------
> *From:* Christian Decker <decker.christian at gmail.com>
> *To:* Mike Hearn <mike at plan99.net>
> *Cc:* Amir Taaki <zgenjix at yahoo.com>; "
> bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> *Sent:* Saturday, November 5, 2011 2:45 PM
> *Subject:* Re: [Bitcoin-development] Lock protocol version numbers
>
> On BitDroid I stopped updating the protocol version at 31700 and set the
> string to be both Version and Client, just like BitcoinJ :-)
>
> On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <mike at plan99.net> wrote:
>
> BitCoinJ already sets the subver field to its name and version.
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111105/12fa49fd/attachment.html>

2023-06-07 04:37:20 CEST

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: The retired wxWidgets client was the original "Satoshi client," but the decision to use the name is up to the maintainers.
📝 Original message:The mainline client (independently from the GUI) has been referenced to as
"Satoshi" client. I personally like the name as a homage, but I guess it
all comes down to the decision of the maintainers.
Regards,
Chris
On Thu, Nov 3, 2011 at 12:07 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, November 02, 2011 6:55:27 PM Amir Taaki wrote:
> > I think calling it Satoshi is apt homage to the person who made the
> > original client reference protocol.
>
> My point is that the "Satoshi client" was the wxWidgets client, which was
> retired by 0.5.
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111103/fe144b63/attachment.html>

2023-06-07 04:37:04 CEST

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: A proposal to lock version numbers to the protocol version and use the sub_version_num field for individual builds was discussed.
📝 Original message:Just for reference: https://github.com/bitcoin/bitcoin/pull/63
The issue resulted in my most useless pull request fixing two variables :-)
I second the use of sub_version_num as a Client and Version identifier.
Regards,
Chris
On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Point taken.
>
> About the sub_version_num though. I prefer to let the field by defined
> clients however they wish, with just a guideline suggestion that IDENTIFIER
> VERSION is a format they should follow.
>
> The idea being that different projects would have different release
> scheduling schemes and it'd be restrictive to lock people into the popular
> major.minor system.
>
> So for the current bitcoin to find out the version number of other clients
> (if it was needed), it would have to parse the number from the string:
>
> "Satoshi 0.5"
>
> Although there would be little reason for this with a sane protocol
> versioning scheme.
>
> If we're agreed then I'll start on that BIP.
>
> ------------------------------
> *From:* Gavin Andresen <gavinandresen at gmail.com>
> *To:* Amir Taaki <zgenjix at yahoo.com>
> *Sent:* Wednesday, November 2, 2011 9:34 PM
> *Subject:* Re: [Bitcoin-development] Lock protocol version numbers
>
> Good idea.
>
> Sounds perfect for a BIP....
>
>
> On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> > Hey,
> > Can we lock the version numbers to be the protocol version (which changes
> > rarely) and instead use the sub_version_num field + revision number for
> > individual builds?
>
> --
> --
> Gavin Andresen
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/6ae2fbe3/attachment.html>

2023-06-07 04:36:58 CEST

- reply

📅 Original date posted:2011-11-05
🗒️ Summary of this message: BitDroid stopped updating protocol version at 31700 and set the string to be both Version and Client, similar to BitcoinJ.
📝 Original message:On BitDroid I stopped updating the protocol version at 31700 and set the
string to be both Version and Client, just like BitcoinJ :-)
On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <mike at plan99.net> wrote:
> BitCoinJ already sets the subver field to its name and version.
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111105/2a3d286f/attachment.html>

2023-06-07 04:36:51 CEST

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Chris suggests locking version numbers to protocol version and using sub_version_num field for builds to avoid version bumping.
📝 Original message:I don't really get what you want to achieve with this. The protocol will be
slow down evolution (hopefully) soon, while the clients will continue
releasing at a similar rhythm. It took long enough to decouple the protocol
version from being bumped each client release, now doing the inverse
coupling makes no sense.
Regards,
Chris
On Wed, Nov 2, 2011 at 10:23 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Hey,
>
> Can we lock the version numbers to be the protocol version (which changes
> rarely) and instead use the sub_version_num field + revision number for
> individual builds?
>
> Satoshi 0.4
> BitcoinJava 120311
> bitcoin-js 6
>
> Like so. Otherwise we will have version bumping insanity :)
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/82bfa1e1/attachment.html>

2023-06-07 04:26:14 CEST

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Chris suggests a BitTorrent-like snubbing and dropping protocol for misbehaving peers, but warns against making the rules too restrictive.
📝 Original message:I'd be happy with a sort of BitTorrent like snubbing, and dropping in
extreme cases.
Sharing blacklist decisions would be dangerous. We could even extend the
protocol to include some sort of choking/unchoking in order to warn peers
that we might drop him if he continues to misbehave.
In general I think that we have to be careful in what we consider
misbehaving, it should be really conservative to begin with, and extend the
rules over time. Making them too restrictive might make future development
difficult, not to speak of alternative clients.
Regards,
Chris
On Thu, Sep 15, 2011 at 4:06 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
> > I'm looking for review of this pull request:
> > https://github.com/bitcoin/bitcoin/pull/517
>
> "Non-standard" transactions, or those with "insufficient" fees should not
> be
> penalised. These are properly relay/miner policy decisions, not protocol
> violations, and should be made more easily configurable, not punished for
> configuration.
>
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110915/3c9778ee/attachment.html>

2023-06-07 04:25:33 CEST

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: The security of the Bitcoin protocol should be the top priority, even if it means putting pools at a disadvantage. Pool operators' problems are also potential attackers' problems.
📝 Original message:Am I the only one to think putting pools at a disadvantage is actually
desirable?
Back when pools started to appear we all had huge reservations about putting
so much control into the hands of a few pool operators, but nowadays it
seems that having pool operators control a vast majority of the
computational power is desired.
I do like pools (I use them myself), but we should put the security of the
protocol in first place and then only think about individual players.
Always remember that the problems pool operators encounter are likely also
the ones of a potential attacker that tries to accumulate 50%+ of the
network power :-)
Regards,
Chris
On Wed, Sep 14, 2011 at 5:43 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:
> > The block timestamp rules currently give HOURS of wiggle-room for
> > timestamps. We can't change those rules without risking a chain split.
>
> And those hours of wiggle-room are not enough to cause a problem.
> The problem only comes in (AFAIK) when the existing rules are *not*
> enforced.
>
> > Assuming a majority of pools/miners adopt the "discourage blocks with
> > stale timestamps" rule, that should squash any incentive for cartels
> > to try to start playing with difficulty-- you would have to have 50+%
> > power to start, or you risk producing mostly orphan blocks.
>
> As this is against pools/miners' interests, and doesn't seem to solve any
> real
> problems, I'm going to discourage its adoption if it ever gets done.
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110914/7cbfb95f/attachment.html>

2023-06-07 03:36:26 CEST

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Using HTTP trackers for bootstrapping Bitcoin clients has advantages over IRC and DNS Seeds, including better load balancing and no virus/botnet behavior. Hardcoding trackers would be necessary. Vladimir's proposal of using a specific last octet of IPv4 addresses is not practical and could lead to network partitions.
📝 Original message:Yes, those trackers would be hard coded, just like the IRC servers and
channels are hardcoded right now.
The advantages over IRC and DNS Seeds are:
- sporadic HTTP requests to a tracker, as opposed to keeping an IRC
connection open at all times
- no virus/botnet like behaviour (automatically join IRC channel with
cryptic name), ISPs tend to bother network admins (like myself) with alerts
when they see this...
- adapts faster than DNS Seeds which require configuration changes on seed
should the nodes become unreachable
- we already use HTTP to determine our external IP, so it would be a
consolidation of transports
- more peers than DNS Seeds (better load balancing)
As for Vladimirs proposal, seems like an extreme measure, that is not really
practical. Also it leads to network partitions since nodes will prefer their
own /8 and /16 networks. IPv6 will also soon be a problem for this method.
On Mon, Jun 13, 2011 at 12:54 PM, Vladimir Marchenko <
vladimir at marchenko.co.uk> wrote:
> one possible bootstrap method of last resort,
>
> 1. create a convention of bitcoind listening on a specific last octest
> of IPv4 address, let's say, .14 when possible. Those of us who have
> access to IP space would use .14's.
>
> 2. if no other bootstrap method works, client could start scanning
> x.x.x.14 addresses, perhaps in some semi-intelligent order (starting
> from more pobable /8's and /16's), if enough people place bitcoind on
> x.x.x.14 than after a 10-100 thousand checks it bound to find a
> bitcoind peer.
>
> It's messy, with all the excessive scanning etc... but it does not
> depend on anything except a bunch of bitcoind by convention preferring
> listening on x.x.x.14's.
>
> Given that this is a method of last resort in bootrap chain it whould
> hopefully not lead to DDOS on those unlucky to own *.14 and not
> running bitcoind there. Also the more people are running bitcoind on
> .14, the quicker it would find a peer, the less scanning to do. It is
> kind of self-regualting.
>
> For whatever it worth...
>
>
> On 13 June 2011 10:56, Jeff Garzik <jgarzik at exmulti.com> wrote:
> > On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker
> > <decker.christian at gmail.com> wrote:
> >> BitTorrent trackers are used to handle several thousands of requests, so
> >> they would probably scale well enough. I'm not even talking about using
> the
> >> DHT trackers, but using old fashioned HTTP based trackers. The fact that
> >> each bitcoin client would contact the tracker would make it very hard
> for an
> >> attacker to get bootstrapping clients to exclusively connect to his
> >> compromised clients. I would say that using a tracker such as
> OpenBittorrent
> >> provides the same advantages as using an IRC channel.
> >
> > And how does the client discover HTTP trackers? You're either
> > hardcoding -those- into the client, or adding an additional bootstrap
> > step to discover them. Either way, it has the same problems as other
> > current methods.
> >
> > The history and experience of gnutella's web caches vs. UDP host
> > caches seems highly relevant here.
> >
> > --
> > Jeff Garzik
> > exMULTI, Inc.
> > jgarzik at exmulti.com
> >
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/d921638d/attachment.html>

2023-06-07 03:36:17 CEST

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: The author suggests using BitTorrent trackers for bootstrapping instead of IRC and hardcoded nodes, as they would scale well and be harder to compromise.
📝 Original message:Don't get me wrong, DNS Seeding is an excellent way to bootstrap via trusted
nodes, I'm not trying to replace it.
What I'm trying to get rid of is the IRC bootstrapping and the hardcoded
nodes in the client, they're easy targets.
BitTorrent trackers are used to handle several thousands of requests, so
they would probably scale well enough. I'm not even talking about using the
DHT trackers, but using old fashioned HTTP based trackers. The fact that
each bitcoin client would contact the tracker would make it very hard for an
attacker to get bootstrapping clients to exclusively connect to his
compromised clients. I would say that using a tracker such as OpenBittorrent
provides the same advantages as using an IRC channel.
On Mon, Jun 13, 2011 at 11:09 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > We have quite a few bootstrapping mechanisms, starting with the overly
> > complex (IMHO) IRC bootstrapping, which is often suspected as
> bot-activity.
> > Then we have a few hardcoded nodes and some fallback nodes. I was
> wondering
> > why we didn't adopt BitTorrent tracker bootstrapping until now? It's
> > basically all it does. Given a hash (SHA1 hash of the genesis bloc would
> be
> > nice ^^) it gives you a list of other nodes with the same hash.
>
> It seems to offer few benefits over DNS seeding, while potentially
> potentially creating a vulnerable hot spot in the DHT. Sybil attacks
> on DHTs are well documented.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/2d8c427a/attachment.html>

2023-06-07 03:36:10 CEST

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: The Bitcoin community is discussing the adoption of BitTorrent tracker bootstrapping as a simpler alternative to the current IRC bootstrapping mechanism.
📝 Original message:Hi all.
Just wanted to carry the discussion from the Forum over to the dev-list.
We have quite a few bootstrapping mechanisms, starting with the overly
complex (IMHO) IRC bootstrapping, which is often suspected as bot-activity.
Then we have a few hardcoded nodes and some fallback nodes. I was wondering
why we didn't adopt BitTorrent tracker bootstrapping until now? It's
basically all it does. Given a hash (SHA1 hash of the genesis bloc would be
nice ^^) it gives you a list of other nodes with the same hash.
Given that there are quite a few open trackers (accepting and tracking any
hash you throw at them) we could just decide to use 2-3 of those to
bootstrap.
The downside would be that they return bencoded data, which has to be
interpreted first, but it's easier than implementing the IRC stuff, I think.
Any comments?
Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110613/099e3077/attachment.html>

2023-06-07 03:19:15 CEST

- reply