Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-14 📝 Original message:Ok, I think I got the ...

📅 Original date posted:2015-05-14
📝 Original message:Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes the prevout and calculates its normalized transaction ID. It
then inserts the normalized transaction IDs in the OutPoint before
calculating its own hash which is then signed. Is that correct so far?

Let me try to summarize the discussion so far:

I think we have consensus that transaction malleability needs to be
addressed, and normalized transaction IDs seem to be the way to go forward.

The discussion now is how to use normalized transaction IDs and we have two
approaches to implement them:

- OP_CHECKAWESOMESIG which continues to use the current hashes to
reference a specific signed instance of a class of semantically identical
transactions. Internally only the semantic class is enforced. Transactions
can be fixed to reference the correct signed instance if the transaction
has been changed along the way.is a softfork using the "if I don't know
this opcode the TX is automatically valid" trick


On Thu, May 14, 2015 at 2:40 AM Pieter Wuille <pieter.wuille at gmail.com>
wrote:

> On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>>
>> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille at gmail.com>
>> wrote:
>>
>>>
>>> This was what I was suggesting all along, sorry if I wasn't clear.
>>>
>>> That's great. So, basically the multi-level refund problem is solved by
>> this?
>>
>
> Yes. So to be clear, I think there are 2 desirable end-goal proposals
> (ignoring difficulty of changing things for a minute):
>
> * Transactions and blocks keep referring to other transactions by full
> txid, but signature hashes are computed off normalized txids (which are
> recursively defined to use normalized txids all the way back to coinbases).
> Is this what you are suggesting now as well?
>
> * Blocks commit to full transaction data, but transactions and signature
> hashes use normalized txids.
>
> The benefit of the latter solution is that it doesn't need "fixing up"
> transactions whose inputs have been malleated, but comes at the cost of
> doing a very invasive hard fork.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150514/7291d57f/attachment.html>;