One thing that we recently stumbled over was that we use CLTV in eltoo not
for timelock but to have a comparison between two committed numbers coming
from the spent and the spending transaction (ordering requirement of
states). We couldn't use a number on the stack of the scriptSig as the
signature
We'd have to be very carefully with this kind of third-party malleability,
since it'd make transaction pinning trivial without even requiring the
ability to spend one of the outputs (which current CPFP based pinning
attacks require).
Cheers,
Christian
On Sat, 5 Mar 2022, 00:33 ZmnSCPxj via bitcoi
Prayank via bitcoin-dev writes:
>> To contrast with his approach, the authors and contributors of
>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>> aren’t promoting an imminent soft fork activation attempt and instead
>> are building out and testing one of the speculated us
> Ah, right.
>
> A feasible attack, without the above, would be to connect to the
> fullnode of the victim, and connect to miners separately. Then you
> broadcast to the victim one of the old txes, call it tx A, but you
> broadcast to the miners a *different* old tx, call it B. The victim
> react
No worries, it's a common character twist I find myself doing from time to
time :-)
Cheers,
Christina
On Fri, 10 Jul 2020, 00:31 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > Af
Ruben Somsen via bitcoin-dev
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. Be
Anthony Towns writes:
> On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev
> wrote:
>> With the recently renewed interest in eltoo, a proof-of-concept
>> implementation
>> [1], and the discussions regarding clean abstractions for off-chain proto
Chris Stewart writes:
>> I don't find too compelling the potential problem of a 'bad wallet
> designer', whether lazy or dogmatic, misusing noinput. I think there are
> simpler ways to cut corners and there will always be plenty of good wallet
> options people can choose.
>
> In my original post,
ZmnSCPxj via bitcoin-dev 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 `S
Chris Stewart 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 l
ZmnSCPxj 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 tr
ZmnSCPxj 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, t
ZmnSCPxj 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
With the recently renewed interest in eltoo, a proof-of-concept implementation
[1], and the discussions regarding clean abstractions for off-chain protocols
[2,3], I thought it might be time to revisit the `sighash_noinput` proposal
(BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
(sorry for
ZmnSCPxj writes:
>> Not necessarily. If we have an escape hatch in the scripts that allows
>> to spend any output attached to the settlement transaction by n-1
>> participants we could reclaim these into a new open right away.
>
> This would have to be very very carefully designed.
> The entire po
ZmnSCPxj writes:
>> cooperative close:
>> * when all parties mutually agree to close the channel
>> * close the channel with a layer one transaction which finalizes the outputs
>> from the most recent channel output state
>> * should be optimized for privacy and low on-chain fees
>
> Of note is t
With the recently published proof-of-concept of eltoo on signet by
Richard, I thought it might a good time to share some thoughts on ho I
think we can build this system. I think there are a few properties of
eltoo that allow us to build a nicely layered protocol stack, which
improves flexibility an
Anthony Towns 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
Johnson Lau writes:
>> 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 t
Johnson Lau 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 s
Ruben Somsen via bitcoin-dev
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 ei
I'd like to retract my comments regarding SINGLE.
I was contacted in private and it was pointed out to me that I was
confusing `sighash_single` with `sighash_single|sighash_anyonecanpay`. I
appreciate the correction and would like to avoid creating confusion
with my previous comments, hence the re
Pieter Wuille via bitcoin-dev
writes:
> On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote:
> * It's probably better to sign the amounts of all inputs, as suggested
> by Johnson Lau. As that would cause default sighashes to sign all
> input and output amounts, is there still a need to sign the tx
Anthony Towns 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
Anthony Towns via bitcoin-dev
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. Any
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 (s
Johnson Lau writes:
> Great, I’ll revise it.
>
> Follow-up questions:
>
> 1. Is there any useful case which one would like to use NOINPUT with
> scriptCode and/or scriptPubKey committed? (Note that with
> taproot/MAST, scriptCode and scriptPubKey are not
> interchangeable. scriptPubKey commits to
Thanks for the update Johnson, just wanted to give a really quick NACK
on the SIGHASH_NOINPUT variant: the whole idea of BIP 118 is to have
floating transactions that can be bound to predecessors, and still
enforce some application logic. In eltoo's case this is the fact that
the state number needs
fred savage via bitcoin-dev writes:
> the issues with sighash_noinput is this
>
> 1. you cannot prevent address-reuse. because bitcoin is a PUSH
> payment. meaning other people can send funds to one address without
> the owner of the key approval/refusal. thus luke cannot control
> addres
Gregory Maxwell writes:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional app
Brian Lockhart writes:
> In the interest of avoiding running multiple bitcoind full nodes - is there
> a method to allow a Lightning node to point to / access a separate
> already-existing node, vs. requiring it to have its own dedicated local
> instance of bitcoind running?
>
> I.e. if I already
Kulpreet Singh via bitcoin-dev
writes:
> But if I understand correctly, lightning nodes need to check if a
> counterparty is broadcasting an old channel state and in response
> broadcast a penalty/justice transaction. Does that mean lightning
> nodes only need to watch for transactions that come a
ZmnSCPxj via bitcoin-dev writes:
> Good morning Rusty and list,
>
>> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is
>> interesting,
>>
>> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need
>> this
>>
>> at all (though others still might).
>
> We might still want th
Anthony Towns writes:
> On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
>> > The big concern I have with _NOINPUT is that it has a huge failure
>> > case: if you use the same key for multiple inputs and sign one of them
>> > with _NOINPUT, you've spent all of them. The current prop
Olaoluwa Osuntokun writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial versi
Olaoluwa Osuntokun via bitcoin-dev
writes:
> Hi Jimpo,
>
> You're correct that the introduction of symmetric state now
> re-introduces the dependency between the CSV value of the commitment,
> and the HTLC timeouts. It's worth nothing that this issue existed in
> an earlier version of the BOLT s
Given the general enthusiasm, and lack of major criticism, for the
`SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent
BIP editors) to be assigned a BIP number. I have hacked together a
simple implementation of the hashing implementation in Bitcoin Core [1]
though I think it's
ZmnSCPxj writes:
> It seems to me, that `SIGHASH_NOINPUT` may help make some protocol
> integrate better with existing wallets.
Depends on which end of a transaction the existing wallet is: existing
wallets will refuse to sign a transaction with an unknown sighash flag,
but if the wallet is creat
Russell O'Connor writes:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
Good catch, must've missed that somehow. I'll amend the BIP accordingly.
___
bitcoin-dev ma
Jim Posen writes:
> I'm still not following why this doesn't accumulate.
>
> In the example route, let's look at it from the point of view of C. C sees
> the following regardless of whether D or E or someone behind E is the last
> hop in the route:
>
> B -> HTLC(expire = X + delta) -> C -> HTLC(ex
Jim Posen writes:
> Can you explain why a fixed offset along the whole circuit is enough to
> ensure safely as opposed to an increased delta at each hop?
Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
let's assume they all have a CLTV delta of 144 blocks (lnd's default
s
ZmnSCPxj 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 *
Jim Posen writes:
> If my understanding is correct though, this construction would
> significantly increase the safe CLTV delta requirements because HTLCs
> cannot be timed out immediately on the settlement transaction. Consider a
> case where node B receives an HTLC from A and forwards to C. If t
Hi all,
I'd like to pick up the discussion from a few months ago, and propose a new
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
output. This was previously mentioned on the list by Joseph Poon [1], but was
never formally proposed, so I wrote a proposal [2].
We hav
(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
te
Note that this would compound the privacy leak that Jonas Nick used to
identify address clusters via the bloom filters in one of his publications.
By reducing the false positives when matching you can get very detailed
clusters. Then again we know that bloom filters aren't good for privacy
anyway,
Peter Todd via bitcoin-dev
writes:
> Does shabang.io say anywhere how it determines whether or not a transaction
> funded a Lightning channel?
My guess they simply collect the short_channel_ids which point to
on-chain outputs that funded a channel. This relies on the channels
being public, non-pu
Agreed, I think a sign-off mechanism might be desirable. Currently it must
be the original author(s) signing off, but we can probably widen that to be
any 2-3 community members. They'd basically be attesting that the meaning
did not change.
- cdecker
On Wed, Sep 27, 2017 at 9:02 PM Bryan Bishop v
I really like the idea of extending signalling capabilities to the
end-users. It gives stakeholders a voice in the decisions we take in
the network, and are a clear signal to all other involved parties. It
reminds me of a student thesis I supervised some time ago [1], in
which we explored various s
On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via bitcoin-dev wrote:
> Note that the 4MB number comes from a single network metric.
>
> Quotes directly from the paper in question:
> http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>
> >Our results hinge on the key metric of effective throug
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/
On Thu, Sep 22, 2016 at 08:37:29PM +0200, Tom via bitcoin-dev wrote:
> On Thursday, 22 September 2016 14:27:29 CEST Peter Todd wrote:
> > CSV uses per-input sequence numbers; you only have a per-tx equivalent.
>
> I think you misunderstand tagged systems at a very basic level. You think
> that h
On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote:
> On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote:
> >
> > I think BIPs should be self-contained, or rely on previous BIPs,
> > whenever possible. Referencing an external formatting d
On Thu, Sep 22, 2016 at 10:56:31AM +0200, Tom via bitcoin-dev wrote:
> On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev wrote:
> > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
> >
> > wrote:
> > > BIP number for my FT spec.
> >
> > This document does not appear to be con
On Thu, Aug 25, 2016 at 02:54:47AM +, James MacWhyte via bitcoin-dev wrote:
> I've always assumed honeypots were meant to look like regular, yet
> poorly-secured, assets. If the intruder could identify this as a honeypot
> by the strange setup (presigned, non-standard transactions lying around)
On Thu, Nov 5, 2015 at 4:27 PM Jorge Timón wrote:
> I think this is just a terminology confusion.
> There's conflicting spends of the same outputs (aka unconfirmed
> double-spends), and there's signature malleability which Segregated
> Witnesses solves.
> If we want to define malleability as sign
approach the normalization
issue we should probably start writing it up and see if we can get critical
mass behind it :-)
On Wed, Nov 4, 2015 at 5:00 AM Peter Todd wrote:
> On Tue, Nov 03, 2015 at 09:44:02PM +0000, Christian Decker via bitcoin-dev
> wrote:
> > Ok, so assuming
On Tue, Nov 3, 2015 at 9:49 PM Luke Dashjr wrote:
> On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:
> > I am still very much intrigued by Luke's idea of having empty scriptsigs
> > and ship the signatures in external scripts, however the proposal uses
> the
> > on-the-fly normali
Ok, getting the ball rolling again after some downtime. I amended the
proposal to use a simple version number instead of the binary flags, added
the normalization of inputs before computing the signaturehash and added
Schnorr signatures as requested.
The BIP has also been assigned number 130 :-)
.
On Thu, Oct 22, 2015 at 10:57 AM Gregory Maxwell wrote:
> On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
> wrote:
> > Normalized transaction IDs do help in the case that the single signer
> wants
> > to immediately follow up its transaction with another t
I think the scenario of the single signer re-ordering the outputs and
inputs and then re-signing the transaction is in the same category of
simple double-spends. The signer could just as well sign a completely
different transaction spending the same coins to somewhere else, so I don't
think there i
Ok, so the normalization step could add a sorting step for inputs/outputs
(which is going to be nasty for SIGHASH_SINGLE), that would solve the issue.
On Wed, Oct 21, 2015 at 10:49 AM Christian Decker <
decker.christ...@gmail.com> wrote:
> On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell
> wrote
On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell wrote:
> On Wed, Oct 21, 2015 at 7:48 AM, Gregory Maxwell
> wrote:
> > I'm still sad that uniform segregated witeness is so hard to deploy,
> > adding another id to every utxo set won't be a nice cost. :( But I
> > have been trying for a long time
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
On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr wrote:
> On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote:
> > > This doesn't completely close malleability (which should be documented
> in
> > > the BIP), so I'm not sure it's wor
On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr 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 the
-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
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > As with the prev
<
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> As with the previous version, which was using a hard-fork, the normalized
>> transaction ID is
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 con
ts to clarify.
Regards,
Chris
[1]
https://blockchain.info/tx/ba1e5d21a340772d637ee5dc0bde8072ad1a7b499ba241d5bfaae9618749531e
On Mon, Aug 24, 2015 at 4:46 PM Jeff Garzik wrote:
> There is a duplicated column.
>
> BIP 100 voting is /BV\d+/
>
>
>
> On Fri, Aug 21, 2015 at 9:2
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@lists.linuxfoundation.org> wrote:
> -
71 matches
Mail list logo
