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] [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] [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 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] 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

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

[Ethan Heilman via bitcoin-dev]

To avoid derailing the NO_INPUT conversation, I have changed the
subject to OP_CAT.

Responding to:
"""
* `SIGHASH` flags attached to signatures are a misdesign, sadly
retained from the original BitCoin 0.1.0 Alpha for Windows design, on
par with:
[..]
* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
[..]
"""

OP_CAT is an extremely valuable op code. I understand why it was
removed as the situation at the time with scripts was dire. However
most of the protocols I've wanted to build on Bitcoin run into the
limitation that stack values can not be concatenated. For instance
TumbleBit would have far smaller transaction sizes if OP_CAT was
supported in Bitcoin. If it happens to me as a researcher it is
probably holding other people back as well. If I could wave a magic
wand and turn on one of the disabled op codes it would be OP_CAT.  Of
course with the change that size of each concatenated value must be 64
Bytes or less.


On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
 wrote:
>
> Good morning lists,
>
> Let me propose the below radical idea:
>
> * `SIGHASH` flags attached to signatures are a misdesign, sadly retained from 
> the original BitCoin 0.1.0 Alpha for Windows design, on par with:
>   * 1 RETURN
>   * higher-`nSequence` replacement
>   * DER-encoded pubkeys
>   * unrestricted `scriptPubKey`
>   * Payee-security-paid-by-payer (i.e. lack of P2SH)
>   * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
>   * transaction malleability
>   * probably many more
>
> So let me propose the more radical excision, starting with SegWit v1:
>
> * Remove `SIGHASH` from signatures.
> * Put `SIGHASH` on public keys.
>
> Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 
> 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey 
> coordinate).
> `OP_CHECKSIG` and friends then look at the *public key* to determine sighash 
> algorithm rather than the signature.
>
> As we expect public keys to be indirectly committed to on every output 
> `scriptPubKey`, this is automatically output tagging to allow particular 
> `SIGHASH`.
> However, we can then utilize the many many ways to hide public keys away 
> until they are needed, exemplified in MAST-inside-Taproot.
>
> I propose also the addition of the opcode:
>
>   OP_SETPUBKEYSIGHASH
>
> * `sighash` must be one byte.
> * `pubkey` may be the special byte `0x1`, meaning "just use the Taproot 
> internal pubkey".
> * `pubkey` may be 33-byte public key, in which case the `sighash` byte is 
> just prepended to it.
> * `pubkey` may be 34-byte public key with sighash, in which case the first 
> byte is replaced with `sighash` byte.
> * If `sighash` is `0x00` then the result is a 33-byte public key (the sighash 
> byte is removed) i.e. `SIGHASH_ALL` implicit.
>
> This retains the old feature where the sighash is selected at 
> time-of-spending rather than time-of-payment.
> This is done by using the script:
>
>  OP_SETPUBKEYSIGHASH OP_CHECKSIG
>
> Then the sighash can be put in the witness stack after the signature, letting 
> the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT 
> specifically is formed to do so.
> This is malleability-safe as the signature still commits to the `SIGHASH` it 
> was created for.
>
> However, by default, public keys will not have an attached `SIGHASH` byte, 
> implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
>
> This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are 
> allowed only if the output specifically says they are allowed.
>
> Would this not be a superior solution?
>
> 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] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Jeremy via bitcoin-dev]

I've updated the BIP to no longer be based on Taproot, and instead based on
a OP_NOP upgrade. The example implementation and tests have also been
updated.

BIP:
https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki
Implementation:
https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:securethebag_master

The BIP defines OP_NOP4 with the same semantics as previously presented.
This enables OP_SECURETHEBAG for segwit and bare script, but not p2sh
(because of hash cycle, it's impossible to put the redeemscript on the
scriptSig without changing the bag hash). The implementation also makes a
bare OP_SECURETHEBAG script standard as that is a common use case.

To address Russel's feedback, once Tapscript is fully prepared (with more
thorough script parsing improvements), multibyte opcodes can be more
cleanly specified.

Best,

Jeremy

n.b. the prior BIP version remains at
https://github.com/JeremyRubin/bips/blob/op-secure-the-bag-taproot/bip-secure-the-bag.mediawiki
--
@JeremyRubin 



