Anthony Towns via bitcoin-dev wrote:
[SNIP]
>
> 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
On Thu, Oct 03, 2019 at 01:08:29PM +0200, Christian Decker wrote:
> > * 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
> >
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
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
> > let me propose the more radical excision, starting with SegWit v1:
> >
> > - Remove `SIGHASH` from signatures.
> > - Put `SIGHASH` on public keys.
> > OP_SETPUBKEYSIGHASH
> >
>
> I don't think you could reasonably do this for key path spends -- if
> you included the sighash as part
On Wed, Oct 02, 2019 at 02:03:43AM +, ZmnSCPxj via Lightning-dev wrote:
> So let me propose the more radical excision, starting with SegWit v1:
> * Remove `SIGHASH` from signatures.
> * Put `SIGHASH` on public keys.
> OP_SETPUBKEYSIGHASH
I don't think you could reasonably do this for
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
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
Good morning aj,
> On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> > `OP_CHECKSIG_WITHOUT_INPUT`.
>
> I don't think there's any meaningful difference between making a new
> opcode and making a new
Good morning Christian,
> > - 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
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote:
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
I don't think there's any meaningful difference between making a new
opcode and making a new tapscript public key type; the
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,
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
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
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
Good morning list,
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
Good morning Christian,
> The concern with output tagging is that it hurts fungibility, marking outputs
> used in a contract as such and making them identifiable. But maybe it would be
> a good idea to create two domains anyway: one for user-addressable
> destinations which users can use with
17 matches
Mail list logo
