Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

[Christian Decker via bitcoin-dev]

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 doesn't commit to it, which is why we commandeered nLocktime
values that are already in the past.

With the annex we could have a way to get a committed to number we can pull
onto the stack, and free the nLocktime for other uses again. It'd also be
less roundabout to explain in classes :-)

An added benefit would be that update transactions, being singlesig, can be
combined into larger transactions by third parties or watchtowers to
amortize some of the fixed cost of getting them confirmed, allowing
on-path-aggregation basically (each node can group and aggregate
transactions as they forward them). This is currently not possible since
all the transactions that we'd like to batch would have to have the same
nLocktime at the moment.

So I think it makes sense to partition the annex into a global annex shared
by the entire transaction, and one for each input. Not sure if one for
inputs would also make sense as it'd bloat the utxo set and could be
emulated by using the input that is spending it.

Cheers,
Christian

On Sat, 5 Mar 2022, 07:33 Anthony Towns via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 04, 2022 at 11:21:41PM +, Jeremy Rubin via bitcoin-dev
> wrote:
> > I've seen some discussion of what the Annex can be used for in Bitcoin.
>
>
> https://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
>
> includes some discussion on that topic from the taproot review meetings.
>
> The difference between information in the annex and information in
> either a script (or the input data for the script that is the rest of
> the witness) is (in theory) that the annex can be analysed immediately
> and unconditionally, without necessarily even knowing anything about
> the utxo being spent.
>
> The idea is that we would define some simple way of encoding (multiple)
> entries into the annex -- perhaps a tag/length/value scheme like
> lightning uses; maybe if we add a lisp scripting language to consensus,
> we just reuse the list encoding from that? -- at which point we might
> use one tag to specify that a transaction uses advanced computation, and
> needs to be treated as having a heavier weight than its serialized size
> implies; but we could use another tag for per-input absolute locktimes;
> or another tag to commit to a past block height having a particular hash.
>
> It seems like a good place for optimising SIGHASH_GROUP (allowing a group
> of inputs to claim a group of outputs for signing, but not allowing inputs
> from different groups to ever claim the same output; so that each output
> is hashed at most once for this purpose) -- since each input's validity
> depends on the other inputs' state, it's better to be able to get at
> that state as easily as possible rather than having to actually execute
> other scripts before your can tell if your script is going to be valid.
>
> > The BIP is tight lipped about it's purpose
>
> BIP341 only reserves an area to put the annex; it doesn't define how
> it's used or why it should be used.
>
> > Essentially, I read this as saying: The annex is the ability to pad a
> > transaction with an additional string of 0's
>
> If you wanted to pad it directly, you can do that in script already
> with a PUSH/DROP combo.
>
> The point of doing it in the annex is you could have a short byte
> string, perhaps something like "0x010201a4" saying "tag 1, data length 2
> bytes, value 420" and have the consensus intepretation of that be "this
> transaction should be treated as if it's 420 weight units more expensive
> than its serialized size", while only increasing its witness size by
> 6 bytes (annex length, annex flag, and the four bytes above). Adding 6
> bytes for a 426 weight unit increase seems much better than adding 426
> witness bytes.
>
> The example scenario is that if there was an opcode to verify a
> zero-knowledge proof, eg I think bulletproof range proofs are something
> like 10x longer than a signature, but require something like 400x the
> validation time. Since checksig has a validation weight of 50 units,
> a bulletproof verify might have a 400x greater validation weight, ie
> 20,000 units, while your witness data is only 650 bytes serialized. In
> that case, we'd need to artificially bump the weight of you transaction
> up by the missing 19,350 units, or else an attacker could fill a block
> with perhaps 6000 bulletproofs costing the equivalent of 120M signature
> operations, rather than the 80k sigops we currently expect as the maximum
> in a block. Seems better to just have "0x01024b96" stuck in the annex,
> than 19kB of zeroes.
>
> > Introducing OP_ANNEX: Suppose there were some sort of annex 

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

[Christian Decker via bitcoin-dev]

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 bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Jeremy,
>
> Umm `OP_ANNEX` seems boring 
>
>
> > It seems like one good option is if we just go on and banish the
> OP_ANNEX. Maybe that solves some of this? I sort of think so. It definitely
> seems like we're not supposed to access it via script, given the quote from
> above:
> >
> > Execute the script, according to the applicable script rules[11], using
> the witness stack elements excluding the script s, the control block c, and
> the annex a if present, as initial stack.
> > If we were meant to have it, we would have not nixed it from the stack,
> no? Or would have made the opcode for it as a part of taproot...
> >
> > But recall that the annex is committed to by the signature.
> >
> > So it's only a matter of time till we see some sort of Cat and Schnorr
> Tricks III the Annex Edition that lets you use G cleverly to get the annex
> onto the stack again, and then it's like we had OP_ANNEX all along, or
> without CAT, at least something that we can detect that the value has
> changed and cause this satisfier looping issue somehow.
>
> ... Never mind I take that back.
>
> Hmmm.
>
> Actually if the Annex is supposed to be ***just*** for adding weight to
> the transaction so that we can do something like increase limits on SCRIPT
> execution, then it does *not* have to be covered by any signature.
> It would then be third-party malleable, but suppose we have a "valid"
> transaction on the mempool where the Annex weight is the minimum necessary:
>
> * If a malleated transaction has a too-low Annex, then the malleated
> transaction fails validation and the current transaction stays in the
> mempool.
> * If a malleated transaction has a higher Annex, then the malleated
> transaction has lower feerate than the current transaction and cannot evict
> it from the mempool.
>
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Christian Decker via bitcoin-dev]

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 use cases, eltoo
>> payment channels [4].
>
> Because its not ready?

Could you elaborate on this point? I keep seeing people mentioning this,
but I, as BIP co-author, have not seen any real pushback. For context
BIP118 was initially called `sighash_noinput` and it was mentioned at
least as far back as 2015 when Joseph and Tadje wrote about its
applications in the LN protocol. While writing eltoo we stumbled over an
alternative use, and decided to draft the formal proposal.

Once we saw that Taproot is likely to activate next, AJ started adapting
it to integrate nicely with Taproot, and renamed it to anyprevout.

I'd like to point out that the original noinput could be implemented
with as little as 3-5 lines of code in Bitcoin Core, and there are
experimental branches implementing APO, which isn't significantly more
complex than the original proposal.

In addition Richard Myers has implemented a PoC of eltoo on top of one
of these experimental branches. So with all this I don't see how APO
could be considered "not ready".

The reason that neither noinput nor APO have a section on activation is
that we want to allow bundling with other soft-forks, and we want to
minimize the surface for potential conflicts. Also as the Taproot
activation has shown activation is a whole another discussion, that is
mostly unrelated to the soft-fork being activated.

