Hi everyone,
We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
OP_CAT was available in early versions of Bitcoin. It was disabled as
it allowed the construction of a script whose evaluation could create
On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
> > Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
> > lightning where the transaction form is deterministically derived, signing
> > 100
> > extra transactions requires just 6400 extra bytes. Even a very
On 10/20/23 9:25 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
What are anchor outputs used for other than increasing fees?
Because if we've pre-signed the full fee range, there is simply no need for
anchor outputs. Under any circumstance we can
On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
> > What are anchor outputs used for other than increasing fees?
> >
> > Because if we've pre-signed the full fee range, there is simply no need for
> > anchor outputs. Under any circumstance we can broadcast a transaction with a
> >
On 10/20/23 8:15 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
Sadly this only is really viable for pre-anchor channels. With anchor
channels the attack can be performed by either side of the closure, as the
HTLCs are now, at max, only signed
> Let's say you have Alice, Bob and Caroll all "honest" routing hops
> targeted by an attacker. They all have 3 independent 10 000 sats HTLC
> in-flight on their outbound channels.
> It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 sats (+
> rbf penalty 1 sat / vb rule 4).
On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
> Sadly this only is really viable for pre-anchor channels. With anchor
> channels the attack can be performed by either side of the closure, as the
> HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you
> to add
On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev wrote:
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim
Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be
performed by either side of the closure, as the HTLCs are now, at max, only signed
SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the
broadcaster.
I
I think if we apply this presigned fee multiplier idea to HTLC spends,
we can prevent replacement cycles from happening.
We could modify HTLC scripts so that *both* parties can only spend the
HTLC via presigned second-stage transactions, and we can always sign
those with SIGHASH_ALL. This will
On Fri, Oct 20, 2023 at 05:19:19PM +, Fabian via bitcoin-dev wrote:
> Hello list,
>
> on Wednesday I found a potential malleability issue in the UTXO set dump files
> generated for and used by assumeutxo [1]. On Thursday morning theStack had
> found the cause of the issue [2]: A bug in the
Hello list,
on Wednesday I found a potential malleability issue in the UTXO set dump files
generated for and used by assumeutxo [1]. On Thursday morning theStack had
found the cause of the issue [2]: A bug in the serialization of UTXOs for the
calculation of hash_serialized_2. This is the value
On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote:
> I've done an exploration of what would be required (given
> OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
> stack) to usefully validate Taproot outputs in Bitcoin Script. Such
>
I found the original explanation a bit confusing. As I understand it,
the attack starts by double-spending the timeout HTLC transaction of
the victim with a pre-image revealing HTLC transaction. This itself
is not an attack: the victim can then use the pre-image to receive its
incoming HTLC
On Fri, Oct 20, 2023 at 10:31:03AM +, Peter Todd via bitcoin-dev wrote:
> As I have suggested before, the correct way to do pre-signed transactions is
> to
> pre-sign enough *different* transactions to cover all reasonable needs for
> bumping fees. Even if you just increase the fee by 2x each
On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote:
> > I think if you want people to understand this exploit, you need to
> explain in more detail how we have a situation where two different parties
> can spend the same HTLC txout, without the first party having the right to
> spend it
On Tue, Oct 17, 2023 at 10:34:04AM +, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Antoine et al.,
>
> Let me try to rephrase the core of the attack.
>
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==`
> are channels):
>
> A = B = C
>
> `A`
Hi,
After writing the mail reply on the economics of sequential malicious
replacement of honest HTLC-timeout, I did write one more test to verify the
behavior on core mempool, and it works as expected.
https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddcc5f6a1bf2
Responsible
18 matches
Mail list logo
