<unnamed>

Public Key

npub14sz60zalvsz094ekxmgq2xpcsr67a9aljeqcny479lc8mpsp95jqfwv9e3

Profile Code

nprofile1qqs2cpd83wlkgp8j6umrd5q9rqugpa0wj7levsvfj2lzlurascqj6fqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsep807r

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:10:58 UTC

- reply

📅 Original date posted:2018-02-20
📝 Original message:Hello Everybody,
I need a little clarity about how OP_CHECKSEQUENCEVERIFY (CSV) works in
transactions.
Can I use multiple CSV end points as depicted in the figure below? I
basically want to allow different conditions at different delays.
[image: Inline image 3]
I just want to know if OP_CHECKSEQUENCEVERIFY can be used to achieve the
above.
Thank you.
Praveen
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180220/915127e0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi CSV.png
Type: image/png
Size: 119739 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180220/915127e0/attachment-0001.png>

2023-06-07 18:07:50 UTC

- reply

📅 Original date posted:2017-11-20
📝 Original message:BIP 140 looks like it solves Tx Malleability with least impact on current
practices. It is still a soft fork though.
Finally, if we were to create an alternative cyptocurrency similar to
Bitcoin, a Normalized Tx ID approach would be a better choice if I get it
right!
ᐧ
On Mon, Nov 20, 2017 at 11:15 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
> We can’t “just compute the Transaction ID the same way the hash for
> signing the transaction is computed” because with different SIGHASH flags,
> there are 6 (actually 256) ways to hash a transaction.
>
> Also, changing the definition of TxID is a hardfork change, i.e. everyone
> are required to upgrade or a chain split will happen.
>
> It is possible to use “normalised TxID” (BIP140) to fix malleability
> issue. As a softfork, BIP140 doesn’t change the definition of TxID.
> Instead, the normalised txid (i.e. txid with scriptSig removed) is used
> when making signature. Comparing with segwit (BIP141), BIP140 does not have
> the side-effect of block size increase, and doesn’t provide any incentive
> to control the size of UTXO set. Also, BIP140 makes the UTXO set
> permanently bigger, as the database needs to store both txid and normalised
> txid
>
> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized
> into a data structure that is different from the current one where
> signatures are separated from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID
> the same way the hash for signing the transaction is computed?
>
> --
> Dr. Praveen Baratam
>
> about.me <http://about.me/praveen.baratam>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171120/35d7fb17/attachment.html>

2023-06-07 18:07:49 UTC

- reply

📅 Original date posted:2017-11-20
📝 Original message:Bitcoin Noob here. Please forgive my ignorance.
>From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171120/2fc6d1a3/attachment.html>