On Thu, Jun 27, 2013 at 9:03 AM, Arthur Gervais <arthur.gerv...@inf.ethz.ch> wrote: > affecting the same Bitcoin version. However we think it is > complementary, since our reported problem has nothing to do with fees, > dust, nor is it necessary to send the two double-spending transaction at > the same time. In our setting, double-spending still works if the second > transaction is sent after minutes (and the first transaction has not yet > been included into a block).
It works just the same for dust based or any other criteria that makes transactions non-standard— including the double spending working if the second transaction is sent minutes after. Exactly the same code is executed and the same behavior observed for any case of a non-standard transaction being used to achieve inconsistent forwarding. > Our only intention is to raise the awareness for merchants who have to > accept zero-confirmation transactions. That is great and I'm certainly glad to see people doing that. Though take care it that your focus on signature encoding differences doesn't create a misunderstanding. This isn't only an issue with these particular versions: There is always mining and relay behavior inhomogeneity in the network. The level of inhomogeneity changes over time— I believe its greatest when new reference client software that changes IsStandard but it is never zero as there are large miners with customized acceptance rules (also mempool state also creates inhomogeneity). The greater inhomogeneity results in higher success rates which may be important since some service could conceivable only be profitable exploited with a high enough success rate. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