Why aren't we yelling about the advantages of APO over other soft-forks
or asking for immediate activation? Because we want to be respectful of
everyone's time. We know review capacity is very limited, and developer
time expensive. By now most devs will be aware of the many improvements
(on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
anyprevout would enable, so there is little point in annoying everyone
by constantly talking about it. The people interested in exploring this
venue are already working on it, and we just need to wait for an
opportune moment to start the activation discussion with other
soft-forks.

I also see people comparing OP_CTV with APO, which may or may not work
out in the end. It seems possible to emulate APO using OP_CTV, but at
what cost? APO does not have any overhead in the transaction size, which
is not the case for OP_CTV, and I therefore consider the two proposals
complementary, and not competing (APO does best what APO does best,
while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
if only one gets activated (But then why would we? We've done much more
obscure things to save bytes in a TX).

Finally I see people mentioning that APO is insufficient to get
eltoo. That's also not true, since in fact we can implement a poor-man's
version of eltoo right now:

 - When updating:
   - Iterate through all prior update TXs
   - Bind the new update TX to each of the prior ones
   - Sign using `sighash_all`
   - Collect all sinatures and send to peer (message size O(n), but
 semantics are preserved, while APO enable O(1) making it actually
 reasonable to implement).

There may be some extensions, such as layered commitments that may be
added at a later stage, but they are not required to get the first
versions off the ground. Pretending that they're required would be like
saying that the protocol in the LN paper hasn't changed since it was
first written (definitely not the case).

Overall I agree with Michael's sentiment that soft-fork activations have
to be carefully planned, and kept at a reasonable pace. This is in order
to ensure that the activated features will work as expected (building
PoCs is important here) and that review time is kept efficient (bundling
may help here). For these reasons we omitted the activation discussion
in BIP118 and have trimmed the proposal to the bare minimum.

Sorry for the longish rant, but I felt I needed to clarify this
situation a bit.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

[Christian Decker via bitcoin-dev]

> 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
> reacts only to tA, but does not react to B since it does not see B in
> the mempool.
>
> On the other hand --- what the victim needs to react to is *onchain*
> confirmed transactions.  So I think all the victim needs to do, in a
> Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based
> mechanisms, is to monitor onchain events and ignore mempool events.
>
> So if we give fairly long timeouts for our mechanisms, it should be
> enough, I think, since once a transaction is confirmed its txid does
> not malleate without a reorg and a `SIGHASH_NOINPUT` signature can
> then be "locked" to that txid, unless a reorg unconfirms the
> transaction.  We only need to be aware of deep reorgs and re-broadcast
> with a malleated prevout until the tx being spent is deeply confirmed.

This is indeed part of the reason why we chose to describe the protocol
on-chain first in the paper and lift it off-chain after showing the
basic functionality. This means that the protocol is still correct even
if executed solely on information derived from blocks and confirmed
transactions in those blocks. The timeouts have to be chosen carefully
to allow reacting in a timely fashion, however that is true for all
off-chain protocols.

> In addition, we want to implement scorch-the-earth,
> keep-bumping-the-fee strategies anyway, so we would keep
> rebroadcasting new versions of the spending transaction, and spending
> from a transaction that is confirmed.

Correct, it might be desirable to give a misbehaving node a papercut by
letting their update transaction confirm (taking their fee along with
it) and then reacting to the outdated update by overriding the effects
with a new update-settlement pair.

So, while being able to react to a transaction in the memory pool early
might be a nice addition, it is not strictly required for safety of the
protocol. I say nice addition, because it can allow replacing the
outdated transaction directly, thus saving the misbehaving node from the
fee papercut, but also save a bit of blockspace which that fee would
have paid for, and leave it available for other transactions.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

[Christian Decker via bitcoin-dev]

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:
> > After talking with Christina
>
> Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke.
>
> Cheers,
> aj, hoping he typed one of those right, at least...
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Statechain implementations

[Christian Decker via bitcoin-dev]

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. Because of
> this, you can't include a fee, and will instead need to have a second
> output for CPFP. This way a previous owner will at least have to pay
> the fee if they want to publish it. Note that it's still an
> improvement, because even if the kickoff transaction gets posted, it
> basically becomes no different than what it would have been, had you
> not used a kickoff transaction at all.

It might be worth adopting the late fee binding we have in eltoo by
having the kickoff transaction input spending the funding tx signed with
sighash_single. This works because we only have 1 input and 1 output
that we really care about, and can allow others to attach fees at
will. That'd at least remove the need to guess the feerate days or
months in advance and thus having to overestimate.  

> Regarding modification 2, I like it a lot conceptually. It hadn't
> occurred to me before, and it's a clear security improvement. The only
> question is something Greg Sanders mentioned: whether it's enough to
> justify the added complexity of using 2P ECDSA. The alternative would
> be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> possibly).

Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?

> I'm looking forward to seeing statechains become a reality.

That'd indeed be great :-)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 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].
>
> Hey Christian, thanks for the write up!
>
>> ## Open questions
>> The questions that remain to be addressed are the following:
>> 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout[?]
>> 2.  Is there strong support or opposition to the chaperone signatures[?]
>> 3.  The same for output tagging / explicit opt-in[?]
>> 4.  Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
>> confusion and make for simpler discussions in the end.
>
> I think there's an important open question you missed from this list:
> (1.5) do we really understand what the dangers of noinput/anyprevout-style
> constructions actually are?
>
> My impression on the first 3.5 q's is: (1) yes, (1.5) not really,
> (2) weak opposition for requiring chaperone sigs, (3) mixed (weak)
> support/opposition for output tagging.
>
> My thinking at the moment (subject to change!) is:
>
>  * anyprevout signatures make the address you're signing for less safe,
>which may cause you to lose funds when additional coins are sent to
>the same address; this can be avoided if handled with care (or if you
>don't care about losing funds in the event of address reuse)
>
>  * being able to guarantee that an address can never be signed for with
>an anyprevout signature is therefore valuable; so having it be opt-in
>at the tapscript level, rather than a sighash flag available for
>key-path spends is valuable (I call this "opt-in", but it's hidden
>until use via taproot rather than "explicit" as output tagging
>would be)
>
>  * receiving funds spent via an anyprevout signature does not involve any
>qualitatively new double-spending/malleability risks.
>
>(eltoo is unavoidably malleable if there are multiple update
>transactions (and chaperone signatures aren't used or are used with
>well known keys), but while it is better to avoid this where possible,
>it's something that's already easily dealt with simply by waiting
>for confirmations, and whether a transaction is malleable is always
>under the control of the sender not the receiver)
>
>  * as such, output tagging is also unnecessary, and there is also no
>need for users to mark anyprevout spends as "tainted" in order to
>wait for more confirmations than normal before considering those funds
>"safe"

Excellent points, I had missed the hidden nature of the opt-in via
pubkey prefix while reading your proposal. I'm starting to like that
option more and more. In that case we'd only ever be revealing that we
opted into anyprevout when we're revealing the entire script anyway, at
which point all fungibility concerns go out the window anyway.

Would this scheme be extendable to opt into all sighash flags the
outpoint would like to allow (e.g., adding opt-in for sighash_none and
sighash_anyonecanpay as well)? That way the pubkey prefix could act as a
mask for the sighash flags and fail verification if they don't match.

> I think it might be good to have a public testnet (based on Richard Myers
> et al's signet2 work?) where we have some fake exchanges/merchants/etc
> and scheduled reorgs, and demo every weird noinput/anyprevout case anyone
> can think of, and just work out if we need any extra code/tagging/whatever
> to keep those fake exchanges/merchants from losing money (and write up
> the weird cases we've found in a wiki or a paper so people can easily
> tell if we missed something obvious).

That'd be great, however even that will not ensure that every possible
corner case is handled and from experience it seems that people are
unwilling to invest a lot of time testing on a network unless their
money is on the line. That's not to say that we shouldn't try, we
absolutely should, I'm just not sure it alone is enough to dispell all
remaining doubts :-)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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, the business that I am talking about don't use "off
> the shelf" wallet options. It isn't a "let's switch from wallet A to wallet
> B" kind of situation. Usually this involves design from ground up with
> security considerations that businesses of scale need to consider (signing
> procedures and key handling being the most important!).

In this case I'd hope that the custom wallet designers/developers are
well-versed in the issues they might encounter when implementing their
wallet. This is especially true if they decide to opt into using some
lesser known sighash flags, such as noinput, that come with huge warning
signs (I forgot to mention that renaming noinput to noinput_dangerous is
also still on the table).

>>Because scripts signed with no_input signatures are only really exchanged
> and used for off-chain negotiations, very few should ever appear on chain.
> Those that do should represent non-cooperative situations that involve
> signing parties who know not to reuse or share scripts with these public
> keys again. No third party has any reason to spend value to a
> multisignature script they don't control, whether or not a no_input
> signature exists for it.
>
> Just because some one is your friend today, doesn't mean they aren't
> necessarily your adversary tomorrow. I don't think a signature being
> onchain really matters, as you have to give it to your counterparty
> regardless. How do you know your counterparty won't replay that
> SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on
> "good-will" for their counter parties for security.
>
>>As I mentioned before, I don't think the lazy wallet designer advantage is
> enough to justify the downsides of chaperone signatures. One additional
> downside is the additional code complexity required to flag whether or not
> a chaperone output is included. By comparison, the code changes for
> creating a no_input digest that skips the prevout and prevscript parts of a
> tx is much less intrusive and easier to maintain.
>
>>I want to second this. The most expensive part of wallet design is
> engineering time. Writing code that uses a new sighash or a custom
> script with a OP_CODE is a very large barrier to use. How many wallets
> support multisig or RBF? How much BTC has been stolen over the entire
> history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE
> vs ECDSA nonce reuse
>
> I actually think lazy wallet designer is a really compelling reason to fix
> footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy
> wallet design. Now we have non-malleable transactions in the form of segwit
> (yay!) that prevent this exploit. We can wish that the Mt Gox wallet
> designers were more aware of bitcoin protocol vulnerabilities, but at the
> end of the day the best thing to do was offering an alternative that
> circumvents the vulnerability all together.

It's worth pointing out that the transaction malleability issue and the
introduction of a new sighash flag are fundamentally different: a wallet
developer has to take active measures to guard against transaction
malleability since it was present even for the most minimal
implementation, whereas with sighash flags the developers have to
actively add support for it. Where transaction malleability you just had
to know that it might be an issue, with noinput you actively have to do
work yo expose yourself to it.

I'd argue that you have to have a very compelling reason to opt into
supporting noinput, and that's usually because you want to support a
more complex protocol such as an off-chain contract anyway, at which
point I'd hope you know about the tradeoffs of various sighash flags :-)

> Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have
> virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly
> every transaction. The feature -- ECDSA in this case -- was managed to be
> done wrong by wallet developers causing fund loss. Unfortunately we can't
> protect against this type of bug in the protocol.
>
> If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it
> doesn't matter if they are secure or insecure. I'm hopefully that offchain
> protocols will achieve wide adoption, and I would hate to see money lost
> because of this. Even though they aren't used, in my OP I do advocate for
> fixing these.

I do share the feeling that we better make a commonly used sighash flag
as useable and safe as possible, but it's rather unrealistic to have a
developer that is able to implement a complex off-chain system, but
fails to understand the importance of using the correct sighash flags in
their wallet. That being said, I think this c

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 `SIGHASH_NOINPUT` use, is 
> *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any 
> other SegWit v1 output.
>
> I propose the below instead:
>
> * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`.
> * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`.
>
> Then, on usage:
>
> * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 
> outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 
> `OP_CHECKSIG_ADD` sequence.
> * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot 
> internal point, with a MAST branch containing a Tapscript v16 with `OP_1 
> OP_CHECKSIG`.
>
> This solves both concerns:
>
> * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit 
> to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is 
> unuseable to claim it.
> * If a UTXO used for an offchain protocol ends up in a cooperative-resolution 
> state, nobody has to know that a Tapscript v16 branch existed that could have 
> used `SIGHASH_NOINPUT`.
>
> Again, my objection to output tagging is that it is **publicly visible** as 
> soon as the funding transaction is confirmed onchain that this is a special 
> output used for a Decker-Russell-Osuntokun construction, greatly damaging 
> privacy.
> But if this fact is kept secret *unless* the very specific case of unilateral 
> uncooperative enforcement, then it is quite fine with me.
>
> Would this alternate proposal hold better muster?

Intriguing idea, this would be an invisible tagging, since the opt-in to
noinput and friends is hidden inside the committed script, which only
gets revealed whenever we actually need it.

For eltoo this would mean that the funding output would be invisibly
tagged, and the cooperative close would use the taproot pubkey, while
the uncooperative close, which would require noinput opt-in, reveals the
script, proving prior opt-in, and provides a matching signature.

If I'm not mistaken this would require AJ's alternative pubkey encoding
(0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 large sums of
> money that is stored in these addreses.
>
> It is my understanding with this part of BIP118
>
>>Using NOINPUT the input containing the signature no longer references a
> specific output. Any participant can take a transaction and rewrite it by
> changing the hash reference to the previous output, without invalidating
> the signatures. This allows transactions to be bound to any output that
> matches the value committed to in the witness and whose witnessProgram,
> combined with the spending transaction's witness returns true.
>
> if an exchange were to once produce a digital signature from that cold
> storage address with a SIGHASH_NOINPUT signature, that signature can be
> replayed again and again on the blockchain until their wallet is drained.
> This might be able to mitigated since the signatures commit to outputs,
> which may be small in value for the transaction that SIGHASH_NOINPUT was
> used. This means that an exchange could move coins from the address with a
> larger transaction that spends money to a new output (and presumably pays a
> higher fee than the smaller transactions).

Thanks for sharing your concerns Chris, I do agree that noinput and
friends are a very sharp knife that needs to be treated carefully, but
ultimately it's exactly its sharpness that makes it useful :-)

> ### Why does this matter?
>
> It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
> protocols like Lightning. This gives us the building blocks for enforcing
> specific offchain states to end up onchain [2].
>
> Since this tool is useful, we can presume that it will be integrated into
> the signing path of large economic entities in bitcoin -- namely exchanges.
> Many exchanges have specific signing procedures for transactions that are
> leaving an exchange that is custom software. Now -- presuming wide adoption
> of off chain protocols -- they will need to have a _second unique signing
> path that uses SIGHASH_NOINPUT_.
>
> It is imperative that this second signing path -- which uses
> SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
> controls an exchanges onchain funds. If this were to happen, fund lost
> could occur if the exchange is reusing address, which seems to be common
> practice.

Totally agreed, and as you point out, BIP118 is careful to mandate
separate private keys be used for off-chain contracts and that the
off-chain contract never be mixed with the remainder of your funds. The
way eltoo uses noinput we selectively open us up to replay attacks
(because that's what the update mechanism is after all) by controlling
the way the transactions can be replayed very carefully, and any other
use of noinput would need to make sure to have the same guarantees.
However, once we have separated the two domains, we can simply use a
separate (hardened) derivation path from a seed key, and never mix them
afterwards. We never exchange any private keys, so even leaking info
across derived keys is not an issue here.

> This is stated here in BIP118:
>
>>This also means that particular care has to be taken in order to avoid
> unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
> used, unless it is explicitly needed for the application, e.g., it MUST NOT
> be a default signing flag in a wallet implementation. Rebinding is only
> possible when the outputs the transaction may bind to all use the same
> public keys. Any public key that is used in a NOINPUT signature MUST only
> be used for outputs that the input may bind to, and they MUST NOT be used
> for transactions that the input may not bind to. For example an application
> SHOULD generate a new key-pair for the application instance using NOINPUT
> signatures and MUST NOT reuse them afterwards.
>
> This means we need to encourage onchain hot wallet signing procedures to be
> kept separate from offchain hot wallet signing procedures, which introduces
> more complexity for key management (two keychains).

This is already the case: off-chain systems always require access to the
signing key in real-time in order to be useful. If any state change is
performed in a channel, even just adjusting fees or receiving a payment,
requires the signature from the key associated with the channel. With
high security on-chain systems on the other hand you should never have a
hot key that automatically signs off on transfers without human
intervention. So I find it unlikely that mandating the on-chain keys to
be kept separate from off-chain keys is any harder than what should be
done with the current systems.

> One (of the few) upsides of the current Lightning penalty mechanism is that
> fund loss can be contained to

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 trigger transaction is not in fact
> necessary for Decker-Russell-Osuntokun: any update transaction could
> spend the funding transaction output directly, and thereby start the
> relative timelock.  At least, if we could arrange the funding
> transaction output to be spendable directly using `SIGHASH_NOINPUT` or
> variants thereof.

This is the case in which we don't have a pre-signed settlement
transaction (or in this case refund transaction) that uses a relative
timelock. In order to have a refund transaction we would need to have
the first update and settlement pair be signed before funding (otherwise
the funder isn't sure she is getting her funds back). Since that first
update and settlement pair do not need to be rebound (they can only ever
be bound to the funding transaction) they can be signed without
noinput/anyprevoutanyscript. If we use output tagging we would mandate
that this first update must be published, so that the funding output is
indistinguishable from a normal output, and the first update switches
from non-noinput/anyprevoutanyscript to enabling it. Collaborative
closes are still indistinguishable, unilateral closes require the
switch, but then would be identifiable anyway.

The one downside I can see is that we now mandate that unilateral closes
also publish the first update, which is a bit annoying.

>> While I do agree that we should keep outputs as unidentifiable as
>> possible, I am starting to question whether that is possible for
>> off-chain payment networks since we are gossiping about the existence of
>> channels and binding them to outpoints to prove their existence anyway.
>
> * Lightning supports unpublished channels, so we do not gossip some outpoints 
> even though they are in fact channels underneath.
>   * I confess the existence of unpublished channels in the spec fails to 
> summon any reaction other than incredulity from me, but they exist 
> nonetheless, my incredulity notwithstanding.

That is true, we do however selectively tell others about the channel's
existence (in invoices, our peers, ...) so I wouldn't consider that to
be the most secret information :-)

As for why they exist: nodes need to have the option of not announcing
their channels to reduce the noise in the network with channels that are
unlikely to be useable in order to forward payments. If every node were
to announce their channels we'd have a much larger routing table, mostly
consisting of unusable channels going to leafs in the
network. Furthermore, the sheer threat that there might be unannounced
channels adds uncertainty for attackers trying to profile nodes: "I see
only my channel with my peer, but he might have unannounced channels, so
I can't really tell whether the payment I forwarded to it is destined
for it or one of its unannounced peers".

> * Historical channels that have been cooperatively closed are no longer 
> normally gossiped, so the fact that they used to be channels is no longer 
> widely broadcast, and may eventually be forgotten by most or all of the 
> network.
>   * This means anyone who wants to record the historical use of Lightning 
> will have to retain the information themselves, rather than delegating it to 
> fullnodes everywhere.

Good point, it requires storing the ephemeral data from gossip, that's
not all that hard, but I agree that it puts up a small barrier for
newcomers.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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, then checks that hash to the signature.
>
> This is equivalent to `SIGHASH_NOINPUT`.
>
> Yet as an opcode, it would be possible to embed in a Taproot script.
>
> For example, a Decker-Russell-Osuntokun would have an internal Taproot
> point be a 2-of-2, then have a script `OP_1
> OP_CHECKSIG_WITHOUT_INPUT`.  Unilateral closes would expose the hidden
> script, but cooperative closes would use the 2-of-2 directly.
>
> Of note, is that any special SCRIPT would already be supportable by Taproot.
> This includes SCRIPTs that may potentially lose funds for the user.
> Yet such SCRIPTs are already targetable by a Taproot address.
>
> If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not
> so concerned about Taproot abuse?

That would certainly be another possibility, which I have not explored
in detail so far. Due to the similarity between the various signature
checking op-codes it felt that it should be a sighash flag, and it
neatly slotted into the already existing flags. If we go for a separate
opcode we might end up reinventing the wheel, and to be honest I feared
that proposing a new opcode would get us into bikeshedding territory
(which I apparently failed to avoid with the sighash flag anyway...).

The advantage would be that with the sighash flag the spender is in
charge of specifying the flags, whereas with an opcode the output
dictates the signature verification modalities. The downside is the
increased design space.

What do others think? Would this be an acceptable opt-in mechanism that
addresses the main concerns?

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 protect the outputs.  That is the reason why we
> would prefer to not support P2SH-wrapped Taproot even though
> P2SH-wrapping was intended to cover all future uses of SegWit,
> including SegWit v1 that Taproot will eventually get.

That is a bit reductive if you ask me. Taproot brings a number of
improvements such as the reduction of on-chain footprint in the
collaborative spend case, the hiding of complex logic in that case, and
yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be
to make everything look identical to the outside observer, but saying
that separating outputs into two coarse-grained domains is equivalent to
throwing the baby out with the bath-water :-)

That being said, I should clarify that I would prefer not having to make
special accomodations on top of the raw sighash_noinput proposal, for
some perceived, but abstract danger that someone might shoot themselves
in the foot. I think we're all old enough not to need too much
handholding :-)

Output tagging is my second choice, since it minimizes the need for
people to get creative to work around other proposals, and minimizes the
on-chain footprint, and finally chaperone signatures are my least
preferred option due to its heavy-handed nature and the increased cost.

> Indeed, if it is output tagging that gets into Bitcoin base layer, I
> would strongly suggest the below for all Decker-Russell-Osuntokun
> implementations:
>
> * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, 
> confirmed onchain
> * A "translator transaction" spending the above and paying out to a SegWit 
> v16 output-tagged output, kept offchain.
> * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` 
> spending the translator transaction output.
> * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` 
> spending the update transaction output.

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 :-)

> The point regarding use of a commonly-known privkey to work around
> chaperone signatures is appropriate to the above, incidentally.  In
> short: this is a workaround, plain and simple, and one wonders the
> point of adding *either* chaperones *or* output tagging if we will, in
> practice, just work around them anyway.

Exactly, why introduce the extra burden of chaperone signatures or
output tagging if we're just going to sidestep it?

> Again, the *more* important point is that special blockchain
> constructions should only be used in the "bad" unilateral close case.
> In the cooperative case, we want to use simple plain
> bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot
> SegWit v1 addresses, to increase the anonymity set of all uses of
> Decker-Russell-Osuntokun and other applications that might use
> `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple
> bip-schnorr-signed n-of-n cases when the protocol is completed
> successfully by all participants).

While I do agree that we should keep outputs as unidentifiable as
possible, I am starting to question whether that is possible for
off-chain payment networks since we are gossiping about the existence of
channels and binding them to outpoints to prove their existence anyway.

Not the strongest argument I know, but there's little point in talking
ideal cases when we need to weaken that later again. 

>> Open questions
>>
>> ---
>>
>> The questions that remain to be addressed are the following:
>>
>> 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout. While at the CoreDev meeting I think everybody agreed that
>> these proposals a useful, also beyond eltoo, not everybody could be
>> there. I'd therefore like to elicit some feedback from the wider 
>> community.
>
> I strongly agree that `NOINPUT` is useful, and I was not able to attend 
> CoreDev (at least, not with any human fleshbot already known to you --- I 
> checked).

Great, good to know that I'm not shouting into the void, and that I'm
not just that crazy guy trying to get his hairbrained scheme to work :-)

>> 2.  Is there strong support or opposition to the chaperone signatures
>> introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
>> formulate a concrete set of pros and contras, rather than talk about
>> abstract dangers or advantages.
>
> No opposition, we will just work around this by publishing a common
> known private key to use for all chaperone signatures, since all

[bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Christian Decker via bitcoin-dev]

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 the long e-mail. I wanted to give enough context and describe the
various tradeoffs so people don't have to stitch them together from memory. If
you're impatient there are a couple of open questions at the bottom)

Both proposals are ways to allow rebinding of transactions to new outputs, by
adding a sighash flag that excludes the output when signing. This allows the
transaction to be bound to any output, without needing a new signature, as
long as output script and input script are compatible, e.g., the signature
matches the public key specified in the output.

BIP-118 is limited to explaining the details of signature verification, and
omits anything related to deployment and dependency on other proposals. This
was done in order not to depend on bip-taproot which is also in draft-phase
currently, and to allow deployment alongside the next version of segwit
script. `bip-anyprevout` builds on top of BIP-118, adding integration with
`bip-taproot`, chaperone signatures, limits the use of the sighash flag to
script path spends, as well as a new pubkey serialization which uses the first
byte to signal opt-in.

I'd like to stress that both proposals are complementary and not competing,
which is something that I've heard a couple of times.

There remain a couple of unclear points which I hope we can address in the
coming days, to get this thing moving again, and hopefully get a new tool in
our toolbox soon(ish).

In the following I will quote a couple of things that were discussed during
the CoreDev meeting earlier this year, but not everybody could join, and it is
important that we engage the wider community, to get a better picture, and I
think not everybody is up-to-date about the current state.


## Dangers of `sighash_noinput`

An argument I have heard against noinput is that it is slightly less complex
or compute intensive than `sighash_all` signatures, which may encourage wallet
creators to only implement the noinput variant, and use it indiscrimi-
nately. This is certainly a good argument, and indeed we have seen at least
one developer proposing to use noinput for all transactions to discourage
address reuse.

This was also mentioned at CoreDev [6]:

> When [...] said he wanted to write a wallet that only used SIGHASH\_NOINPUT,
> that was pause for concern. Some people might want to use SIGHASH\_NOINPUT as 
> a
> way to cheapen or reduce the complexity of making a wallet
> implementation. SIGHASH\_NOINPUT is from a purely procedural point of view
> easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're hashing
> less. It's way faster. That concern has been brought to my attention and it's
> something I can see. Do we want to avoid people being stupid and shooting
> themselves and their customers in the foot? Or do we treat this as a special
> case where you mark we're aware of how it should be used and we just try to
> get that awareness out?

Another issue that is sometimes brought up is that an external user may
attempt to send funds to a script that was really part of a higher-level
protocol. This leads to those funds becoming inaccessible unless you gather
all the participants and sign off on those funds. I don't believe this is
anything new, and if users really want to shoot themselves in the foot and
send funds to random addresses they fish out of a blockexplorer there's little
we can do. What we could do is make the scripts used internally in our
protocols unaddressable (see output tagging below), removing this issue
altogether.


## Chaperone signatures

Chaperone signatures are signatures that ensure that there is no third-party
malleability of transactions. The idea is to have an additional signature,
that doesn't use noinput, or any of its variants, and therefore needs to be
authored by one of the pubkeys in the output script, i.e., one or more of the
participants of the contract the transaction belongs to. Concretely in eltoo
we'd be using a shared key known to all participants in the eltoo instance, so
any participant can sign an update to rebind it to the desired output.

Chaperone signatures have a number of downsides however:

-   Additional size: both the public key and the signature actually need to be
stored along with the real noinput signature, resulting in transfer,
computational and storage overhead. We can't reuse the same pubkey from the
noinput signature since that'd require access to the matching privkey which
is what we want to get rid of using noinput in the first place.
-   Protocols can still simply use a globally known privkey, voiding the
benefit of chaperone signatures, since third-parties can sign again. I
argue that third-party malleability

Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo

[Christian Decker via bitcoin-dev]

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 point of requiring an n-of-n signature is:
>
> * By using an n-of-n signatory where *you* are a signer, you are completely 
> immune to Sybil attacks: even if everybody other than *you* in the signatory 
> set is secretly just one entity, this is no different from doing a 2-of-2 
> bog-standard boring sleepy Zz Poon-Dryja Lightning Network channel.
>   * Any m-of-n signatory where strictly m < n allows anybody with the ability 
> to run m nodes to outright steal money from you.
> * As processing power is cheap nowadays, there is no m that can be 
> considered safe.
>   Your alternative is to fall back on proof-of-work, but that just means 
> going onchain, so you might as well just do things onchain.
>   * This is why 2-of-2 channels work so well, it's the minimum useable 
> construction and any multiparty construction, when Sybilled, devolves to a 
> 2-of-2 channel.
>
> So the n-1 participants would have to be very very very carefully limited in 
> what they can do.
> And if the only "right" the n-1 participants can do is to force the nth 
> participant to claim its funds onchain, then that is implementable with a 
> transaction doing just that, which is pre-signed by the nth participant and 
> given to participants 1..n-1.

Just to be clear, I do *not* want to support uncooperative splice-outs.
This is due to their need to either pre-sign a splice-out of the party
like I explained further down, or it requires encumbering whatever we
build on top in order to do a fast-reopen.

But I do think there is value in exploring what the options are :-)

>> Notice that we are negotiating whether or not to apply generic
>> transactions to a shared state. This also means that there is no direct
>> relationship between the ownership of an output and the ID signing off
>> on a change.
>>
>> The privacy guarantees are identical to Bitcoin on-chain, with the one
>> caveat that we may identify the proposing participant, but we can defend
>> against this by mixing as you propose.
>
> Yes, but if we later combine this with allowing multiilateral kick-out
> of a member that is unresponsive (i.e. we splice out the outputs it
> has at least partial ownership of, and keep only those that are owned
> only by the remaining members), then each member would have to
> honestly claim which UTXOs it is interested in keeping after it is
> kicked out of the membership set, defeating this point entirely.  I
> believe this is roughly what you propose in the next point, and
> roughly what you would want with the "n-1 participants" earlier.

That is indeed the issue I explained further down:

> It also adds the complexity of having to identify which participant is
> the co-owner of an output, otherwise I can claim ownership of an
> unrelated output and force that to move on-chain by including it in my
> fallback and then becoming unresponsive (added rounds of communication
> can help here, but are cumbersome).

Claiming ownership would then involve providing a valid input script
(disregarding any timelocks) that could spend the output under some
condition. Others would have to verify this proof-of-ownership before
accepting the node's self-splice-out before accepting it.

>> It may be a bit much added complexity for a small complexity to be
>> honest, hopefully this won't be needed too often :-)
>
> Statement makes no sense, unless you meant to say "It may be a bit
> much complexity for a small benefit" or similar?

Indeed, that was a weird sentence :-) I did mean that it is a lot of
complexity for very little benefit :-)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo

[Christian Decker via bitcoin-dev]

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 that a close of an update mechanism does not require the
> close of any hosted update mechanisms, or more prosaically, "close of
> channel factory does not require close of hosted channels".  This is
> true for both unilateral and cooperative closes.
>
> Of course, the most likely reason you want to unilaterally close an
> outer mechanism is if you have some contract in some deeply-nested
> mechanism that will absolute-locktime expire "soon", in which case you
> have to close everything that hosts it.  But for example if a channel
> factory has channels A B C and only A has an HTLC that will expire
> soon, while the factory and A have to close, B and C can continue
> operation, even almost as if nothing happened to A.

Indeed this is something that I think we already mentioned back in the
duplex micropayment channel days, though it was a bit hidden and only
mentioned HTLCs (though the principle carries over for other structures
built on the raw update mechanism):

> The process simply involves one party creating the teardown
> transaction, both parties signing it and committing it to the
> blockchain. HTLC outputs which have not been removed by agreement can
> be copied over to the summary transaction such that the same timelocks
> and resolution rules apply.

Notice that in the case of eltoo the settlement transaction is already
the same as the teardown transaction in DMC.

>> membership change (ZmnSCPxj ritual):
>> * when channel parties want to leave or add new members to the channel
>> * close and reopen a new channel via something like a channel splicing 
>> transaction to the layer one blockchain
>> * should be optimized for privacy and low on-chain fees paid for by parties 
>> entering and leaving the channel
>
> Assuming you mean that any owned funds will eventually have to be
> claimed onchain, I suppose this is doable as splice-out.
>
> But note that currently we have some issues with splice-in.
>
> As far as I can tell (perhaps Lisa Neigut can correct me, I believe
> she is working on this), splice-in has the below tradeoffs:
>
> 1.  Option 1: splice-in is async (other updates can continue after all 
> participants have sent the needed signatures for the splice-in).
> Drawback is that spliced-in funds need to be placed in a temporary
> n-of-n, meaning at least one additional tx.

Indeed this is the first proposal I had back at the Milan spec meeting,
and you are right that it requires stashing the funds in a temporary
co-owned output to make sure the transition once we splice in is
atomic. Batching could help here, if we have 3 participants joining they
can coordinate to set the funds aside together and then splice-in at the
same time. The downside is the added on-chain transaction, and the fact
that the funds are not operational until they reach the required depth
(I don't think we can avoid this with the current security guarantees
provided by Bitcoin). Notice that there is still some uncertainty
regarding the confirmation of the splice-in even though the funds were
stashed ahead of time, and we may end up in a state where we assumed
that the splice-in will succeed, but the fees we attached turn out to be
too low. In this case we built a sandcastle that collapses due to our
foundation being washed away, and we'd have to go back and agree on
re-splicing with corrected fees (which a malicious participant might
sabotage) or hope the splice eventually confirms.

> 2.  Option 2: splice-in is efficient (only the splice-in tx appears onchain).
> Drawback is that subsequent updates can only occur after the splice-in tx 
> is deeply confirmed.
> * This can be mitigated somewhat by maintaining a pre-splice-in
> and post-splice-in mechanism, until the splice-in tx is deeply
> confirmed, after which the pre-splice-in version is discarded.
>   Updates need to be done on *both* mechanisms until then, and any
> introduced money is "unuseable" anyway until the splice-in tx
> confirms deeply since it would not exist in the pre-splice-in
> mechanism yet.

This is the more complex variant we discussed during the last
face-to-face in Australia, and it seemed to me that people were mostly
in favor of doing it this way. It adds complexity since we maintain
multiple variants (making it almost un-implementable in LN-penalty),
however the reduced footprint, and the uncertainty regarding
confirmations in the first solution are strong arguments in favor of
this option.

> But perhaps a more interesting thing (and more in keeping with my
> sentiment "a future where most people do not typically have
> single-signer ownership of coins onchain") would be to transfer funds
> from one multipart

[bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

[Christian Decker via bitcoin-dev]

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 and simplifies the reasoning about their relative
security.

Since I don't like huge e-mails myself and I'm about to write one,
here's a quick TL;DR:

> Using the clean separation of protocol layers provided by eltoo we can
> reconcile many on-chain and off-chain concepts, and simplify the
> reasoning to build more complex functionality beyond simple
> HTLCs. Bitcoin transactions are a natural fit to represent proposed
> off-chain state-changes while they are being negotiated.


### Clean separation of protocol layers

One of te big advantages of eltoo over other off-chain update mechanisms
is that it provides strong guarantees regarding the state that will
eventually end up confirmed on-chain. If parties in an eltoo off-chain
contract agree on an update, we can be certain (within eltoo's security
assumptions) that this is the state that will eventually confirm
on-chain, if no newer states are agreed.

In particular it means that we are guaranteed no earlier state can leak
onto the chain, keeping anything we build on top of the update layer
unencumbered since it doesn't have to deal with this case.

This is in stark contrast to the penalty update mechanism, where
old/revoked states can leak on-chain, resulting in anything built on top
of the penalty mechanism having to deal with that eventuality. For
example if we look at HTLCs as specified [1] we see that it needs an
additional revokation path for the case the commitment transaction that
created this HTLC output is confirmed:

```btcscript
# To remote node with revocation key
OP_DUP OP_HASH160  OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
 OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160  OP_EQUALVERIFY
2 OP_SWAP  2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP  OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
```

The update mechanism bleeding into the other layers is rather cumbersome
if you ask me, and complicates the reasoning about security. Having to
thread the penalty through outputs created by the off-chain contract may
also not work if we deal with more than 2 parties, since penalties
always steal all the funds, regardless of whether the output belonged to
the cheater or not (see asymmetry vs symmetry argument from the paper
[2]).

With the clean separation we get from eltoo we can concentrate on
building the output scripts we'd like to have without having to thread
penalties through them. This reduces the complexity and our on-chain
footprint.

The update layer now exposes only two very simple operations:
`add_output` and `remove_output` (this should sound very familiar :-p).


### Ownership and atomic update model

Now that we have a solid update layer, which ensures that agreed upon
states will eventually be reflected on-chain, we can turn our attention
to the next layer up: the negotiation layer. Each output in our
agreed-upon state needs to be assigned one or more owners. The owners
are the participants that need to sign off on removal of an output and
the creation of new outputs which redistribute the funds contained in
the removed outputs to newly created outputs.

In addition we need to ensure that multiple `remove_output` and
`add_output` are guaranteed to be applied atomically. By creating a
datastructure that lists a number of operations that are to either be
applied to the current state or discarded, we can have arbitrary complex
changes of ownership, and the newly created outputs can have arbitrary
scripts.

If all of this sounds familiar that's because this is exactly the UTXO
model and the transaction structure we have in Bitcoin. We
collaboratively manage funds bound to some outputs (UTXO) and can change
their ownership and allocation over time (transactions).

This means that a subset of the participants in an off-chain contract
can negotiate among themselves how to redistribute funds, join and split
them in an arbitrary fashion, without the rest of the contract being
involved. The end result is a valid Bitcoin transaction that spends some
outputs of the current state, and is signed by the owners. The
transaction can then be presented to the entire group, and applied to
the state. Applying the transaction flattens multiple transactions built
on top of the current state into a new state (similar to transaction
cut-through in mimblewimble).

Using transactions as a means to represent off-chain negotiations, and
then applying them to the off-chain state via cut-through has a number
of advantages over similar schemes:

- Even if we failed to update the off-chain state, the transactions
  building on top of it are 

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

[Christian Decker via bitcoin-dev]

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 -> update 3 [TAGGED] -> settlement 3 -> claim
>
>funding tx -> update 3 [TAGGED] -> 
>  update 4 [TAGGED,NOINPUT] -> 
>settlement 4 [TAGGED,NOINPUT] -> 
>claim [NOINPUT]
>
> In the cooperative case, no output tagging needed.

I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Christian Decker via bitcoin-dev]

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 timeout of
>> the CLTV would start ticking down the exact moment the setup transaction
>> is confirmed, hence whatever effect we are trying to achieve with that
>> timelock is limited, and we have a limit to the total lifetime of the
>> channel.
>
> CLTV is absolute locktime. Only CSV will have the “time ticking”
> issue, but that’s not used here. The required locktime  is many
> years in the past. To collaboratively close, you just need to sign
> with SIGHASH_ALL, with a locktime s+1.

Correct, we're using the CLTV here as a weird "compare two numbers that
are committed to in the signatures" operation, by using locktimes in the
past as you correctly point out.

> I think the use of OP_CSV (BIP112) is not needed here (although it
> doesn’t really harm except taking a few more bytes). All you need is
> to sign the settlement tx with a BIP68 relative locktime. Since this
> is a 2-of-2 branch, both parties need to agree with the relative
> locktime, so it is not necessary to restrict it through OP_CSV

I keep forgetting about BIP68, but you're right, that should be
sufficient for our use-case and would safe us a few bytes.

>> In the unilateral case, one party isn't there anymore, or refuses to
>> sign. So we take the trigger transaction (not signed with NOINPUT) and
>> the latest update_n transaction (signed with NOINPUT) and broadcast
>> them. Then we wait for the CSV timeout to expire, and then send the
>> settlement transaction, which gives us the enforcement of the latest
>> state that we agreed on. The chain sees a setup transaction and a
>> trigger transaction (normal transactions for all intents and purposes,
>> except for the output script of the trigger, but we can hide that with
>> taproot), followed by two more transactions which are signed with
>> NOINPUT. So 4 transactions in the worst case, of which 2 are special,
>> and 2 transactions in the good case.
>> 
>> 
>> So all in all I think it's a tradeoff between having a larger on-chain
>> footprint (4 txs vs 3 txs in the worst case) and putting a fixed
>> lifetime on the channel for the refund case if one party disappears
>> right away. We'll probably find out what acceptable parameters are for
>> these and where the cutoff points are :-)
>
> If no one is cheating (i.e. only the last update is broadcast), you
> always need only 3 txs. Think about this: every update tx could be a
> trigger tx, and you can settle directly on a trigger tx, so
> effectively you eliminate trigger tx.

I seem to keep mentally mixing different variants of the protocol in my
head. You are of course correct that the trigger and the update can be
considered the same, hence the 3 txs limit is right. Sorry for the
confusion :-(
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Christian Decker via bitcoin-dev]

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 setup output of the following
> script:  CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign

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 timeout of
the CLTV would start ticking down the exact moment the setup transaction
is confirmed, hence whatever effect we are trying to achieve with that
timelock is limited, and we have a limit to the total lifetime of the
channel.

> 3. They create the update tx 0, spending the setup output with NOINPUT
> and locktime = s+1, to the update-0 output with the script: IF 2 As0
> Bs0 2 CHECKMULTISIG ELSE  CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF

Update 0 is usually what I call the trigger transaction. It takes the
2-of-2 multisig from the setup transaction and translates it into the
two-branch output that further updates or settlements can be attached
to. The settlement transaction attached to the trigger / update 0
reflects the initial state of the channel, i.e., if A added 2 BTC and B
added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1
respectively, with the user's keys (this can also be considered the
refund in case of one party disappearing right away).

The second branch in the script you posted is the update branch, which is
not encumbered by a CSV, while the first branch is the one encumbered
with the CSV and is called the settlement branch since we'll be
attaching settlement txs to it.

The CLTV looks correct to me and ensures that we can only attach any
state >= s+1.

So just to show the output script for state `i` how I think they are
correct:

```
OP_IF
   OP_CSV 2   2 OP_CHECKMULTISIG
OP_ELSE
   OP_CLTV OP_DROP 2   2 OP_CHECKMULTISIG 
```

And the input scripts for the update tx and the settlement tx
respectively would be:

```
OP_FALSE  
```

and

```
OP_TRUE  
```

> 4. They create the settlement tx 0, spending the update-0 output with
> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs

If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH
equivalent) since segwit witnesses only allow pushes. Hence the script
in point 3 needs to add that :-)

> 5. They sign the setup tx and let it confirm

They also need to sign (but not broadcast) update_0, in order to allow
either party to initiate the closure if the counterparty become
unresponsive. The order in which settlement_0 and update_0 are signed is
not important by the way, so we can just batch these. The important part
is that signing the setup acts as a commitment.

> 6. To update, they create the update tx 1, spending the setup output
> with NOINPUT and locktime = s+2, to the update-1 output with the
> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE  CLTV DROP 2 Au Bu 2
> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the
> update-1 output with As1 and Bs1 using relative-locktime, with 2
> settlement outputs

The output script of the updates are identical to the ones in the
trigger or update_0 transaction, so they'd also need a CSV (this is why
committing to the script structure with masking still works).

> 7. To close the channel, broadcast update tx 1. Wait for several
> confirmations. And broadcast settlement-tx-1

We have to differentiate 2 cases: collaborative close and unilateral
close. In the collaborative close we come to a mutual agreement that
we'd like to take this latest state and settle. So we create a new
transaction that spends the setup output, and add outputs according to
the state we agreed upon, and we sign it. This transaction is
immediately valid, and does not need to be signed with NOINPUT. So all
the chain sees is a setup transaction with some inputs and one multisig
output (singlesig with Schnorr) and a collaborative close transaction
that spends the setup (also not signed with NOINPUT). About as normal as
transactions in Bitcoin can get.

In the unilateral case, one party isn't there anymore, or refuses to
sign. So we take the trigger transaction (not signed with NOINPUT) and
the latest update_n transaction (signed with NOINPUT) and broadcast
them. Then we wait for the CSV timeout to expire, and then send the
settlement transaction, which gives us the enforcement of the latest
state that we agreed on. The chain sees a setup transaction and a
trigger transaction (normal transactions for all intents and purposes,
except for the output script of the trigger, but we can hide that with
taproot), followed by two more transactions which are signed with
NOINPUT. So 4 transactions in the worst case, of which 2 are special,
and 2 t

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Christian Decker via bitcoin-dev]

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 either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?

I'm not aware of a way to combine the setup and trigger transaction. The
trigger transaction was introduced in order to delay the start of the
timeouts until a later time, to avoid having an absolute lifetime limit
and having really huge timeout. If we were to combine the trigger
transaction with the setup transaction (which is broadcast during
channel creation), all of those timeouts would start counting down
immediately, and we could just skip the trigger transaction
altogether. It'd be more interesting to combine update and trigger
transactions in a sort of cut-through combination, but that doesn't seem
possible outside of Mimblewimble.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Christian Decker via bitcoin-dev]

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 retraction :-)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Christian Decker via bitcoin-dev]

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 fee
> explicitly? Or in other words, are there situations where changing the
> set of inputs or outputs after signing is desired, but the net
> difference between them cannot change? If not, that would remove the
> need for NOFEE.

So the final proposal would be to append a new `hashValues` field to the
hashed representation, with `hashValues` just being the double SHA256 of
all values? In that case SINGLE needs to blank that hash, otherwise we'd
be committing to all inputs again.

Once we have that detail, we can start thinking about what it means to
commit to the fee vs. committing to the values. Since the fee is given
by the output values and the input values we only need to consider the
cases in which they can be modified.

 - NOINPUT (as in BIP118) commits to the value (and I can't think of a
   usecase where we'd want to change that), and that transparently
   extends to all other inputs.
 - For ANYONECANPAY can't really commit to a fee anyway so ANYONECANPAY
   would likely imply NOFEE.
 - With NONE all bets are off anyway, so no need to consider that :-)
 - SINGLE is a bit special, and for value commitments it reduces to the
   current commitment to its own value, for fee commitment it's hard to
   see a use of that commitment at all afaik (I think the combination
   SINGLE|NOFEE would always be used).

> * Do we need to keep the rule that sequence values of other inputs are
> only signed with default sighash? It feels cleaner to always sign the
> sequence values of all inputs that are included in the sighash anyway
> (so all of them, unless ANYONECANPAY or NOINPUT, which would make it
> sign only the current input's sequence value). If NOINPUT also blanks
> the sequence values (as currently specified by BIP118), and all input
> amounts are signed, that would make amounts/sequence values always be
> treated identically.

Single cannot commit to other the sequence of other inputs, otherwise
we're breaking SINGLE completely. As mentioned before NOINPUT doesn't
need to blank `hashSequence`, but I'm happy to make it match if that
makes implementations handle fewer cases.

> * If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of
> them can be encoded in just 2 bits using the
> PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns
> suggested.

So we'd end up enumerating the combinations rather than having
independent bits for each of them? This might save us storage bits, but
it'd also result in uglier code imho, not a strong feeling but might
come back to haunt us if we ever come up with something new :-)

> So a combined proposal:
> * All existing sighash flags, plus NOINPUT and MASK
> (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
> * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
> failing if not immediately followed by a push, or when appearing as
> last opcode in the script.
> * Signatures are 64 plus an optional sighash byte. A missing sighash
> byte implies ALL, and ALL cannot be specified explicitly.
> * The sighash is computed from the following:
>   * A 64-byte constant tag
>   * Data about the spending transaction:
> * The transaction version number
> * The hash of txins' prevouts+amounts+sequences (or nothing if 
> ANYONECANPAY)

This needs to be partially blanked for SINGLE as well, otherwise we
break SINGLE.

> * The hash of all txouts (or just the corresponding txout if
> SINGLE; nothing if NONE)
> * The transaction locktime
>   * Data about the output being spent:
> * The prevout (or nothing if NOINPUT)
> * The amount
> * The sequence number

I assume the sequence number here refers to the input being signed, not
the sequence number of the transaction output being spent :-) Might be
easier if we consider 3 parts: the spending transaction, the input being
signed, and the output (or TX) being spent.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Christian Decker via bitcoin-dev]

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 to the inputs, I
agree. I'm actually wondering if it makes sense to correct that
additional blanked field in BIP118 at all since it seems there is no
real use-case for NOINPUT that doesn't involve blanking the
`hashSequence` as well.

> I could see this *maybe* making sense if you at least committed to the
> values of each input's outpoint; since that would be an actual constraint?

BIP118 still commits to the value of the input being spent, i.e.,
6. value is not being blanked in the current proposal. This is on
purpose since we commit to the outputs, not committing to the input
values could end up with unexpected fees.

>> As for your proposal, I really like the `sighash_scriptmask` proposal,
>> and committing to the fees (with the `nofee` escape hatch) also works
>> seems also a nice fix. My one concern is that introducing a new opcode
>> to mask things in the sighash looks like a similar layering violation as
>> `codeseparator` was, but that's just a minor issue imho.
>
> I think OP_MASK is okay as far as layering goes, if you just think of it
> as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
> pseudocode a script like:
>
>  OP_CSV OP_DROP  OP_CHECKSIG
>
> and then decide  needs to be masked, you rewrite it as:
>
> [n] OP_CSV OP_DROP  OP_CHECKSIG
>
> indicating n is masked, and don't worry about the exact bytes that will
> encode the push, anymore than you currently worry about whether it's
> OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.
>
> As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
> not to be immediately followed by that PUSH, I think that all works
> out fine.

Agreed, that makes more sense :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Christian Decker via bitcoin-dev]

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. Anyonecanpay would
allow changing the number of inputs in an arbitrary fashion, while
`noinput` without the blanking would (in a weird roundabout way) still
commit to the number of inputs. Maybe we want to make that more explicit
by also hashing the number of inputs? But I can't think of a good
usecase for keeping that, with noinput.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Christian Decker via bitcoin-dev]

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 (since where it is needed we also use `sighash_single`),
so I'm tempted to remove that redundant blanking. It may not make a lot
of difference but it'd limit the ability to change the number of inputs
to a NOINPUT transaction (this now being the only field that commits to
the set of inputs).

As for your proposal, I really like the `sighash_scriptmask` proposal,
and committing to the fees (with the `nofee` escape hatch) also works
seems also a nice fix. My one concern is that introducing a new opcode
to mask things in the sighash looks like a similar layering violation as
`codeseparator` was, but that's just a minor issue imho.

Cheers,
Christian

Pieter Wuille via bitcoin-dev 
writes:
> Hello everyone,
>
> For future segwit versions, I think it would be good add a few things
> to the sighash by default that were overlooked in BIP143:
> * Committing to the absolute transaction fee (in addition to just the
> amount being spent in each input) would categorically remove concerns
> about wallets lying about fees to HW devices or airgapped signers.
> * Committing to the scriptPubKey (in addition to the scriptCode) would
> prevent lying to devices about the type of output being spent, even
> when the scriptCode is correct. As a reminder, the scriptCode is the
> actually executed script (which is the redeemscript in non-segwit
> P2SH, and the witnesscript in P2WSH/P2WPKH).
>
> As this implies additional information that may not be desirable to
> commit to in all circumstances, it makes sense to make these optional.
> This obviously interacts with SIGHASH_NOINPUT, which really adds two
> different ways of rebinding signatures to inputs:
> * Changing the prevout (so that the txid doesn't need to be known when
> the signature is created)
> * Changing the script (so that the exact scriptPubKey/redeemScript/...
> doesn't need to be known when the signature is created)
>
> Of course, the second implies the first, but do all use cases require
> both being able to change the prevout and (arbitrarily) changing the
> scriptPubKey? While BIP118 correctly points out this is secure if the
> same keys are only used in scripts with which binding is to be
> permitted, I feel it would be preferable if signatures/scripts would
> explicitly state what can change. One way to accomplish this is by
> indicating exactly what in a script is subject to change.
>
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> and SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, but:
>   * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> the subsequent opcode/push is removed.
>   * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
>   * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
>   * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>
> Cheers,
>
> -- 
> Pieter
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Christian Decker via bitcoin-dev]

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 all branches, and scriptCode
> is just one script branch). If yes, we could make this configurable.

There is the poor man's malleability fix that you get if you make only
the previous outpoint rewritable, but that use-case is better covered by
segwit already, and since both of our proposals would be for segwit
outputs only, I don't see a point in doing that.

> 2. Which of the following approaches is better?
> A) sign scriptPubKey in every cases except NOINPUT
> B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every 
> cases, including NOINPUT
> C) all of the above
> D) none of the above

What do we effectively gain by committing to the scriptPubkey type? Is
the concern here that we might run into ambiguity about whether this is
a MAST, P2SH, or similar output, allowing an attacker to sideload
unwanted effects?

> Option B is very easy to implement as SignatureHash() could
> distinguish the type by the size of scriptSig in TxTo. Option A is
> more complicated as GenericTransactionSignatureChecker needs to know
> the scriptPubKey.
>
> If the only reason for doing this is to allow hardware wallet to
> distinguish the segwit type, option B is probably enough. This is also
> compatible with eltoo.

Agreed on compatibility :-)

> Option A is useful when a hardware wallet reuses the same public key
> in different scripts, but it couldn’t be applied to NOINPUT
>
> 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use
> NOINPUT|SINGLE to allow fee pumping, since it is an
> one-input-one-output tx. This is not possible with the existing LN as
> the tx is one-input-two-output. If we had DUALOUTPUT which signs the
> matched and last output, fee-pumping would be possible in the existing
> LN.

That's a very strange concept, but it strongly relies on the structure
of the commitment, having two outputs. As soon as we have HTLCs included
in the commitment we no longer have 2 outputs (2 for the endpoints, and
1 as a base for the two-phase HTLC resolution), so this would be a
rather brittle fix or would require major restructuring of LN imho.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Christian Decker via bitcoin-dev]

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 to be smaller than the state number of the
transaction that is being rewritten. The state number that we bind to is
part of the `scriptPubKey`, so we can't commit to the `scriptPubKey` in
the signature since we don't know which output (and thus it's
scriptPubKey`) is at the time we sign.

