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
> wrote:
>
>> Hi,
>>
>>
> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts?
That's an interesting idea, but an attacker can create a local conflict in
your mempool
and then send the preimage tx to make hit recentRejects
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
Morning Zeeman,
> I proposed before to consider splicing as a form of merged closing plus
funding, rather than a modification of channel state; in particular we
might note that, for compatibility with our existing system, a spliced
channel would have to change its short channel ID > and channel
> I notice your post puts little spotlight on unilateral cases.
> A thing to note, is that we only use `nSequence` and the weird watermark
on unilateral closes.
> Even HTLCs only exist on unilateral closes --- on mutual closes we wait
for HTLCs to settle one way or the other before doing the
chnorr happen we don't
have to wait another period to start enjoying the privacy enhancement
(worst-case we can fallback on 2p-ecdsa).
Le sam. 22 févr. 2020 à 07:10, AdamISZ a écrit :
> ‐‐‐ Original Message ‐‐‐
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <
Coinjoins interceptions seem to raise at an increasing pace. Their onchain
fingerprint (high-number of inputs/outputs, lack of anti-fee snipping,
script
type, ...) makes their detection quite easy for a chain observer. A ban of
coinjoin'ed coins or any other coins linked through a common ownwer
> In particular, you care more about privacy when you are contesting a
> close of a channel or other script path because then the miners could be
more
> likely to extract a rent from you as "ransom" for properly closing your
channel
> (or in other words, in a contested close the value of the
201 - 209 of 209 matches
Mail list logo