On Mon, Jul 8, 2019 at 3:25 AM Dmitry Petukhov  wrote:

> If you make ANYPREVOUTANYSCRIPT signature not the only signature that
> controls this UTXO, but use it solely for restricting the spending
> conditions such as the set of outputs, and require another signature
> that would commit to the whole transaction, you can eliminate
> malleability, for the price of additional signature, of course.
>
>   CHECKSIG  CHECKSIG
>
> (CHECKMULTISIG/CHECKSIGADD might be used instead)
>
> where control-P can even be a pubkey of a key that is publicly known,
> and the whole purpose of control-sig would be to restrict the outputs
> (control-sig would be created with flags meaning ANYPREVOUTANYSCRIPT).
> Because control-sig does not depend on the script and on the current
> input, there should be no circular dependency, and it can be part of
> the redeem script.
>
> P would be the pubkey of the actual key that is needed to spend this
> UTXO, and the signature of P can commit to all the inputs and outputs,
> preventing malleability.
>
> I would like to add that it may make sense to just have 2 additional
> flags for sighash: NOPREVOUT and NOSCRIPT.
>
> NOPREVOUT would mean that previous output is not committed to, and when
> combined with ANYONECANPAY, this will mean ANYPREVOUT/NOINPUT:
> ANYONECANPAY means exclude all inputs except the current, and NOPREVOUT
> means exclude the current input. Thus NOPREVOUT|ANYONECANPAY = NOINPUT
>
> With NOPREVOUT|ANYONECANPAY|NOSCRIPT you would have ANYPREVOUTANYSCRIPT
>
> with NOPREVOUT|NOSCRIPT you can commit to "all the inputs beside the
> current one", which would allow to create a spending restriction like
> "this UTXO, and also one (or more) other UTXO", which might be useful
> to retroactively revoke or transfer the rights to spend certain UTXO
> without actually moving it:
>
> think 'vault' UTXO that is controlled by Alice, but requires additional
> 'control' UTXO to spend. Alice have keys for both 'vault' UTXO, and
> 'control' UTXO, but Bob have only key for 'control' UTXO.
>
> If Bob learnsthat Alice's vault UTXO key is at risk of compromize,
> he spends the control UTXO, and then Alice's ability to spend vault
> UTXO vanishes.
>
> You can use this mechanism to transfer this right to spend if you
> prepare a number of taproot branches with different pairs of (vault,
> control) keys and a chain of transactions that each spend the previous
> control UTXO such that the newly created UTXO becomes controlled by the
> control key of the next pair, together with vault key in that pair.
>
> В Sat, 22 Jun 2019 23:43:22 -0700
> Jeremy via bitcoin-dev  wrote:
>
> > This is insufficient: sequences must be committed to because they
> > affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN
> > too.
> >
> > Any malleability makes this much less useful.
> > --
> > @JeremyRubin 
> > 
> >
> >
> > On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> > > > So with regards to OP_SECURETHEBAG, I am also "not really seeing
> > > > any
> > > reason to
> > > > complicate the spec to ensure the digest is precommitted as part
> > > > of the opcode."
> > >
> > > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> > > (NOINPUT) sighash (Johnson Lau's mentioned this before, but not
> > > sure if it's been spelled out anywhere); ie instead of constructing
> > >
> > >   X = Hash_BagHash( version, locktime, [outputs], [sequences],
> > > num_in )
> > >
> > > and having the script be " OP_SECURETHEBAG" you calculate an
> > > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
> > >
> > >   Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> > >a

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

[ZmnSCPxj via bitcoin-dev]

Good morning Ethan,


> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
>
> -   `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> [..]
>
> -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> [..]
> """
>
> OP_CAT is an extremely valuable op code. I understand why it was
> removed as the situation at the time with scripts was dire. However
> most of the protocols I've wanted to build on Bitcoin run into the
> limitation that stack values can not be concatenated. For instance
> TumbleBit would have far smaller transaction sizes if OP_CAT was
> supported in Bitcoin. If it happens to me as a researcher it is
> probably holding other people back as well. If I could wave a magic
> wand and turn on one of the disabled op codes it would be OP_CAT. Of
> course with the change that size of each concatenated value must be 64
> Bytes or less.

Why 64 bytes in particular?

It seems obvious to me that this 64 bytes is most suited for building Merkle 
trees, being the size of two SHA256 hashes.

However we have had issues with the use of Merkle trees in Bitcoin blocks.
Specifically, it is difficult to determine if a hash on a Merkle node is the 
hash of a Merkle subnode, or a leaf transaction.
My understanding is that this is the reason for now requiring transactions to 
be at least 80 bytes.

The obvious fix would be to prepend the type of the hashed object, i.e. add at 
least one byte to determine this type.
Taproot for example uses tagged hash functions, with a different tag for 
leaves, and tagged hashes are just 
prepend-this-32-byte-constant-twice-before-you-SHA256.

This seems to indicate that to check merkle tree proofs, an `OP_CAT` with only 
64 bytes max output size would not be sufficient.

Or we could implement tagged SHA256 as a new opcode...

Regards,
ZmnSCPxj


>
> On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>
> > Good morning lists,
> > Let me propose the below radical idea:
> >
> > -   `SIGHASH` flags attached to signatures are a misdesign, sadly retained 
> > from the original BitCoin 0.1.0 Alpha for Windows design, on par with:
> > -   1 RETURN
> > -   higher-`nSequence` replacement
> > -   DER-encoded pubkeys
> > -   unrestricted `scriptPubKey`
> > -   Payee-security-paid-by-payer (i.e. lack of P2SH)
> > -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > -   transaction malleability
> > -   probably many more
> >
> > So let me propose the more radical excision, starting with SegWit v1:
> >
> > -   Remove `SIGHASH` from signatures.
> > -   Put `SIGHASH` on public keys.
> >
> > Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 
> > 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey 
> > coordinate).
> > `OP_CHECKSIG` and friends then look at the public key to determine sighash 
> > algorithm rather than the signature.
> > As we expect public keys to be indirectly committed to on every output 
> > `scriptPubKey`, this is automatically output tagging to allow particular 
> > `SIGHASH`.
> > However, we can then utilize the many many ways to hide public keys away 
> > until they are needed, exemplified in MAST-inside-Taproot.
> > I propose also the addition of the opcode:
> >
> >   OP_SETPUBKEYSIGHASH
> >
> >
> > -   `sighash` must be one byte.
> > -   `pubkey` may be the special byte `0x1`, meaning "just use the Taproot 
> > internal pubkey".
> > -   `pubkey` may be 33-byte public key, in which case the `sighash` byte is 
> > just prepended to it.
> > -   `pubkey` may be 34-byte public key with sighash, in which case the 
> > first byte is replaced with `sighash` byte.
> > -   If `sighash` is `0x00` then the result is a 33-byte public key (the 
> > sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> >
> > This retains the old feature where the sighash is selected at 
> > time-of-spending rather than time-of-payment.
> > This is done by using the script:
> >
> >  OP_SETPUBKEYSIGHASH OP_CHECKSIG
> >
> >
> > Then the sighash can be put in the witness stack after the signature, 
> > letting the `SIGHASH` flag be selected at time-of-signing, but only if the 
> > SCRIPT specifically is formed to do so.
> > This is malleability-safe as the signature still commits to the `SIGHASH` 
> > it was created for.
> > However, by default, public keys will not have an attached `SIGHASH` byte, 
> > implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
> > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are 
> > allowed only if the output specifically says they are allowed.
> > Would this not be a superior solution?
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfounda

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

[Ethan Heilman via bitcoin-dev]

I hope you are having an great afternoon ZmnSCPxj,

You make an excellent point!

I had thought about doing the following to tag nodes

|| means OP_CAT

`node = SHA256(type||SHA256(data))`
so a subnode would be
`subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
and a leaf node would be
`leafnode = SHA256(0||SHA256(leafdata))`

Yet, I like your idea better. Increasing the size of the two inputs to
OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable
size of object on the stack seems sensible and also doesn't special
case the logic of OP_CAT.

It would also increase performance. SHA256(tag||subnode2||subnode3)
requires 2 compression function calls whereas
SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression
function calls (due to padding).

>Or we could implement tagged SHA256 as a new opcode...

I agree that tagged SHA256 as an op code that would certainty be
useful, but OP_CAT provides far more utility and is a simpler change.

Thanks,
Ethan

On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj  wrote:
>
> Good morning Ethan,
>
>
> > To avoid derailing the NO_INPUT conversation, I have changed the
> > subject to OP_CAT.
> >
> > Responding to:
> > """
> >
> > -   `SIGHASH` flags attached to signatures are a misdesign, sadly
> > retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> > par with:
> > [..]
> >
> > -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > [..]
> > """
> >
> > OP_CAT is an extremely valuable op code. I understand why it was
> > removed as the situation at the time with scripts was dire. However
> > most of the protocols I've wanted to build on Bitcoin run into the
> > limitation that stack values can not be concatenated. For instance
> > TumbleBit would have far smaller transaction sizes if OP_CAT was
> > supported in Bitcoin. If it happens to me as a researcher it is
> > probably holding other people back as well. If I could wave a magic
> > wand and turn on one of the disabled op codes it would be OP_CAT. Of
> > course with the change that size of each concatenated value must be 64
> > Bytes or less.
>
> Why 64 bytes in particular?
>
> It seems obvious to me that this 64 bytes is most suited for building Merkle 
> trees, being the size of two SHA256 hashes.
>
> However we have had issues with the use of Merkle trees in Bitcoin blocks.
> Specifically, it is difficult to determine if a hash on a Merkle node is the 
> hash of a Merkle subnode, or a leaf transaction.
> My understanding is that this is the reason for now requiring transactions to 
> be at least 80 bytes.
>
> The obvious fix would be to prepend the type of the hashed object, i.e. add 
> at least one byte to determine this type.
> Taproot for example uses tagged hash functions, with a different tag for 
> leaves, and tagged hashes are just 
> prepend-this-32-byte-constant-twice-before-you-SHA256.
>
> This seems to indicate that to check merkle tree proofs, an `OP_CAT` with 
> only 64 bytes max output size would not be sufficient.
>
> Or we could implement tagged SHA256 as a new opcode...
>
> Regards,
> ZmnSCPxj
>
>
> >
> > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> >
> >
> > > Good morning lists,
> > > Let me propose the below radical idea:
> > >
> > > -   `SIGHASH` flags attached to signatures are a misdesign, sadly 
> > > retained from the original BitCoin 0.1.0 Alpha for Windows design, on par 
> > > with:
> > > -   1 RETURN
> > > -   higher-`nSequence` replacement
> > > -   DER-encoded pubkeys
> > > -   unrestricted `scriptPubKey`
> > > -   Payee-security-paid-by-payer (i.e. lack of P2SH)
> > > -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > -   transaction malleability
> > > -   probably many more
> > >
> > > So let me propose the more radical excision, starting with SegWit v1:
> > >
> > > -   Remove `SIGHASH` from signatures.
> > > -   Put `SIGHASH` on public keys.
> > >
> > > Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) 
> > > or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey 
> > > coordinate).
> > > `OP_CHECKSIG` and friends then look at the public key to determine 
> > > sighash algorithm rather than the signature.
> > > As we expect public keys to be indirectly committed to on every output 
> > > `scriptPubKey`, this is automatically output tagging to allow particular 
> > > `SIGHASH`.
> > > However, we can then utilize the many many ways to hide public keys away 
> > > until they are needed, exemplified in MAST-inside-Taproot.
> > > I propose also the addition of the opcode:
> > >
> > >   OP_SETPUBKEYSIGHASH
> > >
> > >
> > > -   `sighash` must be one byte.
> > > -   `pubkey` may be the special byte `0x1`, meaning "just use the Taproot 
> > > internal pubkey".
> > > -   `pubkey` may be 33-byte public key, in which case the `sighash` byte 
> > > is just

[bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

[Dave Scotese via bitcoin-dev]

Currently, bitcoin must be redeemed by providing input to a script which
results in the required output.  This causes the attached amount of bitcoin
to become available for use in the outputs of a transaction.  Is there any
work on creating a shorter "transaction" which, instead of creating a new
output, points to (creates a virtual copy of) an existing (unspent) output
with a larger amount attached to it?  This would invalidate the smaller,
earlier UTXO and replace it with the new one without requiring the earlier
one to be redeemed, and also without requiring the original script to be
duplicated.  It is a method for aggregating bitcoin to a UTXO which may
otherwise not be economically viable.

The idea is that there already exists a script that must be satisfied to
spend X1, and if the owner of X1 would like to have the same requirements
for spending X2, this would be a transaction that does that using fewer
data bytes.  Since the script already exists, the transaction can simply
point to it instead of duplicating it.

This would also enable the capacity of lightning channels to be increased
on the fly without closing the existing channel and re-opening a new one.
The LN layer would have to cope with the possibility that the "short
channel ID" could change.

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

[bitcoin-dev] PSBT global key for network

[Jimmy Song via bitcoin-dev]

Hey all,

I wanted to propose a new key in the global context for BIP174,
Partially-Signed Bitcoin Transactions.

= Rationale

Each signer should make sure that the inputs being referenced in the PSBT
exist (with the exception of a Proof-of-Reserves input). In order to do
this, it's critical to know which network the coins are on (mainnet or
testnet). This could potentially be extended to other networks should they
want to use something like PSBT, much in the same way that HD keys from
BIP0044 reserved 0' and 1' as coins for mainnet Bitcoin and testnet Bitcoin
respectively.