If we are committing to `scriptPubKey` this whole way of enforcing order
in updates is no longer possible, and the only thing we actually get
from this change is a (very weak) malleability fix. The same argument
goes for `scriptCode`.

Cheers,
Christian

Johnson Lau  writes:
> After gathering some feedbacks I substantially revised the proposal. This 
> version focus on improving security, and reduces the number of optional 
> features.
>
> Formatted BIP and sample code at:
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
> https://github.com/jl2012/bitcoin/commits/sighash2
>
> The major new features compared with BIP143:
>
> 1. If signing all inputs, also sign all input value. BIP143 signature only 
> covers the value of the same input. In some cases this may not be adequate 
> for hardware wallet to determine the right amount of fees. Signing all input 
> values will secure any possible case.
> 2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
> design, previous scriptPubKey is signed as the scriptCode. However, this is 
> not the case with P2SH and segwit. Explicitly committing to the scriptPubKey 
> allows hardware wallet to confirm what it is actually signing (e.g. 
> P2SH-segwit vs. Native-segwit).
> 3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
> both scriptCode and scriptPubKey. This prevents signature replay if the same 
> public key is used in different scripts.
> 4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range 
> case.
> 5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
> 6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index 
> output. Described by gmaxwell at 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html 
> 
> 7. Signing the amount of fees (optional, yes by default). In case of not 
> signing all inputs or outputs, users may still want to commit to a specific 
> fee amount.
> 8. Signing the witness size (optional, yes by default). While segwit fixed 
> txid malleability, it is not a fix of script malleability. It may cause some 
> trouble if an attacker could bloat the witness and reduce the fee priority of 
> a transaction. Although the witness size is not malleable for most simple 
> scripts, this is not guaranteed for more complex ones. Such kind of size 
> malleability could be avoided if signatures commit to the size of witness.
>
> Any suggestions are welcomed. But I have the following questions:
>
> 1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it 
> should, because that helps avoid signature replay in some cases, and also 
> lets hardware wallets know what they are signing. I am asking this because 
> BIP118 proposes the opposite. I want to make sure I’m not missing something 
> here.
> 2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an 
> example use case is kickstarter, where individual supporters send money to 
> the last output for a kickstarter project, and send change to the matched 
> output. However, I doubt if this would be actually used this way, because the 
> kickstarter organiser could always take the money before the target is met, 
> by making up the difference with his own input. This is an inherent problem 
> for any anonymous kickstarter scheme. If these new SIGHASHs are not useful in 
> other applications, I am not sure if we should add them.
> 3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully 
> flexible way to sign a subset of outputs? The indexes of signed outputs are 
> put at the end of the signature, and the signature won’t commit to these 
> index values. Therefore, a third party could collect all transactions of this 
> kind and merge them into one transaction. To limit the sighash cost, number 
> of signed outputs might not be more than 2 or 3. Some potential problems: a) 
> code complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of 
> outputs to 256. 2-byte will use more space even for smaller txs; c) highly 
> variable signature size makes witness size estimation more difficult
> 4. Should we sign the exact witness size (as proposed), or an upper size 
> limit? Signing an upper limit will take up more space, as the limit has to be 
> explicitly shown in

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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
>   address reuse if many people start spamming him donations.

