Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-25 Thread s7r
Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.

It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying solely
on its txid.

BIP62 is good for preventing 3rd parties (non signers) to mutate txids,
but cannot do anything against 2nd parties (signers). I think we can
solve both by using NORMALIZEDTXID - wouldn't this be simpler and easier
to implement? Why are we talking about P3SH when we can just upgrade
P2SH to support additional OP codes? I saw that there have been talks
about a hard fork for increasing the block size, might as well take the
opportunity and fix this for good, by implementing BIP62, NORMALIZEDTXID
as well as BIP65. Couldn't all these be part of P2SH?

On 4/25/2015 6:40 PM, Stephen Morse wrote:
 Hi Gregory,
 
 In particular not covering the ID allows for transaction replay which
 can result in monetary losses far more severe than any possible
 mishandling of malleability could result in. Byzantine attackers can
 costlessly replay your old transactions any time anyone reuses an
 address, even accidentally (which cannot be easily prevented since
 they can race).
 
 
 With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
 specify that they are to be signed without the previous UTXO's
 value/amount. This means that, at worst, replay attacks can send the
 money to the same place it was sent before (which in many cases is
 likely not be a loss of funds), and only if the amount sent to the
 reused address is the exact same as it was before. I don't think this is
 worse than an attacker being able to mutate their transaction and extort
 a merchant who accepts zero-conf transactions. Anyway, not signing the
 input ID wouldn't exactly be the norm, there would be a defined set of
 flags for standard use cases. Not signing the input TXID would only be
 used in specialized cases, such as setting up micropayment channels. 
  
 
 There are no free lunches;  the proposal linked to there is itself a
 game of wack-a-mole with assorted masking flags; 
 
 
 I agree that it is also a bit of wac-a-mole, but the defined space of
 issues is possibly more limited here. There are only X number of things
 that can be signed/not signed in a transaction, and the 'Build your own
 nHashType' proposal enables you to fully specify which of those are
 being signed. If you don't want to get burned by not fully signing your
 transactions, then don't use the non-standard sighash flags.
 
 many of which we have
 no notion of if they're useful for any particular application(s); 
 
 
 A few of the flags, indeed, may not ever be useful. But we can't predict
 the future, and I think it's better to build in a more flexible solution
 now than to wish we had more flexible nHashTypes later.
 
 To the original point of this thread, hopefully the suggested proposal
 won't be necessary as wallets will upgrade to use version 3 transactions
 and the rules associated with them over time. 
 
 Best,
 Stephen
 
 
 --
 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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-25 Thread Stephen Morse
Hi William,

I personally prefer this solution, since it nails the problem
 completely with one simple and obvious change. The BIP 62 approach is
 more like a game of wac-a-mole.


The two are complementary, not competing. BIP62 prevents *non-signers* from
mutating the transactions, which is very important. The 'Build your own
nHashType' proposal enables chained transactions even in the face of
*signers* mutating the transaction. I believe that integrating both will
lead to the best defense against transaction malleability, and will enable
more complicated uses of chained transactions (such as micropayment
channels).

Best,
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-25 Thread Stephen Morse
Hi Gregory,

In particular not covering the ID allows for transaction replay which
 can result in monetary losses far more severe than any possible
 mishandling of malleability could result in. Byzantine attackers can
 costlessly replay your old transactions any time anyone reuses an
 address, even accidentally (which cannot be easily prevented since
 they can race).


With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
specify that they are to be signed without the previous UTXO's
value/amount. This means that, at worst, replay attacks can send the money
to the same place it was sent before (which in many cases is likely not be
a loss of funds), and only if the amount sent to the reused address is the
exact same as it was before. I don't think this is worse than an attacker
being able to mutate their transaction and extort a merchant who accepts
zero-conf transactions. Anyway, not signing the input ID wouldn't exactly
be the norm, there would be a defined set of flags for standard use cases.
Not signing the input TXID would only be used in specialized cases, such as
setting up micropayment channels.


 There are no free lunches;  the proposal linked to there is itself a
 game of wack-a-mole with assorted masking flags;


I agree that it is also a bit of wac-a-mole, but the defined space of
issues is possibly more limited here. There are only X number of things
that can be signed/not signed in a transaction, and the 'Build your own
nHashType' proposal enables you to fully specify which of those are being
signed. If you don't want to get burned by not fully signing your
transactions, then don't use the non-standard sighash flags.

many of which we have
 no notion of if they're useful for any particular application(s);


A few of the flags, indeed, may not ever be useful. But we can't predict
the future, and I think it's better to build in a more flexible solution
now than to wish we had more flexible nHashTypes later.

To the original point of this thread, hopefully the suggested proposal
won't be necessary as wallets will upgrade to use version 3 transactions
and the rules associated with them over time.

Best,
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development