= Proposal

Add the key 0x03 for network in the global key-value store. Value is a
variable integer with 0x00 indicating Bitcoin mainnet and 0x01 indicating
Bitcoin testnet. Other coins that want to use the PSBT should use the coin
network number from SLIP-0044 with the high bit removed.

---

Best,

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

[bitcoin-dev] Chain width expansion

[Braydon Fuller via bitcoin-dev]

Hi everyone,

We would like to share a paper for broad discussion, it is titled
"Bitcoin Chain Width Expansion Denial-of-Service Attacks".

>From the abstract: The attacks leverage unprotected resources for a
denial-of-service by filling the disk and exhausting the CPU with
unnecessary header and block data. This forces the node to halt
operation. The attack difficulty ranges from difficult to easy. There
are currently limited guards for some of the attacks that require
checkpoints to be enabled. This paper describes a solution that does not
require enabling or maintaining checkpoints and provides improved security.

As the checkpoints in Bitcoin Core have not been maintained or updated
since mid 2014, this is especially relevant. Bitcoin Core implements
headers-first synchronization, since 2014, that provides the base for
the further improvements upon that design.

The paper is available at:
https://bcoin.io/papers/bitcoin-chain-expansion.pdf

The proposed solution has been implemented in Bcoin and is available at:
https://github.com/bcoin-org/bcoin/tree/chain-expansion