This point is pretty much moot since these are scripts, that are used in
very specialized contexts, and should not be shown to any
end-user. Sure, if you go through the blockchain looking for these
addresses, and send the exact same value to it, and create a matching
script then you could end up exposing those funds to this, however
that'd be very silly of you, and you'd have jumped through a lot of
hoops to lose money :-)

>   2.  for average users who would just 'autopilot' LN and only see the
> GUI. they will have no clue what transaction types and technicals are
> happening under the hood. also with LN being not validated by the
> community. a user creating a channel could tweak their own LN node to
> make their counterparty sign a sighash-noinput as a term/condition of
> the channel this is also a risk for the under the hood raw tx risks
> where a tx can be signed but then allow the out's to alter value(using
> a different opcode). .. you know the premiss of allowing a counterpart
> to alter the outs value to vary so that they can control the broadcast
> fee at the time of broadcast to cover being acceptd onchain.. which
> can be abused by a counter party just editing it so A gets nothing and
> B gets it all..

You cannot force the counterparty to sign with a sighash-flag that they
don't chose themselves. We are very clear in the BIP that you should
only use sighash_noinput_unsafe in the context of protocols, that need
to be designed in such a way that these issues are excluded. In
particular, eltoo uses a public key, provided by the signing party,
which they can ensure is not reused (ensuring script
uniqueness). Finally, wallets that are not part of LN or eltoo, won't
even know how to sign with sighash-noinput (try signing anything but
sighash-all on a hardware wallet for example).

