Here is an old write-up that should be read by everyone trying to design a
NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev
wrote:
> Goo
Good morning Burak,
> > As the access to Lightning is also by the (same?) ASP, it seems to me that
> > the ASP will simply fail to forward the payment on the broader Lightning
> > network after it has replaced the in-mempool transaction, preventing
> > recipients from actually being able to rel
Do you have any write up that presents a fully detailed architecture,
including mechanisms like bitcoin scripts, transactions and L2 protocols,
and then derives claims from that base?
On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > As
Hi Michael,
Yes, I had requested CVE ID after v24.1 was released as Anthony Towns being the
discoverer.
I would follow the process shared here:
https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md when bitcoin core
developers do not disclose vulnerabilities publicly as GitHub issues whic
Hi alicexbt
> It has been assigned CVE-2023-33297
Did you personally request the CVE ID? Say via here [0]? Did you confirm with
someone listed on the vulnerability reporting process [1] for Bitcoin Core that
it made sense to do that at this time? I'm not sure whether completely
bypassing that
Hi fd0,
> - Transactions could be encrypted when published as nostr events initially
> except size, fee rate and offer. This can be used by different clients to
> show them as external mempool with transactions sorted by fee rate without
> affecting privacy of users.
>
I don't think this will wo
Hi Joost,
Transaction relay over nostr sounds interesting. I have 2 suggestions:
- Transactions could be encrypted when published as nostr events initially
except size, fee rate and offer. This can be used by different clients to show
them as external mempool with transactions sorted by fee rat
Hi Lucas,
> In some coinjoin implementations inputs are registered first because in that
> way, if the user fails or refuses to sign the transaction the input is banned
> and denial of service is made a bit more expensive, in the sense that an
> attacker needs more and more utxos to keep the at
Hi Ben,
Thanks for the feedback.
> - Coordinator adds its own inputs, you still get your outputs but
> effectively paid fees for no privacy gain
What will be the incentive for a coordinator to add its inputs in coinjoin? Is
this possible without ALL|ANYONECANPAY as well? Even if there is an
Hi all,
In some coinjoin implementations inputs are registered first because in
that way, if the user fails or refuses to sign the transaction the input is
banned and denial of service is made a bit more expensive, in the sense
that an attacker needs more and more utxos to keep the attack going.
Hi,
I write to get your thoughts on an alternative approach for Bitcoin
transaction relay, addressing some of the limitations in the current
peer-to-peer transaction relay system. To the best of my knowledge, the
credit for the original concept goes to Ben Carman. I felt it would be
beneficial to
> As the access to Lightning is also by the (same?) ASP, it seems to me that
> the ASP will simply fail to forward the payment on the broader Lightning
> network after it has replaced the in-mempool transaction, preventing
> recipients from actually being able to rely on any received funds exist
12 matches
Mail list logo