Best,
Braydon Fuller

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

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

[Jeremy via bitcoin-dev]

Awhile back, Ethan and I discussed having, rather than OP_CAT, an
OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
function to allow concatenation of an unlimited amount of data, provided
the only use is to hash it.

You can then use it perhaps as follows:

// start a new hash with item
OP_SHA256STREAM  (-1) -> [state]
// Add item to the hash in state
OP_SHA256STREAM n [item] [state] -> [state]
// Finalize
OP_SHA256STREAM (-2) [state] -> [Hash]

<-1> OP_SHA256STREAM<3> OP_SHA256STREAM <-2>
OP_SHA256STREAM


Or it coul



--
@JeremyRubin 



On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman  wrote:

> I hope you are having an great afternoon ZmnSCPxj,
>
> You make an excellent point!
>
> I had thought about doing the following to tag nodes
>
> || means OP_CAT
>
> `node = SHA256(type||SHA256(data))`
> so a subnode would be
> `subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
> and a leaf node would be
> `leafnode = SHA256(0||SHA256(leafdata))`
>
> Yet, I like your idea better. Increasing the size of the two inputs to
> OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable
> size of object on the stack seems sensible and also doesn't special
> case the logic of OP_CAT.
>
> It would also increase performance. SHA256(tag||subnode2||subnode3)
> requires 2 compression function calls whereas
> SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression
> function calls (due to padding).
>
> >Or we could implement tagged SHA256 as a new opcode...
>
> I agree that tagged SHA256 as an op code that would certainty be
> useful, but OP_CAT provides far more utility and is a simpler change.
>
> Thanks,
> Ethan
>
> On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj  wrote:
> >
> > Good morning Ethan,
> >
> >
> > > To avoid derailing the NO_INPUT conversation, I have changed the
> > > subject to OP_CAT.
> > >
> > > Responding to:
> > > """
> > >
> > > -   `SIGHASH` flags attached to signatures are a misdesign, sadly
> > > retained from the original BitCoin 0.1.0 Alpha for Windows design,
> on
> > > par with:
> > > [..]
> > >
> > > -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > [..]
> > > """
> > >
> > > OP_CAT is an extremely valuable op code. I understand why it was
> > > removed as the situation at the time with scripts was dire. However
> > > most of the protocols I've wanted to build on Bitcoin run into the
> > > limitation that stack values can not be concatenated. For instance
> > > TumbleBit would have far smaller transaction sizes if OP_CAT was
> > > supported in Bitcoin. If it happens to me as a researcher it is
> > > probably holding other people back as well. If I could wave a magic
> > > wand and turn on one of the disabled op codes it would be OP_CAT.
> Of
> > > course with the change that size of each concatenated value must
> be 64
> > > Bytes or less.
> >
> > Why 64 bytes in particular?
> >
> > It seems obvious to me that this 64 bytes is most suited for building
> Merkle trees, being the size of two SHA256 hashes.
> >
> > However we have had issues with the use of Merkle trees in Bitcoin
> blocks.
> > Specifically, it is difficult to determine if a hash on a Merkle node is
> the hash of a Merkle subnode, or a leaf transaction.
> > My understanding is that this is the reason for now requiring
> transactions to be at least 80 bytes.
> >
> > The obvious fix would be to prepend the type of the hashed object, i.e.
> add at least one byte to determine this type.
> > Taproot for example uses tagged hash functions, with a different tag for
> leaves, and tagged hashes are just
> prepend-this-32-byte-constant-twice-before-you-SHA256.
> >
> > This seems to indicate that to check merkle tree proofs, an `OP_CAT`
> with only 64 bytes max output size would not be sufficient.
> >
> > Or we could implement tagged SHA256 as a new opcode...
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > >
> > > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > >
> > >
> > > > Good morning lists,
> > > > Let me propose the below radical idea:
> > > >
> > > > -   `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on par
> with:
> > > > -   1 RETURN
> > > > -   higher-`nSequence` replacement
> > > > -   DER-encoded pubkeys
> > > > -   unrestricted `scriptPubKey`
> > > > -   Payee-security-paid-by-payer (i.e. lack of P2SH)
> > > > -   `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > > > -   transaction malleability
> > > > -   probably many more
> > > >
> > > > So let me propose the more radical excision, starting with SegWit v1:
> > > >
> > > > -   Remove `SIGHASH` from signatures.
> > > > -   Put `SIGHASH` on public keys.
> > > >
> > > > Public keys are now encoded as either 33-bytes (implicit
> `SIGHASH_A

Re: [bitcoin-dev] PSBT global key for network

[木ノ下じょな via bitcoin-dev]

Hi Jimmy,

The only time I could see this being a problem is in the case of a
fork-coin.
Otherwise the likelihood that two unrelated networks could have a tx with
an id that is identical are low.

Everything included in PSBT thus far is info for verifying something
helpful, and providing the information needed for signing and verifying
what will be signed.

Adding a network section will be the inverse of that. The info doesn't help
you verify anything, since I could lie about the network, and you will need
to go out and check the network is as the PSBT says it is anyways.
Network is also not needed for signing.

In fact, come to think of it, even if there was a fork-coin incident, even
if you were able to separate PSBTs via network info, it won't matter if
there's no replay protection anyways, so giving a false sense of security
in thinking "I have explicitly stated my network so I should be ok"
(developers will think this, I guarantee) is actually a security minus IMO.

Currently BitcoinJS only uses network parameters to allow for the use of
addresses in addOutput... but I'm starting to think we should remove it...
not sure...

Cheers,
Jon

2019年10月4日(金) 11:04 Jimmy Song via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Hey all,
>
> I wanted to propose a new key in the global context for BIP174,
> Partially-Signed Bitcoin Transactions.
>
> = Rationale
>
> Each signer should make sure that the inputs being referenced in the PSBT
> exist (with the exception of a Proof-of-Reserves input). In order to do
> this, it's critical to know which network the coins are on (mainnet or
> testnet). This could potentially be extended to other networks should they
> want to use something like PSBT, much in the same way that HD keys from
> BIP0044 reserved 0' and 1' as coins for mainnet Bitcoin and testnet Bitcoin
> respectively.
>
> = Proposal
>
> Add the key 0x03 for network in the global key-value store. Value is a
> variable integer with 0x00 indicating Bitcoin mainnet and 0x01 indicating
> Bitcoin testnet. Other coins that want to use the PSBT should use the coin
> network number from SLIP-0044 with the high bit removed.
>
> ---
>
> Best,
>
> Jimmy
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
-BEGIN PGP PUBLIC KEY BLOCK-
Comment: http://openpgpjs.org

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-END PGP PUBLIC KEY BLOCK-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