The kind of editing you describe also doesn't work, since sighash-single
is used for the late fee binding, not sighash-noinput. sighash-single
makes sure that the input is only valid if the matching output is still
intact, so redirecting funds away from the desired output doesn't work.

>   3.  by allowing certain things to change after signing. is infact
>   bringing back malleability for those that use a TXID to identify a
>   tx has been confirmed. as a TXID would change if values
>   change.. just like how malleation abused old transactions by editing
>   a tx without needing to re-sign a tx

Again, this is only to be used in the context of applications that
require it, which also means that they know how to deal with this
malleability (in fact this malleability is wanted here). If you squint
at it you can probably see that sighash-noinput is also a poor-man's
malleability fix, allowing you to take a transaction that is based on a
malleated output, and rebind it to re-establish the connection.

It seems people believe that we are advocating the use of
sighash-noinput-unsafe in general purpose wallets and in everyday
transactions, this couldn't be further from the truth: sighash-noinput
is a sharp tool, that should only be used in very specific situations,
to enable a bit more flexibility, and it can improve the safety of
off-chain protocols a lot, however general purpose wallets should not
even allow signing with it.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely.   Otherwise, I'm worried
> that wallets might start using this sighash because it simplifies
> handling malleability without realizing that when a third party reuses
> a script pubkey, completely outside of control of the wallet that uses
> the flag, funds will be lost as soon as a troublemaker shows up (but
> not, sadly, in testing).  This sort of risk is magnified because the
> third party address reuser has no way to know that this sighash flag
> has (or will) be used with a particular scriptpubkey.

Absolutely agree that we should be signaling the danger of using noinput
as clearly as possible to developers, and I'm more than happy to adopt
the _unsafe suffix suggested by jb55. I think using non-sighash_all
sighashes is always a huge danger, as you have correctly pointed out, so
maybe we should be marking all of them as being unsafe, or make sure to
communicate that danger on a higher level (docs).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[Christian Decker via bitcoin-dev]

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 have a full bitcoin node running, could I use RPC calls
> or something to tell my Lightning node to use that node, instead of
> spinning up *another* full node? I’m currently minimizing the network
> thrashing by whitelisting my LN bitcoind node to only point to my existing
> full node for updates, but if I could just point my whole LN node at it,
> that’s save on disk storage etc. etc. etc.

Certainly, that's supported by all 3 implementations:

 - With c-lightning you can either configure `bitcoin-cli` to connect to
   a remote node with the `rpcconnect`, `rpcuser`, and `rpcpassword`
   options in the `bitcoin.conf` file (at which point all calls to
   `bitcoin-cli` will use that node) or you can use the following
   command line options when starting `lightningd`: `--bitcoin-rpcuser`,
   `--bitcoin-rpcpassword` and `--bitcoin-rpcconnect`
 - lnd allows you to specify the node to connect to using the command
   line options `--bitcoind.rpchost`, `--bitcoind.rpcuser`, and
   `--bitcoind.rpcpass`.
 - Eclair requires you to edit the configuration file [1] before
   compiling afaik

Cheers,
Christian


[1] 
https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/resources/reference.conf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[Christian Decker via bitcoin-dev]

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 after the funding
> transaction? Is that the only reason lightning needs to run bitcoind
> with txindex?

Yes, Lightning nodes need to monitor the network for transactions that
they need to react to. This is basically tailing the blockchain and
looking for anything suspicious. The `bitcoind` sitting next to the
lightning node however does not need to keep an index of the
transactions, at least for c-lightning, because we just ask for the full
block that then gets scanned for transactions of interest and then we
discard the rest of the block. We never ask for a specific transaction
from `bitcoind` and therefore we don't need to run with `-txindex`.

> If that is the case, and a lightning node only needs to query
> transactions broadcast after the funding transaction, then a pruned
> bitcoind instance with txindex might be a bit handy.

Pruned nodes should work, as long as the current blockchain head that
the lightning node has seen does not fall into the pruned range, since
in that case it won't be able to fetch and process the blocks anymore.

> Also from [1] it seems that indexing pruned nodes is not supported
> because it doesn't make sense, not that it was infeasible. Now with
> the lightning requirements, does an indexed pruned node start to make
> sense?

I don't think we should ever require `-txindex` to run a lightning node
(I know some implementations did in the past), since that'd be a very
onerous requirement to run a lightning node. Tailing the blockchain is
more than sufficient to get the necessary data, and hopefully we can get
our reliance on `bitcoind` down to a minimum in the future.

> Once again, please forgive my naive understanding of some of the issues
> involved and thanks for your patience.

Absolutely no problem, it is a common misconception that `-txindex` is
required to run a lightning node in all cases :-)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Christian Decker via bitcoin-dev]

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 this in general in Lightning; for instance we
> could make every funding transaction include such an output.  If it
> turns out, our initial feerate estimate for the funding transaction is
> low, we can use the `OP_TRUE` for fee-bumping.  This is a win for
> Lightning since the funding transaction ID remains the same (even in
> Decker-Russell-Osuntokun, the trigger transaction is signed with
> `SIGHASH_ALL`, and refers to a fixed funding transaction ID).
>
> Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a
> new different channel and RBF the old funding transaction with a new
> higher-feerate funding transaction, then keep track of which one gets
> confirmed deeply (there is a race where a miner discovers a block
> using the older funding transaction before our broadcast of the new
> funding transaction reaches it).
>
> (we could also feebump using the change output of the funding
> transaction, but such a change output might not exist for all funding
> transactions.)

This would only really help in the case of the funding tx not having a
change output, which I believe will be very rare. In the case of a
change output we can simply do a CPFP which includes the change output.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 proposal kind-of
>> > limits the potential damage by still committing to the prevout amount,
>> > but it still seems a big risk for all the people that reuse addresses,
>> > which seems to be just about everyone.
>> If I can convince you to sign with SIGHASH_NONE, it's already a problem
>> today.
>
> So, I don't find that very compelling: "there's already a way to lose
> your money, so it's fine to add other ways to lose your money". And
> again, I think NOINPUT is worse here, because a SIGHASH_NONE signature
> only lets others take the coin you're trying to spend, messing up when
> using NOINPUT can cause you to lose other coins as well (with caveats).

`SIGHASH_NOINPUT` is a rather powerful tool, but has to be used
responsibly, which is why we always mention that it shouldn't be used
lightly. Then again all sighash flags can be dangerous if not well
understood. Think for example `SIGHASH_SINGLE` with it's pitfall when
the input has no matching output, or the already mentioned SIGHASH_NONE.

>From a technical, and risk, point of view I don't think there is much
difference between a new opcode or a new sighash flag, with the
activation being the one exception. I personally believe that a segwit
script bump has cleaner semantics than soft-forking in a new opcode
(which has 90% overlap with the existing checksig and checkmultisig
opcodes).

>> [...]
>> In a world where SIGHASH_NONE didn't exist, this might be an argument :)
>
> I could see either dropping support for SIGHASH_NONE for segwit
> v1 addresses, or possibly limiting SIGHASH_NONE in a similar way to
> limiting SIGHASH_NOINPUT. Has anyone dug through the blockchain to see
> if SIGHASH_NONE is actually used/useful?

That's a good point, I'll try looking for it once I get back to my full
node :-) And yes, `SIGHASH_NONE` should also come with all the warning
signs about not using it without a very good reason.

>> That was also suggested by Mark Friedenbach, but I think we'll end up
>> with more "magic key" a-la Schnorr/taproot/graftroot and less script in
>> future.
>
> Taproot and graftroot aren't "less script" at all -- if anything they're
> the opposite in that suddenly every address can have a script path.
> I think NOINPUT has pretty much the same tradeoffs as taproot/graftroot
> scripts: in the normal case for both you just use a SIGHASH_ALL
> signature to spend your funds; in the abnormal case for NOINPUT, you use
> a SIGHASH_NOINPUT (multi)sig for unilateral eltoo closes or watchtower
> penalties, in the abnormal case for taproot/graftroot you use a script.

That's true for today's uses of `SIGHASH_NOINPUT` and others, but there
might be other uses that we don't know about in which noinput isn't just
used for the contingency, handwavy I know. That's probably not the case
for graftroot/taproot, but I'm happy to be corrected on that one.

Still, these opcodes and hash flags being mainly used for contingencies,
doesn't remove the need for these contingency options to be enforced
on-chain.

>> That means we'd actually want a different Segwit version for
>> "NOINPUT-can-be-used", which seems super ugly.
>
> That's backwards. If you introduce a new opcode, you can use the existing
> segwit version, rather than needing segwit v1. You certainly don't need
> v1 segwit for regular coins and v2 segwit for NOINPUT coins, if that's
> where you were going?
>
> For segwit v0, that would mean your addresses for a key "X", might be:
>
>[pubkey]  X
> - not usable with NOINPUT
>[script]  2 X Y 2 CHECKMULTISIG
> - not usable with NOINPUT
>[script]  2 X Y 2 CHECKMULTISIG_1USE_VERIFY
> - usable with NOINPUT (or SIGHASH_ALL)
>
> CHECKMULTISIG_1USE_VERIFY being soft-forked in by replacing an OP_NOP,
> of course. Any output spendable via a NOINPUT signature would then have
> had to have been deliberately created as being spendable by NOINPUT.

The main reason I went for the sighash flag instead of an opcode is that
it has clean semantics, allows for it to be bundled with a number of
other upgrades, and doesn't use up NOP-codes, which I was lectured
for my normalized tx BIP (BIP140) is a rare resource that should be used
sparingly. The `SIGHASH_NOINPUT` proposal is minimal, since it enhances
4 existing opcodes. If we were to do that with new opcodes we'd either
want a multisig and a singlesig variant, potentially with a verify
variant each. That's a lot of opcodes.

The proposal being minimal should also help against everybody trying to
get their favorite feature added, and hopefully streamline the
discussion.

> For a new segwit version with taproot that likewise includes an opcode,
> that might be:
>
>[taproot]  X
> - not usable with NOINPUT

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 version I
> implemented still committed to the script being sent, while this new
> version just relies on witness validity instead. This approach is even
> more flexible as the script attached to the output being spent can
> change, without rendering the spending transaction invalid as long as
> the witness still ratifies a branch in the output's predicate.

Yeah, we removed the script commitment out of necessity for eltoo, but
it seems to add a lot of flexibility that might be useful. One
additional use-case that came to mind is having a recovery transaction
for vault-like scenarios, i.e., a transaction that can short-circuit a
thawing process of frozen funds. You'd keep that transaction in a vault,
pre-signed and bind it to whatever action you'd like to interrupt.

> Given that this would introduce a _new_ sighash flag, perhaps we
> should also attempt to bundle additional more flexible sighash flags
> concurrently as well?  This would require a larger overhaul w.r.t to
> how sighash flags are interpreted, so in this case, we may need to
> introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now),
> which would consume an available noop opcode. As a template for more
> fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3]
> (particularly the "New nHashType definitions" section).  This was
> originally proposed in the context of his merklized script work as it
> more or less opened up a new opportunity to further modify script
> within the context of merklized script executions.  The approach reads
> in the sighash flags as a bit vector, and allows developers to express
> things like: "don't sign the input value, nor the sequence, but sign
> the output of this input, and ONLY the script of this output". This
> approach is _extremely_ powerful, and one would be able to express the
> equivalent of no_input by setting the appropriate bits in the sighash.

I purposefully made the proposal as small and as well defined as
possible, with a number of possible applications to back it, since I
think this might be the best way to introduce a new feature and make it
as uncontroversial as possible. I'm not opposed to additional flags
being deployed in parallel, but they'll need their own justification and
analysis, and shouldn't be rushed just "because we're doing noinput".

Going for a separate op-code is definitely an option we considered, but
just for noinput it'd be duplicating quite a lot of existing
functionality. With additional sighash flags it might become necessary,
but I don't think it is necessary just for noinput.

