zaki at manian.org [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: sighhash_noinput is the ...
📅 Original date posted:2015-11-19
📝 Original message:
sighhash_noinput is the miner chooses which which utxo is consumed assuming
there are multiple candidates variant of the idea?
On Thu, Nov 19, 2015 at 11:12 AM, Tadge Dryja <tadge at lightning.network>
wrote:
> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses many
> vectors for txid malleability, but maybe there are more. And more
> importantly, it addresses 3rd party malleability. It's not helpful in the
> context of lightning channel creation because ECDSA sigs are inherently
> malleable. You can always re-sign the same message with a different
> k-value and get a different signature.
>
> The functionality that's needed is to be able to reliably spend from
> unconfirmed transactions. Segregated witness can accomplish that, but it
> quite a large hard-fork change. sighash_noinput can also accomplish that:
> as input txids are not signed, if they change, the spending transaction can
> be modified while leaving counterparty signatures intact.
>
> I'm hoping to start a new "testnet-L" similar to testnet3, with this
> sighash type so that we can test malleability mitigation out.
>
> (Oh also, hi mailing list, sorry I have not posted till now! But I will
> start posting!)
>
> -Tadge
>
> On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> The basic idea of the soft-fork plan is very simple --- have the
>> scriptPubKey be just the 20-byte hash of the redeem script. The scriptSig
>> of the spending input is empty. The actual scriptSig, with the redeem
>> script and signatures, is contained in a separate Merkle tree committed to
>> elsewhere in the block (e.g. in the last output of the coinbase, or the
>> last output of the last transaction).
>>
>> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com>
>> wrote:
>>
>>> The hardfork variant is quite simple, if I understood it correctly. You
>>> just stick the signatures in another parallel merkle tree. So if you don't
>>> want to validate signatures, just don't download them, and validate
>>> everything else. TXIDs don't use the signature at all. Nothing to malleate,
>>> AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
>>> Bitcoin HK.
>>>
>>> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
>>> wrote:
>>>
>>>>
>>>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Pierre
>>>>>
>>>>> you could start here
>>>>>
>>>>>
>>>>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>>>>
>>>>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>>>>> https://github.com/ElementsProject/elements
>>>>
>>>>
>>>> There was a brief blip on Reddit:
>>>>
>>>>
>>>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>>>
>>>> Its weird how little information there is on Segregated Witness. I'm
>>>> guessing its a simple concept and those working on it (sipa / gmaxwell)
>>>> haven't felt the need to write it up.
>>>>
>>>> That it "apparently" can be done with a soft fork similar to P2SH is
>>>> good news... I guess...
>>>>
>>>>
>>>> --
>>>> Glenn H. Tarbox, PhD
>>>> =]|[=
>>>>
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/10a65b2f/attachment-0001.html>;
📝 Original message:
sighhash_noinput is the miner chooses which which utxo is consumed assuming
there are multiple candidates variant of the idea?
On Thu, Nov 19, 2015 at 11:12 AM, Tadge Dryja <tadge at lightning.network>
wrote:
> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses many
> vectors for txid malleability, but maybe there are more. And more
> importantly, it addresses 3rd party malleability. It's not helpful in the
> context of lightning channel creation because ECDSA sigs are inherently
> malleable. You can always re-sign the same message with a different
> k-value and get a different signature.
>
> The functionality that's needed is to be able to reliably spend from
> unconfirmed transactions. Segregated witness can accomplish that, but it
> quite a large hard-fork change. sighash_noinput can also accomplish that:
> as input txids are not signed, if they change, the spending transaction can
> be modified while leaving counterparty signatures intact.
>
> I'm hoping to start a new "testnet-L" similar to testnet3, with this
> sighash type so that we can test malleability mitigation out.
>
> (Oh also, hi mailing list, sorry I have not posted till now! But I will
> start posting!)
>
> -Tadge
>
> On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> The basic idea of the soft-fork plan is very simple --- have the
>> scriptPubKey be just the 20-byte hash of the redeem script. The scriptSig
>> of the spending input is empty. The actual scriptSig, with the redeem
>> script and signatures, is contained in a separate Merkle tree committed to
>> elsewhere in the block (e.g. in the last output of the coinbase, or the
>> last output of the last transaction).
>>
>> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com>
>> wrote:
>>
>>> The hardfork variant is quite simple, if I understood it correctly. You
>>> just stick the signatures in another parallel merkle tree. So if you don't
>>> want to validate signatures, just don't download them, and validate
>>> everything else. TXIDs don't use the signature at all. Nothing to malleate,
>>> AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
>>> Bitcoin HK.
>>>
>>> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
>>> wrote:
>>>
>>>>
>>>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Pierre
>>>>>
>>>>> you could start here
>>>>>
>>>>>
>>>>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>>>>
>>>>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>>>>> https://github.com/ElementsProject/elements
>>>>
>>>>
>>>> There was a brief blip on Reddit:
>>>>
>>>>
>>>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>>>
>>>> Its weird how little information there is on Segregated Witness. I'm
>>>> guessing its a simple concept and those working on it (sipa / gmaxwell)
>>>> haven't felt the need to write it up.
>>>>
>>>> That it "apparently" can be done with a soft fork similar to P2SH is
>>>> good news... I guess...
>>>>
>>>>
>>>> --
>>>> Glenn H. Tarbox, PhD
>>>> =]|[=
>>>>
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/10a65b2f/attachment-0001.html>;