[ZmnSCPxj via bitcoin-dev]

Good morning David,

> Currently, bitcoin must be redeemed by providing input to a script which 
> results in the required output.  This causes the attached amount of bitcoin 
> to become available for use in the outputs of a transaction.  Is there any 
> work on creating a shorter "transaction" which, instead of creating a new 
> output, points to (creates a virtual copy of) an existing (unspent) output 
> with a larger amount attached to it?  This would invalidate the smaller, 
> earlier UTXO and replace it with the new one without requiring the earlier 
> one to be redeemed, and also without requiring the original script to be 
> duplicated.  It is a method for aggregating bitcoin to a UTXO which may 
> otherwise not be economically viable.
>
> The idea is that there already exists a script that must be satisfied to 
> spend X1, and if the owner of X1 would like to have the same requirements for 
> spending X2, this would be a transaction that does that using fewer data 
> bytes.  Since the script already exists, the transaction can simply point to 
> it instead of duplicating it.
>
> This would also enable the capacity of lightning channels to be increased on 
> the fly without closing the existing channel and re-opening a new one.  The 
> LN layer would have to cope with the possibility that the "short channel ID" 
> could change.
>
> Dave.

This moves us closer to an "account"-style rather than "UTXO"-style.
The advantage of UTXO-style is that it becomes easy to validate a transaction 
as valid when putting it into the mempool, and as long as the UTXO it consumes 
remains valid, revalidation of the transaction when it is seen in a block is 
unnecessary.

Admittedly, the issue with account-style is when the account is overdrawn --- 
with UTXOs every spend drains the entire "account" and the "account" 
subsequently is definitely no longer spendable, whereas with accounts, every 
fullnode has to consider what would happen if two or more transactions spend 
from the account.
In your case, it seems to just *add* to the amount of a UTXO.

In any case, this might not be easy to implement in current Bitcoin.
The UTXO-style is deeply ingrained to Bitcoin design, and cannot be easily 
hacked in a softfork.

See also 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017135.html 
and its thread for the difficulties involved with "just copy some existing 
`scriptPubKey`" and why such a thing will be very unlikely to come in Bitcoin.


But I think this can be done, in spirit, by pay-to-endpoint / payjoin.

In P2EP/Payjoin, the payer contacts the payee and offers to coinjoin 
simultaneously to the payment.
This does what you want:

* Refers to a previous UTXO owned by the payee, and deletes it (by normal 
transaction spending rules).
* Creates a new UTO, owned by the payee, which contains the total value of the 
below:
  * The above old UTXO.
  * The value to be transferred from payer to payee.

The only issues are that:

* Payee has to be online and cooperate.
* Payee has to provide signatures for the old UTXO, adding more blockchain data.
* New UTXO has to publish a SCRIPT too.
  * In terms of *privacy*, of course you *have* to use a new SCRIPT with a new 
public key anyway.
Thus this is superior to your proposal where the pubkey is reused, as 
P2EP/Payjoin preserves privacy.


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