1 2015-03-28 00:19:35 <kanzure> https://github.com/richardkiss/pycoin/pull/108
 2 2015-03-28 00:19:45 <kanzure> "BUY A LOTTO TICKET RIGHT NOW! You have stumbled across and astronomically unlikely scenario."
 3 2015-03-28 00:26:52 <gmaxwell> kanzure: looking at the issue 107 there creates a bit of concern.
 4 2015-03-28 00:27:18 <kanzure> agreed
 5 2015-03-28 00:27:36 <gmaxwell> it has a long discourse on uniformity from correctly handling the order; ... but correct implementation of BIP32 already requires correctly handling the order (handling of it is specifically called out)
 6 2015-03-28 00:29:47 <gmaxwell> (it specifies using rejection sampling)
 7 2015-03-28 00:42:06 <sipa> ;;blocks
 8 2015-03-28 00:42:07 <gribble> 349573
 9 2015-03-28 00:48:33 <jf_> hi ?
10 2015-03-28 00:49:11 <jf_> nobody here uh ?
11 2015-03-28 02:33:56 <gmaxwell> wumpus: while reiewing your wallet rebroadcasting patch I realized another way to get rid of the conflicted that I missed before.
12 2015-03-28 02:36:05 <gmaxwell> For every wallet transaction add an additional stored flag for 'seen on the network' (which is 0 for never sent, 1 if you've sent it or heard it from a peer, 2 if you've seen it inved more times, etc.).  Is the seen flag is 0 then skip the claim of conflict. Then none of the conflict logic has to change.  Though it's a little less good than changing the conflict logic because a txn could be conflicte
13 2015-03-28 02:36:11 <gmaxwell> d without ever being seen or sent.
14 2015-03-28 05:44:14 <phantomcircuit> gmaxwell, assuming the BIP62 softfork happens what mutation issues are there still?
15 2015-03-28 05:44:57 <phantomcircuit> malleability*
16 2015-03-28 05:45:24 <Luke-Jr> phantomcircuit: "the unknown", CoinJoin, respending with a higher fee, etc
17 2015-03-28 05:47:19 <phantomcircuit> Luke-Jr, right i was thinking stuff that can be done without the private key
18 2015-03-28 05:47:32 <phantomcircuit> so i guess just "unknown" and maybe some weird ec stuff
19 2015-03-28 05:48:20 <gmaxwell> phantomcircuit: dunno what you mean by "mutation issues", you need to use more precise language.
20 2015-03-28 05:49:07 <gmaxwell> I assume you mean "changes to transactions against the users will." -- a fine thing to mean, and the answer is "if they use the new tx version and ordinary scripts, none that we know of."
21 2015-03-28 05:49:52 <phantomcircuit> gmaxwell, that is what i meant and yeah quite imprecise language
22 2015-03-28 05:50:10 <gmaxwell> I am browbeating you on precision because people seem to think BIP62 will mean that txids won't change on the network (or at least won't change without the user's help), and thats not true, since one can trivially author an intentionally malleable transaction and BIP62 doesnt't change that (and it can't be changed without losing really useful functionality).
23 2015-03-28 05:50:23 <gmaxwell> (I know you know this; but lots of other people do not)
24 2015-03-28 05:51:47 <wumpus> gmaxwell:  I don't see a reason why that could not work; we already keep such a flag, it's just not persistent