> Looking forward in hearing y'alls thoughts on this approach, thanks.
>
> [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
> [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
> [3]: 
> https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
>
> -- Laolu
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

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 spec, this was pointed out by Mats in
> the past: [1][2]. The dependency meant that if we wanted to allow very
> long CSV time outs (like 1 month +), then this would have the adverse
> effect of increasing the total CLTV timeout along the entire route. As
> a result, we moved to the 2-stage HTLC scheme which is now implemented
> and deployed as a part of BOLT 1.0. It may be the case that in the mid
> to near future, most implementations aren't concerned about long time
>  locks due to the existence of robust and reliable private
> outsourcers.

It's worth mentioning that the requirement for extremely large CLTV deltas
would already create incredibly long CLTV deltas between the endpoints,
since the endpoint delta accumulates along the path. This is true for
LN-Penalty as well as eltoo. eltoo's requirement to settle before the
HTLCs touch the blockchain adds a stage in which need to start on-chain
settlement to ensure the HTLC hits the chain before its CLTV
expires. We can imagine this as a separate timewindow, that does not
accumulate across multiple hops (settlement ordering is not an issue,
CLTV resolution is).

My hope is that indeed with the simpler watch-towers we can reduce both
the CLTV deltas as well as the settlement timeouts for eltoo, so that
they become negligible.

> As a side effect of the way the symmetric state changes the strategy
> around breach attempts, we may see more breach attempts (and therefore
> update transactions) on the chain since attempting to cheat w/ vanilla
> symmetric state is now "costless" (worst case we just use the latest
> state, best case I can commit the state better for me. This is in
> stark contrast to punishment/slashing based approaches where a failed
> breach attempt results in the cheating party losing all their funds.

Not exactly costless, since the breaching party will have to pay the
on-chain fees, and we may be able to reintroduce the reserve in order to
add an additional punishment on top of the simple update mechanism
(selectively introducing asymmetry).

> However, with a commitment protocol that uses symmetric state. The
> 2-stage HTLC scheme doesn't actually apply. Observe that with
> Lighting's current asymmetric state commitment protocol, the "clock"
> starts ticking as soon as the commitment hits the chain, and we follow
> the "if an output pays to me, it must be delayed as I may be
> attempting a breach". With symmetric state this no longer applies, the
> clock instead starts "officially" ticking after the latest update
> transaction has hit the chain, and there are no further challenges. As
> a result of this, the commitment transaction itself doesn't need to
> have any CSV delays within the Script branches of the outputs it
> creates. Instead, each of those outputs can be immediately be spent as
> the challenge period has already elapsed, and from the PoV of the
> chain, this is now the "correct" commitment. Due to this, the HTLC
> outputs would now be symmetric themselves, and look very much like an
> HTLC output that one would use in a vanilla on-chain cross-chain
> atomic swap.

In addition to this it is worth pointing out that the old/replaced HTLCs
have no way of ever touching the blockchain, so we can throw away a
whole heap of data about these HTLCs, that we would have to carry around
indefinitely if this were not the case. The same reason the HTLCs start
ticking when a settlement touches the chain in LN-penalty is also the
reason we need to carry all that data around. eltoo can be said to
contain the two stage HTLC commit we added on top of LN-penalty.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 unlikely to sail through review, and given the lack
of ground-work on witness V1 scripts, I can't really test it now, and
only the second commit is part of the implementation itself.

One issue that was raised off list was that some fork coins have used
sighash 0x40 as FORKID. This does not conflict with this proposal since
the proposal only applies to segwit transactions, which the fork coins
have explicitly disabled :-)

I'm looking forward to discussing how to we can move forward to
implementing this proposal, and how we can combine multiple proposals
into the next soft-fork.

Cheers,
Christian

[1] https://github.com/cdecker/bitcoin/tree/noinput
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 creating the output that'll later be spent using a
`SIGHASH_NOINPUT` transaction it won't (and shouldn't) care.

> I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in
> LN discussions, when the issue of transaction malleation was
> considered (before SegWit, being totally uncontroversial, was
> massively adopted).  The sketch below, I believe, is somewhat
> consistent with how it could have been used in funding a channel.

I consider `SIGHASH_NOINPUT` to be a poor-man's malleability fix, since
it comes with some baggage. Without trying to undermine my own proposal,
but address reuse in combination with binding through script, can lead
to very unexpected results. You need to be very careful about where you
allow rebinding, hence the warnings in the proposal.

> Consider a CoinSwap protocol.  Each side writes a transaction that
> pays out to an ordinary 2-of-2 multisig address.  But before each side
> writes and signs that transaction, it first demands a timelocked
> backout transaction to let them recover their own funds in case it
> falls through (more generally, every offchain protocol has a similar
> setup stage where some way to back out is signed before all parties
> enter into the contract).
>
> ...
>
> With `SIGHASH_NOINPUT`, we can indeed implement such a walletless
> CoinSwap (or other protocol) software.  We only need to provide the
> public keys that will be used in the initial 2-of-2, and the other
> side can create a signature with `SIGHASH_NOINPUT` flag.

I was wondering whether we could actually skip one communication round
w.r.t. the previously described CoinSwap protocol, but it turns out we
need to at least exchange public keys before actually moving any
funds. Would have been nice to do spontaneous CoinSwaps.

> The setup of the CoinSwap then goes this way.  The swapping nodes
> exchange public keys (two for each side in this case), they agree on
> who gets to move first in the swap and who generates the preimage, and
> then they agree on what the backout transactions look like (in
> particular, they agree on the address the backout transactions spend)
> and create signatures, with `SIGHASH_NOINPUT`.  In particular, the
> signatures do not commit to the txid of the transaction that they
> authorize spending.  The CoinSwap sofwares then turn around to their
> users and say "okay, send to this address", the users initiate the
> swap using their normal wallet software, the CoinSwap software
> monitors only the address it asked the user to use, then when it
> appears onchain (the CoinSwap software does not even need to track the
> mempool) it continues with the HTLC offers and preimage exchanges
> until the protocol completes.
>
> In a world where walletless CoinSwap exists, consider this:
>
> 1.  A user buys Bitcoin from an exchange.  The exchange operates a
> wallet which they credit when the user buys Bitcoin.
> 2.  The user starts a CoinSwap, giving the destination address from
> their cold-storage wallet.
> 3.  The CoinSwap tells the user an address to send to.  The user
> withdraws money from the exchange using that address as destination (1
> transaction)
> 4.  The user waits for the CoinSwap to finish, which causes the funds
> to appear in their cold-storage wallet (1 transaction).
>
> If CoinSwap implementations all needed their own wallets, then instead:
>
> 1.  A user buys Bitcoin from an exchange.
> 2.  The user withdraws the funds from the exchange to a CoinSwap
> implementation wallet (1 transaction).
> 3.  The user performs a CoinSwap which goes back to the CoinSwap
> implementation wallet (2 transactions).
> 4.  The user sends from the CoinSwap wallet to their cold storage (1
> transaction). (granted, the CoinSwap implementation could offer a
> feature that immediately transfers the swapped funds to some other
> wallet, but we still cannot get around the transfer from the exchange
> to the CoinSwap wallet)
>
> A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to
> use; it immediately paints the user as using some special protocol.
> So much for `SIGHASH_NOINPUT` CoinSwap.

By providing a new use-case you are contributing to the obfuscation of
this technique. The more normal the use of `SIGHASH_NOINPUT` becomes the
less an observer can learn from it being used. In combination with MAST,
Taproot or Graftroot we can further hide the details of the executed
protocol :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

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(expire = X) -> D
>
> So D is not required to reveal the preimage before time X, and in the case
> of an on-chain settle, C needs to be able to redeem the HTLC output through
> the timeout clause before time X + delta. C can't redeem the HTLC (with
> sufficient confirmations) at least until the settlement transaction is
> confirmed. So it seems to me that regardless of the overall route and the
> maximum CSV on it, the delta for the C hop has to be greater than the CSV
> delay on the update transaction. And that this must be true at every hop
> for the same reason.

That'd be a purely reactionary behavior, i.e., chosing the delta in such
a way that I can both settle the channel and have enough time to react
to turn around and reveal the preimage. So with the assumptions we had
before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
288 on each hop, yes. That's basically the case in which each channel
reacts serially.

You can trivially parallelize these closures by looking ahead and
noticing that each hop really just cares about its own closure deadline,
i.e., each node just cares to close 288 blocks before the CLTV expires,
not that its delta w.r.t. to the downstream channel is that far in the
future. So all we care about is that once we are due to give the
upstream hop the preimage we've already closed the downstream channel
and can now read the HTLC preimage from that channel.

The CSV timeout isn't part of the delta on each hop, but we need to
implement the deadline computation as:

```
CLTV - CLTV delta - CSV
```

instead of LN-penaltiy's

```
CLTV - CLTV delta
```
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

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
setting). Furthermore let's assume that the CSV timeout for the channels
is also 144.

This means that with the current LN-penalty mechanism you'd have the
following CLTV deltas in the HTLC:

```
A -(576)-> B -(432)-> C -(288)-> D -(144)-> E
```

Meaning that if the current time is approaching the absolute CLTV we
need initiate a channel closure to safely fetch the preimage on-chain,
and be able to turn around and send it on the upstream channel.

This is minimal, but can be arbitrarily higher, if you follow the best
practice of obfuscating the final destination by building a shadow route
behind the real recipient, and add it's CLTV deltas and fees to your
route.

