rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2014-02-20 📝 Original message:We've done forking changes before much faster than a year and that was with less experience. If we want, we can get this done within months. On 20 Feb 2014 16:30, "Michael Gronager" <gronager at mac.com> wrote: > As I see the BIP it is basically stressing that ver 1 transactions are > malleable. > > It then addresses the need for unmalleable transactions for e.g. spending > unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) > - this transaction type is defined as ver 3. > > A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as > such make an implicit assumption that this is kind of safe, which it is not > - it can be intervened and sabotaged through tx malleability. > > What I suggested was to ensure that a subclass of version 1 transactions > become unmalleable - namely those with sighash=all. Note that only the > sender can modify the sighash as it is part of the hash signed. So instead > of defining a version 3, we could constrain version 1 txes with sighash=all > to have a unmalleable hash. If you e.g. would like to still have a > sighash=all type of transaction with malleable features you can simply use > that sighash=all today is checked for using sighash&0x1f=sighash_all, so > just OR'ing with 0x20 or 0x40 will get you the 'old' feature. > > I do however buy the argument of Peter and Gregory that there might exist > unpublished transactions out there that does not even conform to the DER > rules etc, and as such we cannot forbid them from being mined, nor can we > timestamp them and include 'only the old ones'. Hence we cannot change the > consensus rule for version 1 transactions - and only changing the relay > rules will not provide a certain guarantee. > > So, I think the two line argument for the BIP is as follows: > 1. We cannot change the consensus rules for version 1 transactions as that > might invalidate unpublished non-standard transactions (= voiding peoples > money, which is a line we don't want to cross) > 2. The prime usecase for unmalleable transactions is being able to spend > unconfirmed outputs - this is done today by almost all clients, but it is > really broken. Hence a need for a fix asap. > > I am all in favor for the BIP, but I expect the realistic timeline for > enforced version 3 transactions is roughly one year, which is better than > two, but it would have been nice to get it faster... > > /M > > > On Feb 19, 2014, at 10:11 PM, Pieter Wuille <pieter.wuille at gmail.com> > wrote: > > > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com> > wrote: > >> I think that we could guarantee fewer incidents by making version 1 > transactions unmalleable and then optionally introduce a version 3 that > supported the malleability feature. That way most existing problematic > implementations would be fixed and no doors were closed for people > experimenting with other stuff - tx v 3 would probably then be called > experimental transactions. > > > > Just to be clear: this change is not directly intended to avoid > > "incidents". It will take way too long to deploy this. Software should > > deal with malleability. This is a longer-term solution intended to > > provide non-malleability guarantees for clients that a) are upgraded > > to use them b) willing to restrict their functionality. As there are > > several intended use cases for malleable transactions (the sighash > > flags pretty directly are a way to signify what malleabilities are > > *wanted*), this is not about outlawing malleability. > > > > While we could right now make all these rules non-standard, and > > schedule a soft fork in a year or so to make them illegal, it would > > mean removing potential functionality that can only be re-enabled > > through a hard fork. This is significantly harder, so we should think > > about it very well in advance. > > > > About new transaction and block versions: this allows implementing and > > automatically scheduling a softfork without waiting for wallets to > > upgrade. The non-DER signature change was discussed for over two > > years, and implemented almost a year ago, and we still notice wallets > > that don't support it. We can't expect every wallet to be instantly > > modified (what about hardware wallets like the Trezor, for example? > > they may not just be able to be upgraded). Nor is it necessary: if > > your software only spends confirmed change, and tracks all debits > > correctly, there is no need. > > > > -- > > Pieter > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > 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/20140220/41fc69a7/attachment.html>