Hi Bastien,
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
If my understanding of the "soft lock" strategy is
> I think it's important to differentiate between fees a node charges and
> *reputation_revenue*. Reputation is determined as a function of the latter.
> If Caroll has a very high *reputation_revenue* and Bob has a very low one,
> then Bob probably won't have a high reputation with Caroll, as the
Hi list,
As it has been discussed before, a solution to mitigate jamming
attacks over the Lightning Network consists in the introduction of
credentials that must be acquired by HTLC senders to lock each hop
liquidity along the forwarding path. Those credentials can be
privacy-preserving to mask
Hi all,
> That is, one cannot gain reputation during low fee times and use it when
fees are high.
> Good reputation is also a function of the general environment, and so if
there is a fee spike, reputation will change. It is true that nodes can go
rogue, but this is why we aim > for the price of
Hi Tony,
> Is there a better place to have public communication? Unfortunately since
one off topic email was sent here, it's been a ghost town. It appears that
there's many emails being held and only one moderator that checks them once
a week.
As I think you're referring to my post of March 21th
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
Hi Bastien,
Thanks for the update on the state of splicing.
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only
acting the wider
non-LL Taro community).
There are 2 more troubling issues. One, the title of the letter "Chaincode
Labs - Cease & Desist Letter to Antione Riard". I really received it like
this and checked the typo multiple times. I think my name is Antoine Riard,
I've to verify b
Hi all,
My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the
Hi Val,
Thanks for the proposal here. About using OM for payment probing, I think
there could be an alternative of the routing hops themselves announcing
their liquidity balances with an extension or new set of gossip messages.
Gossips messages could commit to a liquidity balance and duration
As long as protocol development and design is done neutrally, I'm all fine!
Le ven. 17 févr. 2023 à 10:48, Joost Jager a écrit :
> Right, that was my above point about fetching scoring data - there's three
>> relevant "buckets" of
>> nodes, I think - (a) large nodes sending lots of payments,
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit
Hi Joost,
> 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
Hi Clara,
> * They will likely require a network wide upgrade: when a sender
>makes a payment, the full path will need to understand the new
>feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials --
(Reply 2/2)
> * Whether we should look into a more complicated approach that
>includes a "proof of forward" secret in the next node's onion which
>must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty
Hi Clara,
(Reply 1/2 - Apparently there is a limit of 80KB on Lightning mailing post)
> * They will likely require a network wide upgrade: when a sender
>makes a payment, the full path will need to understand the new
>feature bit for it to be used.
I believe the upgradeability
Hi all,
Since starting to hack on LDK, I’ve been interested in running some
components of a Lightning node in a dedicated hardware environment, in the
image of what is done by the smart card industry. We have been doing a
bunch of refactoring in that sense early on to isolate our signing
Hi LN devs,
Following the November proposal of mitigating channel jamming with
Reputation Credentials, started to document the protocol architecture.
After feedback on the naming protocol itself, I switched to Staking
Credentials. In fact the proposed architecture enables mitigations
deployment
ntity.
Still, I think eltoo channels would simplify the implementation of
distributed towers by Lightning implementation, notably handling concurrent
broadcast w.r.t chain asynchronicity issues, and hopefully removing the
concern of commitment transaction key duplication by tower [0].
Bes
ransaction is only allowed
> a single ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this poli
nt relies here. AFAICT, if there is an unbounded spending path
cycle introduced for one of the counterparties, you're exposed to "eltoo
states overflow".
Best,
Antoine
Le lun. 12 déc. 2022 à 22:51, Anthony Towns a écrit :
> On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
all that matters. It does introduce a watchtower cycle, so it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
>
> Cheers,
> Greg
>
> On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard
> wrote:
>
>
Hi list,
The following post describes a potential attack vector against eltoo-based
Lightning channels, from my understanding also including the recent
two-party eltoo w/ punishment construction. While I think this concern has
been known for a while among devs, and I believe it's mitigable by
Hi Clara,
Thanks for rolling the ball forward.
On the agenda, a few more thoughts.
> 1. Which parameters should be considered in reputation-based solutions?
I think before thinking about the parameters of reputation-based solutions,
we should discuss the security goal we're aiming to achieve
Hi AJ,
The eltoo irc channel is ##eltoo on Libera chat.
> - 2022-10-21, eltoo/chia:
https://twitter.com/bramcohen/status/1583122833932099585
On the eltoo/chia variant, from my (quick) understanding, the main
innovation aimed for is the limitation of the publication of eltoo states
more than
Hi Joost,
> The economic proportionality is that an attacker can't do much with a
> severely limited channel, and would need many more to achieve the same
> effect. I don't think it is possible to eliminate all bad behavior, and
> that the goal should just be to make it a lot harder than it
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
Hi Loki,
Thanks for raising awareness on this project.
I share the sentiment on the gradual generalization of Lightning onion
messaging as a transport network on its own for Bitcoin-specific traffic
such as offers, offline receive control flow or credentials tokens or even
in the future DLC
Hi Zeeman,
I think it is correct to say that if any mechanism to protect against
channel jamming succeeds, the remaining instance of apparent channel
jamming might be accidental. This rate of accident might be still high due
to spontaneous congestion (i.e more HTLC senders than slots/liquidity
Hi Dave & Zeeman,
As the credentials tokens should be blinded during countersigning and then
wrapped inside HTLC onions, the routing hops cannot use them to assign
blame. Instead the jamming attack prevention efficiency relies on
misbehaving senders exhausting their supply of scarce and costly
ations, is on by default in all those Lightning
> implementations etc. And even if it was I would want to opt out of it.
>
> Thanks
> Michael
>
> [0]: https://jamming-dev.github.io/book/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: mi
.bitrated.com/faq
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Monday, November 21st, 2022 at 06:01, Antoine Riard <
> an
ike to mask).
Best,
Antoine
Le sam. 26 nov. 2022 à 15:48, David A. Harding a écrit :
> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 4. How would these tokens work with blinded paths and other
> >> privacy-preserving suggestions?
>
khelman
a écrit :
> Cool, thanks for that.
>
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
>
> On Thu, Nov 24, 2022, 21:22 Antoine Riard wrote:
>
>> Hi Clara,
>>
>> The main benefit of this "staking"
unds like unconditional fees cover most of what this policy does,
> without the extra risks that come from creating a new token. Is there a
> clear benefit to using a token compared to unconditional fees and
> local reputation?
>
> Best,
> Clara
>
> On Wed, Nov 23, 2022
in detail, I think that some kind of
> recommended policy is needed. If presenting one is a low priority, and
> waiting for other things, my main concern is that it will just never happen
> ("any decade now" kind of situation).
>
> Best,
> Clara
>
> On Tue, No
Hi Clara,
Shared the mail on #lightning-dev Libera chat to get more feedback on
schedule.
> Do you have a timeline in mind for presenting such a policy?
See the comments on the BOLT #1043 PR, for now I'm thinking more to refine
the proposed credentials architectural framework.
I think dynamic
hannel?
> If this is the case, can't a routing node "trick" a user into buying many
> tokens and then bring the price up?
>
> 4. How would these tokens work with blinded paths and other
> privacy-preserving suggestions?
>
> Thanks again,
> Clara
>
> On Sun, Nov
Hi LN Devs,
tl;dr A formalization of a reputation-based scheme to solve channel jamming
is proposed. The system relies on "credentials" issued by routing hops and
requested to be attached to each HTLC forward request. The "credentials"
can be used by a reputation algorithm to reward/punish
Hi Clara, Sergei
Congrats for the paper!
Here are a few in-flight thoughts browsing the paper.
On introducing a general framework for evaluating attack mitigations, I
think this is relevant as scarce resources wastes, of which jamming is a
subcase is echoed multiple times not only in Lightning,
Hi Dustin,
>From my understanding, splice pinning is problematic for channel funds
safety. In the sense once you have a splice floating in network mempools
and your latest valid commitment transaction pre-signed fees isn't enough
to replace the splice, lack of confirmation might damage the claim
Hi Alex,
Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup
Gleb Naumenko and I would like to present our latest research on the
well-known channel jamming attacks affecting the Lightning Network. For a
reminder on the basis of channel jamming, we would like to point to Gleb's
earlier recollection [0].
We have a serie of research posts available here:
Hi Bastien,
Thanks for the proposal,
While I think establishing the rate limiting based on channel topology
should be effective to mitigate against DoS attackers, there is still a
concern that the damage inflicted might be beyond the channel cost. I.e, as
the onion messages routing is
Hi Laolu,
Thanks for the proposal, quick feedback.
> It *is* still the case that _ultimately_ the two transactions to close the
> old segwit v0 funding output, and re-open the channel with a new segwit v1
> funding output are unavoidable. However this adapter commitment lets peers
> _defer_
Hi Eugene,
> Since the remote party gives them a signature, after the timeout, the
offering party can
claim with the remote's signature + preimage, but can only spend with the
HTLC-timeout transaction because of SIGHASH_ALL.
I've not exercised the witness against our test framework though the
I've been informed by Mitre, the correct CVE assignment:
* c-lightning : CVE-2021-41592
* lnd: CVE-2021-41593
Not the assignement disclosed in the initial mail.
Le lun. 4 oct. 2021 à 11:09, Antoine Riard a
écrit :
> Hi,
>
> I'm writing a report to disclose specification-level vulner
13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard
> wrote:
>
>> Hi,
>>
>> I'm writing a repo
ink we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.
Le lun. 4 oct. 2021 à 12:28, Luke Dashjr a écrit :
> On Monday 04 October 2021
sadly that's going to increase with Lightning growth and deployment of
other L2s.
Maybe we could dry-up some policy rules in consensus like the dust limit
one :)
Le lun. 4 oct. 2021 à 11:57, Luke Dashjr a écrit :
> On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> > St
Hi,
I'm writing a report to disclose specification-level vulnerabilities
affecting the Lightning implementations.
The vulnerabilities are expected to be patched in:
* Eclair: v0.6.2+ (CVE-2021-41591)
* LND: v0.13.3+ (CVE-2021-41592)
* LDK: v0.0.102 (not released as production software yet)
The
m/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2=1#slide=id.g85f425098
Thanks to bringing to the surface probabilistic payments, yes that's a
worthy alternative approach for low-value payments to keep in mind.
Le mar. 10 août 2021 à 02:15, David A. Harding a écrit :
> On Mon, Aug 09, 2021 at 09:22:
I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety
Hi Ryan,
Thanks for starting this discussion, I agree it's a good time for the
Lightning development community to start this self-introspection on its own
specification process :)
First and foremost, maybe we could take a minute off to celebrate the
success of the BOLT process and the road
nds full with their own
> implementations.
>
> I think we can get the balance right by making progress on this
> (important) discussion whilst also maintaining humility that we don't
> know exact timelines and that getting things merged into Core relies
> on a number of people who
Hi,
I was super glad to see the recent survey on potential softforks for the
near-future of Bitcoin! I didn't have time to answer this one but will do
so for the future. I wanna to salute the grassroots involvement in bitcoin
protocol development, that's cool to see :)
Though softforks are what
ub.com/bitcoin/bitcoin/issues/14895
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
Le sam. 19 juin 2021 à 09:38, David A. Harding a écrit :
> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> > 2) Solving the Pre-Signed Feerate problem
> That's a question I hope we'll gather feedback during next Thursday's
transaction relay workshops.
As someone kindly pointed out to me, workshop is happening Tuesday, June
22th. Not Thursday, mistake of mine :/
Le ven. 18 juin 2021 à 18:11, Antoine Riard a
écrit :
> Hi,
>
>
Hi,
It's a big chunk, so if you don't have time browse parts 1 and 2 and share
your 2 sats on the deployment timeline :p
This post recalls some unsolved safety holes about Lightning, how
package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool
hardening can solve the second
Hi,
A short reminder about the 1st transaction relay workshop happening
tomorrow on #l2-onchain-support Libera chat (!), Tuesday 15th June, from
19:00 UTC to 20:30 UTC
Scheduled topics are:
* "Guidelines about L2 protocols onchain security design"
* "Coordinated cross-layers security
Hi,
In this post I would like to highlight some DoS attacks against multi-party
Bitcoin protocols during their funding phases. Recent discussions around
DLC funding flow [0] and dual-funding of LN channel [1] remind me that some
timevalue DoS/fee inflation issues are common to any multi-party
0 block lock
> on spending a sponsoring tx which would hopefully make less controversial,
> this would be a great place to discuss those tradeoffs.
>
> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard
> wrote:
>
>> Hi,
>>
>> During the lastest years, tx-relay and mempool
Hi,
During the lastest years, tx-relay and mempool acceptances rules of the
base layer have been sources of major security and operational concerns for
Lightning and other Bitcoin second-layers [0]. I think those areas require
significant improvements to ease design and deployment of higher
a first attempt at projecting this idea onto the existing spec:
> https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also
> clarify some of the questions that haven't been answered yet.
>
> Joost
>
> On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard
> wro
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims
# Problem
A lightning node must verify that its channel transactions are not only
consensus-valid but also tx-relay standard. The counterparty signatures are
part of the local txn (commitment/HTLC) as provided in the
`commitment_signed`. Verifying consensus-validity of these signatures but
not
# Problem
A lightning node must verify that its channel transactions are not only
consensus-valid but also tx-relay standard. The counterparty signatures are
part of the local txn (commitment/HTLC) as provided in the
`commitment_signed`. Verifying consensus-validity of these signatures but
not
# Problem
In case of a relayed HTLC hash-and-amount collision with an expected
payment HTLC on the same channel, LND was releasing the preimage for the
later while claiming onchain the former. A malicious peer could have
deliberately intercepted a HTLC intended for the victim node, probe the
Hi Joost,
Thanks for your proposal, please find my following opinion which is
deliberately on a high-level as IMO defining better threats model and
agreeing on expected network dynamics resulting from any solution
trade-offs sounds required before to work on any solution.
> We've looked at all
Hi Zeeman,
> * It requires a lot more communication rounds and (symmetric, at least)
cryptographic operations.
At first sight, it sounds similar to HORNET/rendez-vous, at least in the
goal of achieving bidirectional communications.
* Intermediate nodes can guess the distance from the source by
> There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway
I think it's just how you defne channel's operations, either emptying out
all pending HTLCs or more a `update_fee` alike semantic. You're right that
the latter
Hello Bastien,
I'm all in for a model where channel transactions are pre-signed with a
reasonable minimal relay fee and the adjustment is done by the closer. The
channel initiator shouldn't have to pay for channel-closing as it's somehow
a liquidity allocation decision ("My balance could be
Hello Bastien,
As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC
h can potentially cascade.
> >
> > In lnd today, anchors is still behind a build flag, but we plan to enable
> > it by default for our upcoming 0.12 release. The blockers on our end
> were to
> > add support for towers, and add basic deadline aware bumping, both of
>
ll now also look into setting clamps on the
> receiver end to just not accept unreasonable values for the fee rate of a
> commitment, as this ends up eating into the true HTLC values for both
> sides.
>
> -- Laolu
>
>
> On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard
> w
Hi,
In this post, I would like to expose a potential vulnerability introduced
by the recent anchor output spec update related to the new usage of
SIGHASH_SINGLE for HTLC transactions. This new malleability combined with
the currently deployed mechanism of `update_fee` is likely harmful for
funds
Hi Zeeman,
> i.e. I send my high-fee RBF-enabled channel funding to you, at the same
time I send a conflicting low-fee RBF-disabled transaction (that pays the
entire channel amount to myself) to all the miners I can find.
Mapping miners mempools will be a cost in spying infrastructure and thus
Hi Roei,
You might have a mechanism to lower trust in zero-conf channel opener.
Actually the local party can be in charge of broadcasting the funding
transaction, thus ensuring it's well-propagated across network mempools and
then start to accept incoming payment on the zero-conf channel. Per BIP
Hi Laolu,
I think that's a must before we introduce a bunch of new features and the
number of channels explodes. The de-synchronized side could be underscored
more as any scheduled, automatic, massive upgrade for security forcing
chain writes can be exploited to launch mempool-congestion
(tl;dr Ideally network mempools should be an efficient marketplace leading
to discovery of best-feerate blockspace demand by miners. It's not due to
current anti-DoS rules assumptions and it's quite harmful for shared-utxo
protocols like LN)
Hello all,
Lightning security model relies on the
Hi Rene,
Thanks for disclosing this vulnerability,
I think this blackmail scenario holds but sadly there is a lower scenario.
Both "Flood & Loot" and your blackmail attack rely on `update_fee`
mechanism and unbounded commitment transaction size inflation. Though the
first to provoke block
Hi ZmnSCPxj,
As of today, you can setup a `htlc_minimum_msat` higher than remote's
`dust_limit_satoshis`, but you don't necessarily know it before announcing
your channel parameters if you're initiator.
In practice, assuming you can do so, with fees going higher and HTLC
outputs being encumbered,
Lightning protocol supports a floating dust output selection at channel
creation, where each party declares a dust parameter applying to its local
transactions. The current spec doesn't enforce or recommend any bound on
this value, beyond the requirement of being lower that
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.
Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step
dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-...@lists.linuxfoundation.org> wrote:
> >
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> Trust-minimization of Bitcoin security
Hi Christopher,
Thanks for Blockchain Commons and Learning Bitcoin from the Command Line!
> If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could
Africans and
> Europeans serving the Asians in kind. By plugging in our phones and going
> to sleep we could blanket the whole world in (somewhat) full nodes!
>
> Cheers,
> Igor
>
> [1] https://icota.github.io/
>
> On Tue, 5 May 2020 at 12:18, Antoine Riard
> wrot
out miners.
>
> Keagan
>
> On Wed, May 6, 2020 at 3:06 AM Antoine Riard
> wrote:
>
>> I do see the consensus capture argument by miners but in reality isn't
>> this attack scenario have a lot of assumptions on topology an deployment ?
>>
>> For such attack
ess to a single header/filter, a range of them in the past, or N headers
> past the known chain tip, etc, etc.
>
> -- Laolu
>
> [1]: https://lsat.tech/
> [2]: https://lightning.engineering/posts/2020-03-30-lsat/
>
>
> On Tue, May 5, 2020 at 3:17 AM Antoine Riard
> wrote:
>
>
> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.
And offer them a solution which would scale in the long-term.
Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how
foster node adoption as much as we can.
Le mar. 5 mai 2020 à 09:01, Luke Dashjr a écrit :
> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This curre
I didn't trust myself and verify. In fact the [3] is the real [2].
Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses a
écrit :
> Hey Antoine, just a small note, [3] is missing in your footnotes, can you
> add it? Thanks
>
> On Tue, 5 May 2020 at 18:17, Antoine Riard
>
Hi,
(cross-posting as it's really both layers concerned)
Ongoing advancement of BIP 157 implementation in Core maybe the opportunity
to reflect on the future of light client protocols and use this knowledge
to make better-informed decisions about what kind of infrastructure is
needed to support
Personally, I would have wait a bit before to go public on this, like
letting some implementations
increasing their CLTV deltas, but anyway, it's here now.
Mempool-pinning attacks were already discussed on this list [0], but what
we found is you
can _reverse_ the scenario, where it's not the
Darosior ( i'll stick with my pseudo, first names definitely don't have
> enough entropy :-) )
> Original Message ----
> On Jan 30, 2020, 19:09, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> Hey Darosior,
>
> You don't need a strict synchronization bet
ei)
>
>
> Antoine
>
>
> ---- Original Message
> On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> Hey thanks for this proposal!
>
> 2 high-level questions:
>
> What about multi-party tx constructi
Hi Max,
Sorry by transaction format I didn't mean a binary transaction format,
but format like we use in BOLT3 :
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md
My concern is, e.g LN implementations setting nLocktime to 0x,
Coinjoin wallets always
Hey thanks for this proposal!
2 high-level questions:
What about multi-party tx construction ? By multi-party, let's define
Alice initiate a tx construction to Bob and then Bob announce a
construction to Caroll and "bridge" all inputs/outputs
additions/substractions
in both directions. I think
Hey Zeeman,
tl;dr A LN node paired with an external signer can be distrusted and LN
funds be safe in any case
if signer is connected to a N-set of watchtowers and at least one of them
is non-compromised.
Thanks for this interesting post, I was thinking about LN hardware wallets
support for a
Hi Bastien,
The use case you're describing strikes me as similar to a slashing protocol
for a LN node and a watchtower, i.e punishing
a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
unlock some funds for B".
Here a rough
1 - 100 of 108 matches
Mail list logo