With eltoo you'd need to make sure that you have the settlement
transaction confirmed before your desired CLTV timeout delta begins to
count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV
delta` you need to initiate a close, whereas Lightning allows you to
wait for time `now + CLTV delta`. Effectively this results in the
following time deltas:

```
A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E
```

Taking the last hop for example, if we had a CLTV of 1000 with eltoo
we'd need to start closing at height 712, instead of 856 with
LN-penalty. However, this increased delta does not accumulate along the
path, it's just a fixed offset. The longer the route, the smaller the
actual impact of this offset.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

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 *output script* to refer to the 
>> `witness` or `scriptSig`.
>
> Figure 2 contains to what looks to me like a `witnessProgram`, 
> `scriptPubKey`, or `redeemScript` but refers to it as an "output script":
>
>>OP_IF
>>10 OP_CSV
>>2 As Bs 2 OP_CHECKMULTISIGVERIFY
>>OP_ELSE
>>2 Au Bu 2 OP_CHECKMULTISIGVERIFY
>>OP_ENDIF
>>
>> Figure 2: The output script used by the on-chain update transactions.
>
> Regards,
> ZmnSCPxj

Darn last minute changes! Yes, you are right, I seem to have flipped the
two definitions. I'll fix that up and push a new version.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

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 the HTLC
> offered to C times out and C does not fail the HTLC off-chain, Lightning
> currently guarantees that the CLTV delta is sufficient that I may close the
> channel to C on-chain and claim the timed-out HTLC before my upstream HTLC
> to A times out. If the CLTV delta is too small, I may fail the upstream
> HTLC as soon as it times out, and then C may still claim the downstream
> HTLC with the preimage on-chain. With eltoo, when B closes the downstream
> channel on-chain, it must wait the CSV timeout on the update transaction
> before locking in the timed-out HTLC. This effectively means the CLTV delta
> has to be greater than the CSV timeout, plus some extra (whereas it is
> currently safe to make it significantly shorter). Is that true or am I
> missing something?

That's a good point Jim. We need to make sure that the CLTVs are far
enough in the future for the CSV timeout to expire and to grab any
preimage downstream and insert it upstream. Overall this results in an
offset of all the CLTVs to (less than) the maximum CSV timeout along the
path. This would be a fixed offset for each channel and can be announced
using the gossip protocol, so senders can take it into consideration
when computing the routes. Notice that this is not really the CLTV
delta, which would accumulate along the path, but an offset on which the
CLTV deltas build on.

In today's network we have many nodes that have a CLTV delta of 144
blocks, which quickly results in HTLC funds unavailable for several days
depending on the route length, so I don't think that adding a fixed
offset is much worse. Once we have watch-towers we can reduce both the
offset as well as the CLTV deltas. Since eltoo makes watch-towers less
expensive, given the reduced storage costs, I'd argue that it's a net
positive for the Lightning network (but then again I'm biased) :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

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 have long known that `SIGHASH_NOINPUT` would be a great fit for Lightning.
They enable simple watch-towers, i.e., outsource the need to watch the
blockchain for channel closures, and react appropriately if our counterparty
misbehaves. In addition to this we just released the eltoo [3,4] paper which
describes a simplified update mechanism that can be used in Lightning, and other
off-chain contracts, with any number of participants.

By not committing to the previous output being spent by the transaction, we can
rebind an input to point to any outpoint with a matching output script and
value. The binding therefore is no longer explicit through a reference, but
through script compatibility, and the transaction ID reference in the input is a
hint to validators. The sighash flag is meant to enable some off-chain use-cases
and should not be used unless the tradeoffs are well-known. In particular we
suggest using contract specific key-pairs, in order to avoid having any unwanted
rebinding opportunities.

The proposal is very minimalistic, and simple. However, there are a few things
where we'd like to hear the input of the wider community with regards to the
implementation details though. We had some discussions internally on whether to
use a separate opcode or a sighash flag, some feeling that the sighash flag
could lead to some confusion with existing wallets, but given that we have
`SIGHASH_NONE`, and that existing wallets will not sign things with unknown
flags, we decided to go the sighash way. Another thing is that we still commit
to the amount of the outpoint being spent. The rationale behind this is that,
while rebinding to outpoints with the same value maintains the value
relationship between input and output, we will probably not want to bind to
something with a different value and suddenly pay a gigantic fee.

The deployment part of the proposal is left vague on purpose in order not to
collide with any other proposals. It should be possible to introduce it by
bumping the segwit script version and adding the new behavior.

I hope the proposal is well received, and I'm looking forward to discussing
variants and tradeoffs here. I think the applications we proposed so far are
quite interesting, and I'm sure there are many more we can enable with this
change.

Cheers,
Christian

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
[2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
[3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[4] https://blockstream.com/eltoo.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

(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
teams joined forces to work on a common specification for the protocol
stack. Now that both that specification and our three implementations
are becoming stable and usable, it is time to look forward: to further
improve the protocol, to add new features, to simplify, and to fix
downsides.

One of the core innovations that enabled Lightning in the first place was an
off-chain update mechanism to renegotiate a new state and ensure that the old
state can not be settled on-chain. Today, we're excited to release our latest
research paper on a new, simplified, update mechanism for layer 2 protocols,
called eltoo.

eltoo is a drop-in replacement for the penalty based invalidation
mechanism that is used today in the Lightning specification. It is
similar in many ways to the sequence number mechanism that was already
present in the original Bitcoin implementation. But, while sequence
numbers were unenforceable on the blockchain, eltoo is enforceable by
overriding subsequent states on-chain.

Unlike the current mechanism used in Lightning so far, it is not penalty
based, i.e., publishing an old state does not result in the faulty node
to automatically lose funds, and is most similar to the duplex
micropayment channels construction. It is a symmetric scheme, i.e., all
participants share an identical set of transactions, and it ensures that the
last agreed upon state is settled on-chain, with similar tradeoffs as
today's Lightning (timelock vs. online requirement).

eltoo addresses some of the issues we encountered while speficying and
implementing the Lightning Network. For example outsourcing becomes very
simple since old states becoming public can't hurt us anymore. We
completely remove the need to estimate fees ahead of time. The
construction allows us to attach fees when settling, and even allows for
fees to be bumped using CPFP or RBF.

Beyond Lightning, eltoo can be used as a generic update mechanism for an
off-chain contract, for a larger number of participants. This was not
possible in the current update mechanism since reactions to a
misbehaving participant needed to be tailore to that participant. This
enables other protocols such as the channel factories, and in
combination with Schnorr signatures allows for very large off-chain
contracts with minimal on-chain footprint.

Before we can implement eltoo, we need a minor change to Bitcoin: the
introduction of the SIGHASH_NOINPUT flag for signatures. This was first
discussed a few months ago in the context of watchtowers to help secure
Lightning channels, but was not formally proposed. A formal proposal may
now be found in the eltoo paper.

We invite the community to consider our proposal and to participate in
its discussion. We hope to arrive at a consensus for the usage of
SIGHASH_NOINPUT, so that it can be accepted and included in a future
soft fork of Bitcoin Script. Doing so will put us on the road to a more
reliable and simpler Lightning Network, incorporating a new update
mechanism that can also be used for many other applications.

The full official announcement can be found at [1] and the paper with the full
details can be found at [2].

Looking forward to the communities feedback,
Christian

[1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[2] https://blockstream.com/eltoo.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

[Christian Decker via bitcoin-dev]

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, so this might be a non-issue.

On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Why not add the outpoints owned by the wallet to the filter and watch for
> those instead of elements in the input script or witness data?
>
> On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Andreas
>>
>> Thanks for bringing this up and this seems indeed to be suboptimal.
>>
>> > I wonder if Bitcoin Core would be willing to extend the BIP37 matching
>> > rules such that data elements in the witness are also matched against?
>>
>> Bitcoin Core is not an identity that can be „willing to extend“ (or
>> reject) a feature.
>> Someone needs to come up with a proposal (pull request).
>>
>> Maybe an extension for BIP37 would make sense (*meh*).
>> Just inserting the witness data into the bloom filter seems to be an easy
>> solution (CBloomFilter::IsRelevantAndUpdate())
>>
>> /jonas
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Christian Decker via bitcoin-dev]

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-public channels can still be identified on settlement.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revising BIP 2 to expand editorial authority

[Christian Decker via bitcoin-dev]

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 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> What do people think about modifying BIP 2 to allow editors to merge these
>> kinds of changes without involving the Authors? Strictly speaking, BIP 2
>> shouldn't be changed now that it is Active, but for such a minor
>> revision, I
>> think an exception is reasonable.
>>
>
> Even minor revisions can not change the meaning of text. Changing a single
> word can often have a strange impact on the meaning of the text. There
> should be some amount of care exercised here. Maybe it would be okay as
> long as edits are mentioned in the changelog at the bottom of each
> document, or mention that the primary authors have not reviewed suggested
> changes, or something as much; otherwise the reader might not be aware to
> check revision history to see what's going on.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction signalling

[Christian Decker via bitcoin-dev]

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 signalling ideas.

I think we have a number of fields that may be used for such a
signalling, e.g., OP_RETURN, locktime, and output scripts. I think
OP_RETURN is probably not the field you'd want to use though since it
adds data that needs to be transferred, stored for bootstrap, and
outputs in the UTXO would need to be tagged with additional
information. Locktime has the advantage of being mostly a freeform
field for values in the past, but it clashes with other uses that may
rely on it. Furthermore, it is the transaction creator that specifies
the locktime, hence the signal trails one hop behind the current
owner, i.e., the actual stakeholder.

I think probably the best field to signal would be the output
script. It is specified by the recipient of the funds, i.e., the
current owner, and is already stored in the UTXO, so a single pass can
tally up the votes. We could for example use the last 4 bits of the
pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1
depending on the stakeholders desired signal). We'd need to define
similar semantics for other script types, but getting the standard
scripts to be recognized should be simple.

In the spirit of full disclosure I'd like to also mention some of the
downsides of voting this way. Unlike the OP_RETURN proposal, users
that do not intend to signal will also be included in the tally. I'd
expect the signals of these users to be random with a 50% chance of
either outcome, so they should not influence the final result, but may
muddy the water depending on what part of the population is
signalling. The opt-in should make sure that the majority of votes are
actually voluntary votes, and not just users that randomly select a
pubkey/pubkeyhash, and can be adjusted as desired, though higher
values require more grinding on behalf of the users.

The grinding may also exacerbate some problems we already have with
the HD Wallet lookahead, since we now skip a number of addresses, so
we should not require too many opt-in bits.

So there are some problems we'd need to tackle, but I'm really excited
about this, as it could provide data to make informed decisions, and
should put an end to the endless speculation about the will of the
economic majority.

Cheers,
Christian

[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Three hardfork-related BIPs

[Christian Decker via bitcoin-dev]

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 throughput in the overlay
> network, which we define here as which blocks propagate within an average
> block interval period the percentage of nodes to.
> ...
> >Note that as we consider only a subset of possible metrics (due to
> difficulty in accurately measuring others), our results on
> reparametrization may be viewed as upper bounds: additional metrics could
> reveal even stricter limits.
> 
> It says nothing about any mining centralization pressure, DoS attacks, etc.
> A single metric among many we have to contend with.
>

As one of the authors of that paper and the source of the measurement
data I'd also like to point out that the 4MB number is indeed intended
as an optimistic upper bound on todays network capacity.

More importantly it's not a black and white situation, where there is
a magic number beyond which Bad Things (TM) happen, it's a spectrum on
which we can see a few threshold beyond which we _know_ Bad Things
definitely happen. Miner centralization pressure is felt earlier.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Christian Decker via bitcoin-dev]

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/is_in_mempool?txid=334847bb...
> > https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> > https://bw.com/api/is_in_mempool?txid=334847bb...
> > https://bitfury.com/api/is_in_mempool?txid=334847bb...
> > https://btcc.com/api/is_in_mempool?txid=334847bb...
> > 
> > If each of these services return "True", and you know those services
> > so not engage in RBF, then you can assume with great confidence that
> > your transaction will be in the next block, or in a block very soon.
> > If any one of those services return "False", then you must assume that
> > it is possible that there is a double spend floating around, and that
> > you should wait to see if that tx gets confirmed. The problem is that
> > not every pool runs such a service to check the contents of their
> > mempool...
> > 
> > This is an example of mining centralization increasing the security of
> > zero confirm.
> 
> A world connected up to a few web services to determine payment validity
> is an example of a bitcoin security catastrophe.
> 
> e
> 

And it's a great way to tell every miner who you are and what
transactions you are sending/receiving. An absolute privacy
nightmare...

-- cdecker
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

[Christian Decker via bitcoin-dev]

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 html can only use a bold tag  once in a document? Thats equivalent 
> to what you are saying.
> 
> Your comment is rather embarrassing, I have to point out. You may want to 
> read a bit more before you comment more.

Not sure if the comparison to XML and HTML holds: the lack of closing
tags makes the meaning of individual tokens ambiguous, like I pointed
out before. The use of segments gives at most two levels of nesting,
so any relationship among tokens in the same segment has to rely on
their relative position, which could result in ambiguities, like
whether a tag refers to a single input or the transaction as a whole.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

[Christian Decker via bitcoin-dev]

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 document should
> > be avoided 
> 
> If luke-jr thinks I should submit CMF as a BIP, I can certainly do that.
> Luke, what do you think?
> 
> I don't have a preference either way.
> 
> > 
> > So the presence is signaled by encountering the tag, which contains
> > both token type and name-reference. The encoder and decoder operations
> > could be described better.
> 
> I'm sorry, I'm not following you here. Is there a question?

Nope, just clarifying how presence or absence is indicated :-)

> > 
> > Minor nit: that table is not well-formed.
> 
> I am not very well versed in mediawiki tables, and I found github has some 
> incompatibilities too.
> The markdown one looks better;
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md

It's just some rows have 3 columns, others have 2. It's a minor nit
really.

> > As was pointed out in the
> > normalized transaction ID BIP, your proposal only addresses
> > third-party malleability, since signers can simply change the
> > transaction and re-sign it.
> 
> I have to disagree. That is not malleability. Creating a new document and re-
> signing it is not changing anything. Its re-creating. Something that the 
> owner 
> of the coin has every right to do.

Same thing I was arguing back then, however Luke pointed out that
malleability just refers to the possibility of modifying a transaction
after the fact. Always referring to "third-party malleability" avoids
this ambiguity.

> > This is evident from the fact that inputs
> > and outputs do not have a canonical order and it would appear that
> > tokens can be re-ordered in segments. 
> 
> Sorry, what is evident? You seem to imply that it is uncommon that you can 
> create two transactions of similar intent but using different bytes.
> You would be wrong with this implication as this is very common. You can just 
> alter the order of the inputs, for instance.
> 
> I am unable to see what the point is you are trying to make. Is there a 
> question or a suggestion for improvement here?
> 
> > Dependencies of tokens inside a
> > segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex,
> > TxOutScript <-> TxOutValue).
> 
> Maybe you missed this line; 
>   «TxInPrevHash and TxInPrevIndex
>Index can be skipped, but in any input the PrevHash always has
>to come first»

Nope, that is exactly the kind of dependency I was talking
about. Instead of nesting a construct like the current transactions
do, you rely on the order of tokens to imply that they belong
together.

> If you still see something alarming, let me know.
> You can look at the code in Bitcoin Classic and notice that it really isn't 
> anything complicated or worrying.
> 
> 
> > Finally, allowing miners to reject transactions with unknown fields
> > makes the OP_NOPs unusable 
> 
> Hmm, it looks like you are mixing terminology and abstraction-levels.  OP_NOP 
> is a field from script and there is no discussion about any rejection based 
> on 
> script in this BIP at all.
> 
> Rejection of transactions is done on there being unrecognised tokens in the 
> transaction formatting itself.

Ah, thanks for clearing that up. However, the problem persists, if we
add new fields that a non-upgraded node doesn't know about and it
rejects transactions containing it, we'll have a hard-fork. It should
probably not reject transactions with unknown fields if the
transaction is included in a block.

> Thank you for your email to my BIP, I hope you got the answers you were 
> looking for :)

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

[Christian Decker via bitcoin-dev]

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 concretely specified enough to
> > review or implement from it.
> > 
> > For example, it does not specify the serialization of "integer"
> 
> It refers to the external specification which is linked at the bottom.
> In that spec you'll see that "Integer" is the standard var-int that Bitcoin 
> has used for years.

I think BIPs should be self-contained, or rely on previous BIPs,
whenever possible. Referencing an external formatting document should
be avoided and requiring readers to reverse engineer a reference
implementation doesn't seem too user friendly either. Publishing a BIP
with CMF would certainly help, and completing this spec with the
details that are missing, or only "defined" in the implementation,
would be better.

> > nor does it specify how the
> > presence of the optional fields are signaled 
> 
> How does one signals an optional field except of in the spec? Thats the job 
> of 
> a specification.

So the presence is signaled by encountering the tag, which contains
both token type and name-reference. The encoder and decoder operations
could be described better.

> > nor the cardinality of
> > the inputs or outputs. 
> 
> Did you miss this in the 3rd table ?  I suggest clicking on the github bips 
> repo link as tables are not easy to read in mediawiki plain format that the 
> email contained.

Minor nit: that table is not well-formed. As was pointed out in the
normalized transaction ID BIP, your proposal only addresses
third-party malleability, since signers can simply change the
transaction and re-sign it. This is evident from the fact that inputs
and outputs do not have a canonical order and it would appear that
tokens can be re-ordered in segments. Dependencies of tokens inside a
segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex,
TxOutScript <-> TxOutValue).

Finally, allowing miners to reject transactions with unknown fields
makes the OP_NOPs unusable since they'd result in forks: non-upgraded
nodes would reject blocks from upgraded nodes.

Regards,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Christian Decker via bitcoin-dev]

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)
> and was aware that the creator intended to doublespend as soon as the
> transaction was discovered, wouldn't they instead prefer to not touch
> anything and wait for a non-bait target to appear? Is the assumption here
> that the intruder wouldn't know this is a honeypot, or that they would know
> and it's just assumed that they would rather take their chances on this
> instead of causing some other trouble?

That strongly depends on the value of the compromised machine to the
attacker. If he has syphoned all the data from it and has no further
use for it then the he will probably trip the tripwire to get the
coins even though this will make the compromise apparent. If however
he is planning to use it as a foothold to further compromise your
company, send spam or similar, he will likely try to avoid these
tripwires. In which case a classic honeypot, that attempts to look
like a regular system is what you're looking for.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 signature malleability +
> conflicting spends, then that's fine.
> But it seems Christian is mostly interested in signature malleability,
> which is what SW can solve.
> In fact, creating conflicting spends is sometimes useful for some
> contracts (ie to cancel the contract when that's supposed to be
> allowed).
> Maybe it is "incorrect" that people use "malleability" when they're
> specifically talking about "signature malleability", but I think that
> in this case it's clear that we're talking about transactions having
> an id that cannot be changed just by signing with a different nonce
> (what SW provides).
>
> Please, Christian, correct me if you mean something else.
>

Yes, your differentiation is spot on. My main goal is to eliminate the risk
of detaching transactions in  off-blockchain protocols that rely on a
number of transactions being chained, hence solving signature malleability
might be the correct term. Canonical encodings do address part of the
problem, however they do nothing in the case of one of the signers
re-signing a transaction and detaching any followup transaction. Also
having transaction templates is a nice way to reduce the complexity of
protocols by eliminating some of the "who signs what when" gotchas.
Segregated witnesses would be a perfect solution, we just need to find a
good migration plan for Bitcoin :-)

Sorry for the confusion caused by me misusing the term malleability, I'll
use signature malleability in the future :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

This does indeed sound reasonable. The chances of having a cut in the
network consisting of non-upgraded nodes partitioning the network and not
forwarding the segregated witnesses should be minimal, given a long rollout
phase before the activation.

If everybody agrees that this is a better way to 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 we can get a connected component of upgraded nodes that
> > relay both the transaction and the associated external scripts then we
> > could just piggyback the external scripts on top of the normal messages.
> > Non-upgraded nodes will read the entire two-part message but only parse
> the
> > classical transaction, dropping the external script. Validation rules for
> > upgraded nodes are the same as before: if the attached signatures are
> > invalid the entire TX is dropped. We have to commit to the external
> scripts
> > used during the creation of a block. I think the easiest way to add this
> > commitment is the coinbase input I guess, and following the transaction
> > list a new list of signature lists is shipped with the rest of the block.
> > Non-upgraded will ignore it as before.
> >
> > Would that work? It all hinges on having upgraded miners in a connected
> > component otherwise non-upgraded nodes will drop the external scripts on
> > the way (since they parse and then reconstruct the messages along the
> > path). But if it works this could be a much nicer solution.
>
> FWIW my replace-by-fee fork does preferential peering with other RBF
> nodes to ensure that you'll always be connected to at least some
> full-RBF peers. In practice this works very well, and I'm sure a similar
> scheme could be used in this situation as well.
>
> Basically, conceptually unless you're connected to peers that advertise
> that they relay the new data, you treat the situation as though you're
> not connected to any peers at all. No different than if for some reason
> none of your peers were advertising NODE_NETWORK.
>
> --
> 'peter'[:-1]@petertodd.org
> 0247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 normalization because we have no good way of relaying the
> > external scripts. Since we are still in the drafting phase I am open to
> > suggestions and if there is a good/working solution I can amend/withdraw
> > the proposal.
>
> Changing the network protocol is trivial in comparison to making a
> permanent
> increase in UTXO set costs.
>

Ok, so assuming we can get a connected component of upgraded nodes that
relay both the transaction and the associated external scripts then we
could just piggyback the external scripts on top of the normal messages.
Non-upgraded nodes will read the entire two-part message but only parse the
classical transaction, dropping the external script. Validation rules for
upgraded nodes are the same as before: if the attached signatures are
invalid the entire TX is dropped. We have to commit to the external scripts
used during the creation of a block. I think the easiest way to add this
commitment is the coinbase input I guess, and following the transaction
list a new list of signature lists is shipped with the rest of the block.
Non-upgraded will ignore it as before.

Would that work? It all hinges on having upgraded miners in a connected
component otherwise non-upgraded nodes will drop the external scripts on
the way (since they parse and then reconstruct the messages along the
path). But if it works this could be a much nicer solution.


>
> > As for open venues for malleability, I'm not sure we can fix them at all,
> > after all the ability of a single signer to doublespend by
> > appending/replacing inputs/outputs in an arbitrary fashion is not fixable
> > IMHO and will cause any future transaction building on its outputs to be
> > orphaned. What would the perfect properties for such a fix be?
>
> The problem isn't changing inputs/outputs, but that such changes invalidate
> later spends. In particular, note that wallets *should ideally* be actively
> trying to make transfers using multiple malleated versions of the same
> payment.
>

So this is indeed a form of desired malleability we will likely not be able
to fix. I'd argue that this goes more into the direction of double-spending
than a form of malleability, and is mostly out of scope for this BIP. As
the abstract mentions this BIP attempts to eliminate damage incurred by
malleability in the third party modification scenario and in the multisig
scenario, with the added benefit of enabling transaction templating. If we
can get the segregated witnesses approach working all the better, we don't
even have the penalty of increased UTXO size. The problem of singlesig
users doublespending their outputs to update transactions remains a problem
even then.


>
> So the way to make an anti-malleable wallet, would be to strictly enforce
> the
> no-address-reuse rule on payments received (note this has no effect on
> other/current wallets) and rely only on the hash of that scriptPubKey+value
> for the input in subsequent transactions. This way, no matter what inputs
> or
> other outputs the transaction paying the address/invoice uses, the
> subsequent
> transaction ignores them and remains valid. (I am not suggesting this as a
> mandatory change that all wallets must adopt to receive the current semi-
> malleability protection you propose - only that it be *possible* for
> wallets
> to upgrade to or offer in the future.)
>

Sounds very interesting. That would then be a new signature checking opcode
I guess that would allow the transaction hash in the input be replaced by
the hash of the serialized output it is spending? That way the transaction
would not be detached from the coins unless the amount or the scriptpubkey
(containing the address) is modified. So a user may add new outputs and
inputs to an existing transaction like you mentioned. This does not help
someone receiving funds from a sender to build new transactions on top
since the sender may simply doublespend its output before it is confirmed.
I think this is probably best addressed in a separate proposal.


>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 :-)

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 normalization because we have no good way of relaying the
external scripts. Since we are still in the drafting phase I am open to
suggestions and if there is a good/working solution I can amend/withdraw
the proposal.

As for open venues for malleability, I'm not sure we can fix them at all,
after all the ability of a single signer to doublespend by
appending/replacing inputs/outputs in an arbitrary fashion is not fixable
IMHO and will cause any future transaction building on its outputs to be
orphaned. What would the perfect properties for such a fix be?

Regards,
Christian

On Thu, Oct 22, 2015 at 11:05 AM Luke Dashjr  wrote:

> On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> > 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 is a lot we can do about it even if we instate a canonical
> > ordering. Even if we order the inputs and outputs the signer can just
> add a
> > new input and output and we would have a different transaction.
> >
> > Normalized transaction IDs do help in the case that the single signer
> wants
> > to immediately follow up its transaction with another transaction
> spending
> > the first one's change output, and it prevents any modification in the
> > multi-signer scenario.
>
> Except that unlike malicious double spending, adding more outputs to
> unconfirmed transactions is what wallets *should ideally be doing every
> time
> they send another transaction*. Spending unconfirmed change is the wrong
> approach. So half-fixing malleability as this PR would, encourages
> inefficient behaviour in multiple ways (first, by not making it
> malleability-
> safe; second, by encouraging spending unconfirmed change).
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

Indeed the reason I got started with all of this is the use of normalized
transaction IDs within smart contracts with multiple signers. Sorry if I
was perceived as overselling it :-)

So to summarize the discussions that have been on-going here as well as in
the PR so far, most people seem to agree that the BIP is an improvement for
smart-contracts as well as the third-party modification scenario. It comes
at the cost of increased UTXO size due to the additional hash being stored
per transaction with unclaimed outputs and some additional computations.
The additional computation is for the normalized ID computation and the
swapping in of normalized IDs during verification. No additional coin
lookups are needed as they are retrieved and cached anyway when verifying
the transaction. Would everybody agree with this assessment so far?

On the PR there were some additional suggestions of treating singlesig
transactions as 1-of-1 transactions and using Schnorr signatures for the
new opcode. Schnorr has been in the works for a long time and gives a
multitude of advantages, e.g., batch validation, and seems like a good
addition. Since the verify flag is mandatory due to the soft-fork migration
and we might merge singlesig and multisig into a single opcode we can
replace the bitmap of flags with a simple version number. Clients would
fall back to OP_NOP behaviour for versions they do not implement,
maintaining soft-fork semantics to build more future signing and
verification methods.

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 transaction
> spending
> > the first one's change output, and it prevents any modification in the
> > multi-signer scenario.
>
> For ordinary transactions which are not performing interesting smart
> contracts that particular is better addressed via canonical encoding,
> which is immediately available and doesn't have the associated costs
> (new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
> to fixup txid references, etc.).
>
> Please, as I said up-thread: this is good and importantstuff to work
> on, but it shouldn't be oversold.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 is a lot we can do about it even if we instate a canonical
ordering. Even if we order the inputs and outputs the signer can just add a
new input and output and we would have a different transaction.

Normalized transaction IDs do help in the case that the single signer wants
to immediately follow up its transaction with another transaction spending
the first one's change output, and it prevents any modification in the
multi-signer scenario.

On Thu, Oct 22, 2015 at 1:21 AM Luke Dashjr  wrote:

> On Wednesday, October 21, 2015 6:22:25 PM Danny Thorpe wrote:
> > Let's keep canonical ordering separate from the normalized transaction ID
> > proposal. Baby steps. Normalized transaction IDs provide an immediate
> > benefit against the hazard of third party manipulation of transactions in
> > the mempool, even without canonical ordering.
>
> My point is that third-party manipulation is not much more of a problem
> than
> signing-party manipulation. Solving the former (at a high cost), without
> solving the latter, seems not worth it IMO.
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 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 to come up with anything better and
>> > not being successful.
>>
>> Oh good. Luke solved it.
>>
>> To deploy SW without a disruptive flag day this encoding could be used:
>>
>> A new P2SH like scriptPubkey type is defined. In the soft-fork, the
>> scriptsig for this scriptPubkey is required to be empty.
>>
>> Signatures are not covered under txid, but carried along side. Then
>> committed to in blocks in a separate hashtree.
>>
>>
> Isn't that sort of what this BIP describes as well? Except that we use the
> scriptSig to transport the signatures internally to the transactions and
> strip them when it comes to signing/checking? The wire format and transport
> of transactions do not change so old clients continue to fetch and process
> transactions as before, they just can't verify the TX. Blocks still
> reference the instance but verification uses the stripped TX with the
> signatures on the side, etc.
>
>
>> The only disadvantage to the approach used in elements alpha that I
>> can come up with so far (in the few minutes since luke turned my can't
>> into a can) is that that the approach in EA did not disrupt the normal
>> relay handling process, and this would, since relay that transports
>> the extradata either needs to use a different hash that includes the
>> witness, or have a separate mechanism for witness transport.
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 to come up with anything better and
> > not being successful.
>
> Oh good. Luke solved it.
>
> To deploy SW without a disruptive flag day this encoding could be used:
>
> A new P2SH like scriptPubkey type is defined. In the soft-fork, the
> scriptsig for this scriptPubkey is required to be empty.
>
> Signatures are not covered under txid, but carried along side. Then
> committed to in blocks in a separate hashtree.
>
>
Isn't that sort of what this BIP describes as well? Except that we use the
scriptSig to transport the signatures internally to the transactions and
strip them when it comes to signing/checking? The wire format and transport
of transactions do not change so old clients continue to fetch and process
transactions as before, they just can't verify the TX. Blocks still
reference the instance but verification uses the stripped TX with the
signatures on the side, etc.


> The only disadvantage to the approach used in elements alpha that I
> can come up with so far (in the few minutes since luke turned my can't
> into a can) is that that the approach in EA did not disrupt the normal
> relay handling process, and this would, since relay that transports
> the extradata either needs to use a different hash that includes the
> witness, or have a separate mechanism for witness transport.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 be gained about the spender. Maybe we can defer to
that effort?

On Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr  wrote:

> On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> > 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 worth the cost, especially if
> closing
> > > > > malleability later on would need more. How about specifying flags
> > >
> > > upfront
> > >
> > > > > in the UTXO-creating transaction specifying which parts the
> signature
> > > > > will cover? This would allow implementation of fully
> > > > > malleability-proof wallets.
> > > >
> > > > As far as I see it the only remaining venues for malleability are the
> > > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the
> > > > BIP. Any
> > >
> > > use
> > >
> > > > of non-sighash_all flags is already an explicit permission to modify
> > > > the transactions, by adding and removing inputs and outputs, so I
> > > > don't see
> > >
> > > how
> > >
> > > > these can be made non-malleable. Am I missing something?
> > >
> > > Signer malleability is still a notable concern needing consideration.
> > > Ideally,
> > > wallets should be trying to actively CoinJoin, bump fees on, etc any
> > > pending
> > > transactions in the background. These forms of malleability affect
> nearly
> > > as
> > > many real use cases as third-party malleability.
> > >
> > > Luke
> >
> > How is signer malleability still a problem if we remove the signatures
> from
> > the transaction ID of the transaction and all preceding transactions? The
> > signer can re-sign a transaction but it won't change the transaction ID.
>
> The signer can also change the order of the inputs, the inputs themselves,
> add/remove outputs, etc... all which should be possible without becoming a
> different logical transaction. The only unique property of the logical
> transaction is the scriptPubKey/address.
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 worth the cost, especially if closing
> > > malleability later on would need more. How about specifying flags
> upfront
> > > in the UTXO-creating transaction specifying which parts the signature
> > > will cover? This would allow implementation of fully malleability-proof
> > > wallets.
> >
> > As far as I see it the only remaining venues for malleability are the use
> > of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any
> use
> > of non-sighash_all flags is already an explicit permission to modify the
> > transactions, by adding and removing inputs and outputs, so I don't see
> how
> > these can be made non-malleable. Am I missing something?
>
> Signer malleability is still a notable concern needing consideration.
> Ideally,
> wallets should be trying to actively CoinJoin, bump fees on, etc any
> pending
> transactions in the background. These forms of malleability affect nearly
> as
> many real use cases as third-party malleability.
>
> Luke
>

How is signer malleability still a problem if we remove the signatures from
the transaction ID of the transaction and all preceding transactions? The
signer can re-sign a transaction but it won't change the transaction ID.

It is still possible to double-spend transactions that do not have enough
fees, so just starting a new round of CoinJoin is sufficient to bump fees
for all parties that participate, and that would also result in the
double-spent low fee transaction to be discarded, resolving the state of
all coins in the first CoinJoin tx.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 them along with
> the
> > coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> > OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> > how to best refactor the common functionality into reusable blocks. And
> the
> > annotating incoming transactions with their normalized inputs is a bit
> > cumbersome, maye somebody has some pointers here as well?


> This doesn't completely close malleability (which should be documented in
> the
> BIP), so I'm not sure it's worth the cost, especially if closing
> malleability
> later on would need more. How about specifying flags upfront in the UTXO-
> creating transaction specifying which parts the signature will cover? This
> would allow implementation of fully malleability-proof wallets.
>

As far as I see it the only remaining venues for malleability are the use
of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use
of non-sighash_all flags is already an explicit permission to modify the
transactions, by adding and removing inputs and outputs, so I don't see how
these can be made non-malleable. Am I missing something?


>
> Additionally, you have a flag to control whether the opcode behaves as
> VERIFY
> or not. Non-VERIFY is not possible as a softfork (without doing a
> second/new
> P2SH) since it can be negated.
>

Yes, this is my mistake and has been pointed out in the PR, I will amend
the PR to make the verify flag mandatory, which also guarantees that the
top of the stack contains a non-null element, thus resulting in a
successful evaluation on non-updated clients.


>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So what exactly is used to create the normalized txid (sha256 hash of
> what data)? I've read in the linked BIP draft that it will strip the
> 'malleable parts' but didn't understand what exactly will be used to
> calculate the normalized transactions ids and how will the change apply
> retro-active for the transactions so deep buried in the blockchain?
>

The normalization involves two steps:
 - strip the scriptSig scripts in the inputs, i.e., the only part whose
integrity is not guaranteed by the signature itself, by replacing the
scripts with empty strings (var length string of size 0)
 - replace the hashes referencing the outputs being spent with the
normalized hashes of the transaction that created the outputs. This is done
recursively down to the first v2 transactions.

The second part is not yet explained in the draft, but I will amend it as
soon as possible.


> Pubkeys (addresses) can be reused infinitely so what guarantees us
> unique normalized txids all the time and protection against replay
> attacks? The question is not if this issue is covered or not, I know it
> is, I am just asking how, in simpler terms.
>

Non-coinbase transactions can still not be replayed since the normalized
transaction still includes a the normalized transaction hashes of claimed
outputs, hence any attempt to replay a transaction would fail since the
outputs were already spent. For coinbase transactions it is indeed possible
that we create multiple transactions with the same hash (only one of which
would be spendable), hence we do not strip coinbase transactions and rely
on BIP 34 to make the coinbase transactions unique (except for blocks 91842
and 91880 which are the reason we introduced BIP 34 in the first place).
Clarifying the way the normalized transaction ID is computed should remove
any ambiguities I hope.


>
> SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document.
>
> Will it also fix > third level malleability (a tx which spends from
> another unconfirmed tx which spends from yet another unconfirmed tx)?
>

Yes, if the computation of the normalized transaction ID includes replacing
input hashes with their normalized counterpart makes a chain of any depth
non-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 previous version, which was using a hard-fork, the
> > normalized transaction ID is computed only considering the
> > non-malleable parts of a transaction, i.e., stripping the signatures
> > before computing the hash of the transaction.
> > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
> >
> > Is this proposal recursive?
> >
> > *Coinbase transaction
> > *
> >
> > * n-txid = txid
> >
> > *Non-coinbase transactions
> > *
> > * replace sigScripts with empty strings
> > * replace txids in TxIns with n-txid for parents
> >
> > The 2nd step is recursive starting from the coinbases.
> >
> > In effect, the rule is that txids are what they would have been if
> > n-txids had been used right from the start.
> >
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

Yes, this has been pointed out in the PR as well. Transactions inputs must
also be normalized by replacing malleable hashes with the normalized
hashes. I will fix the spec and the implementation to reflect this :-)

Regards,
Christian

On Mon, Oct 19, 2015 at 5:24 PM Tier Nolan via bitcoin-dev <
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 computed only considering the non-malleable parts of a
>> transaction, i.e., stripping the signatures before computing the hash of
>> the transaction.
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> Is this proposal recursive?
>
>
> *Coinbase transaction *
>
> * n-txid = txid
>
>
> *Non-coinbase transactions*
> * replace sigScripts with empty strings
> * replace txids in TxIns with n-txid for parents
>
> The 2nd step is recursive starting from the coinbases.
>
> In effect, the rule is that txids are what they would have been if n-txids
> had been used right from the start.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker via bitcoin-dev]

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 considering the non-malleable parts of a
transaction, i.e., stripping the signatures before computing the hash of
the transaction. This ensures that if a transaction is modified, either by
a third party fishing transactions from the network and re-injecting
modified versions or by one of the signers re-signing it, any transaction
that builds on top of it still remains valid. Furthermore it allows the use
of template transactions, unsigned transactions upon which further
transaction can be built before signing the template transaction and
locking the contract.

Unlike the previous proposal, this is a softfork proposal that redefines
OP_NOP4 with an extensible and parameterized version of the signature
checking opcodes, called OP_CHECKSIGEX. Among other things the parameters
allow to specify that an output with an OP_CHECKSIGEX is to be referenced
by the normalized transaction ID that created it, instead of the instance
transaction ID containing malleable signatures. This BIP uses the
normalized transaction IDs exclusively while signing or checking
signatures, they are not used in any network level message as the previous
version would have done, hence there is no change at network level and old
clients should be able to exchange transactions as before and blocks still
reference the transaction instances.

The proposal is implemented (see below), by computing the normalized
transaction ID when adding them to the UTXO and storing them along with the
coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
how to best refactor the common functionality into reusable blocks. And the
annotating incoming transactions with their normalized inputs is a bit
cumbersome, maye somebody has some pointers here as well?

BIP Pull request: https://github.com/bitcoin/bips/pull/224
Implementation: https://github.com/cdecker/bitcoin/commits/normtx

I think in the discussion of my previous proposal, most of you welcomed the
introduction of normalized transaction IDs, were it not for the hardfork. I
hope this proposal adresses the previous concerns and that we can move
forward in adding the normalized transaction IDs to the bitcoin protocol.
That being said, I'm always open to suggestions :-)

Regards,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RE : Visualizations of Votes

[Christian Decker via bitcoin-dev]

Yes, the two dimensions are orthogonal: BIP 100 support and actual size
voting. However there seem to be a few pools which simply vote to support
BIP100, without specifying a desired block size [1], hence I started
tracking both on the same chart, maybe I'll split them into different
charts 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:24 AM, Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hello Nicolas,
>>>
>>> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>>> >> A visualization I would like to see would include:
>>> >
>>> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
>>> >> sipa
>>> > etc) based on what's published in blocks.
>>> >
>>> > If such a vote existed, I would gladly show the pie on BIPxDevs.
>>> > However there is no standard way for miners to vote informally BIP
>>> > they support.
>>>
>>> What about formal votes? Is there a way to visually have them appear
>>> in a pie chart as the votes become apparent in blocks?
>>>
>>> I appreciate good visualizations and am trying to get a (visual)
>>> comparison of the votes on these competing proposals.
>>>
>>> >
>>> >
>>> >
>>> > ___ bitcoin-dev mailing
>>> > list bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>>
>>> - --
>>> http://abis.io ~
>>> "a protocol concept to enable decentralization
>>> and expansion of a giving economy, and a new social good"
>>> https://keybase.io/odinn
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
>>> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
>>> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
>>> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
>>> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
>>> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
>>> =AHv3
>>> -END PGP SIGNATURE-
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RE : Visualizations of Votes

[Christian Decker via bitcoin-dev]

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:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Nicolas,
>
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
> >> A visualization I would like to see would include:
> >
> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
> >> sipa
> > etc) based on what's published in blocks.
> >
> > If such a vote existed, I would gladly show the pie on BIPxDevs.
> > However there is no standard way for miners to vote informally BIP
> > they support.
>
> What about formal votes? Is there a way to visually have them appear
> in a pie chart as the votes become apparent in blocks?
>
> I appreciate good visualizations and am trying to get a (visual)
> comparison of the votes on these competing proposals.
>
> >
> >
> >
> > ___ bitcoin-dev mailing
> > list bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
> =AHv3
> -END PGP SIGNATURE-
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev