1 2015-11-20 00:00:29 <Luke-Jr> sipa: do blocks actually /need/ to commit to the witnesses? isn't the worst-case scenario there that we lack information to verify the block?
  2 2015-11-20 00:02:35 <Luke-Jr> I suppose it would be a DoS vector since there's no way to cache the validation result per DMMS
  3 2015-11-20 00:03:01 <sipa> it also means you wouldn't be able to mark a block as invalid, ever
  4 2015-11-20 00:03:10 <sipa> someone could just have modified the witness en route
  5 2015-11-20 00:03:28 <gmaxwell> the commitment is needed for several reasons: preventing dos, accountability (foresenics),  and also it's necessary for fraud proofs to work.
  6 2015-11-20 00:03:53 <Luke-Jr> last I knew, fraud proofs simply *don't* work..
  7 2015-11-20 00:04:42 <sipa> with a tiny bit of extra data in the witnesses, we can make them work :)
  8 2015-11-20 00:05:25 <Luke-Jr> sipa: how do we avoid the data-withholding problem?
  9 2015-11-20 00:05:51 <sipa> Luke-Jr: same way we do now: we don't
 10 2015-11-20 00:06:22 <Luke-Jr> … so how does it make fraud proofs work, if that problem is still unsolved?
 11 2015-11-20 00:06:22 <sipa> we can treat missing witness identical to merkle tree mismatch
 12 2015-11-20 00:06:59 <sipa> i don't understand
 13 2015-11-20 00:07:30 <Luke-Jr> sipa: when I make a block, I replace an irrelevant merkle branch with a dummy hash-looking data that isn't actually a hash of anything.
 14 2015-11-20 00:07:43 <Luke-Jr> now I can provide merkle proofs for transactions in that "block", but you cannot prove the block is ivnalid
 15 2015-11-20 00:07:56 <Luke-Jr> because you don't have the data to build the complete merkle tree
 16 2015-11-20 00:08:20 <Luke-Jr> (in this case, that data doesn't exist and nobody can have it)
 17 2015-11-20 00:09:01 <sipa> ugh
 18 2015-11-20 00:10:05 <sipa> right, the merkle tree branch used must be unique
 19 2015-11-20 00:10:27 <sipa> or at least must be known without seeing the witness data
 20 2015-11-20 00:10:44 <sipa> otherwise you can have multiple versions of a block's witness
 21 2015-11-20 00:10:50 <Luke-Jr> sipa: I'm not even talking about the commitment here.. this is a problem right now that affects the usual tx merkle tree.
 22 2015-11-20 00:15:14 <sipa> Luke-Jr: right, you still need to see the full blocks
 23 2015-11-20 00:19:04 <gmaxwell> Luke-Jr: fraud proofs are not a replacement for validation.
 24 2015-11-20 00:19:37 <gmaxwell> They allow an intermediate security model between no-verification and full verification; which adds an additional strong assumption that you are not partitioned from an honest node with the full data.
 25 2015-11-20 00:20:09 <gmaxwell> The thing we can't make work for fundimental censorship reasons is fraud proofs as a total replacement for verification.
 26 2015-11-20 00:42:12 <nickler> j
 27 2015-11-20 00:46:51 <sipa> k
 28 2015-11-20 00:59:03 <midnightmagic> l
 29 2015-11-20 01:07:39 <norman> Greetings!. I am getting "ERROR: Failed to connect to localhost port 18332: Connection timed out"
 30 2015-11-20 01:08:33 <norman> on testnet using PHP and easybitcoin.php library  $bitcoin = new Bitcoin($username,$password,$host,$port)
 31 2015-11-20 01:08:50 <norman> im running testnet
 32 2015-11-20 01:08:58 <norman> anyone have any ideas?
 33 2015-11-20 01:09:13 <norman> is this a good place to ask for this help?
 34 2015-11-20 01:13:57 <graingert> m
 35 2015-11-20 01:16:22 <norman> just trying to connect to testnet via the easybitcoin.php library and display getinfo and status and play with sending test bitcoins. im running testnet on ubuntu
 36 2015-11-20 01:18:14 <instagibbs> norman, you can try #bitcoin as well
 37 2015-11-20 01:20:36 <norman> host is localhost and port is 18332
 38 2015-11-20 01:21:50 <norman> would you know how I would connect to another channel ?
 39 2015-11-20 01:21:58 <norman> :-)
 40 2015-11-20 01:22:26 <norman> figured it out!! :-)
 41 2015-11-20 01:22:34 <norman> how to create another channel that is
 42 2015-11-20 01:25:49 <sipa> /join #bitcoin
 43 2015-11-20 01:25:51 <sipa> type that
 44 2015-11-20 01:25:57 <sipa> right here
 45 2015-11-20 01:39:28 <norman> SIPA: thanks, I figured it out. I posted also on #bitcoin, waiting for response.
 46 2015-11-20 02:02:03 <Naroh> y
 47 2015-11-20 03:54:00 <norman> I figured out my port connection issue on testnet btw, so im good there
 48 2015-11-20 03:54:42 <norman> i had port as a number and it object was expecting a string :-)
 49 2015-11-20 17:03:30 <btcdrak> ping jtimon
 50 2015-11-20 17:04:03 <btcdrak> ping jtimon_
 51 2015-11-20 17:21:49 <jtimon_> btcdrak: pong
 52 2015-11-20 17:22:17 <btcdrak> yeah I wanted to talk about your suggested commit for #6312
 53 2015-11-20 17:22:50 <btcdrak> jtimon_: I believe this is the one? https://github.com/jtimon/bitcoin/commit/071bc1cf615c0528d4f7e2fe33dc80186da447d3
 54 2015-11-20 17:22:56 <jtimon_> sure
 55 2015-11-20 17:23:44 <jtimon_> yep, I believe that should be squashed into sipa's commit
 56 2015-11-20 17:24:43 <jtimon_> the total diff count of sipa's commit will remain the same
 57 2015-11-20 17:24:45 <sipa> do we _really_ care about avoid 3 & symbols in the code, and making it less obvious?
 58 2015-11-20 17:25:12 <jtimon_> we don't need pointers inside
 59 2015-11-20 17:25:39 <jtimon_> reference is more clear if possible (ie always) IMO
 60 2015-11-20 17:25:47 <sipa> god
 61 2015-11-20 17:25:56 <sipa> it's an argument that can be empty
 62 2015-11-20 17:26:12 <sipa> why do you want to turn it into a reference?
 63 2015-11-20 17:26:37 <jtimon_> so that I don't have to think about null pointers in consensus code
 64 2015-11-20 17:26:52 <sipa> you should think about
 65 2015-11-20 17:26:53 <sipa> it
 66 2015-11-20 17:27:01 <sipa> because it's an argument that can be avoided
 67 2015-11-20 17:27:11 <sipa> it has different behaviour with and without
 68 2015-11-20 17:27:41 <jtimon_> does my commit change behaviour?
 69 2015-11-20 17:27:41 <sipa> anyway, not worth spending more time on - it's a waste of time
 70 2015-11-20 17:28:02 <sipa> no, and it makes it less clear imho, and we're wasting our time discussing unimportant things
 71 2015-11-20 17:28:05 <sipa> so, i don't care
 72 2015-11-20 17:28:16 <jtimon_> sure it's just a nit to the nit of the nit
 73 2015-11-20 17:28:21 <btcdrak> ok I think I have my answer. I'm not going to merge it.
 74 2015-11-20 17:29:28 <jtimon_> but I humbly disagree with you in it making it less clear, sipa, now where using . outside and -> inside for no good reason
 75 2015-11-20 17:29:55 <jtimon_> s/where/we're
 76 2015-11-20 17:30:46 <sipa> jtimon_: which makes it clear that the argument is a pointer, and thus can be NULL; and that's something that someone reading the code should notice
 77 2015-11-20 17:30:57 <sipa> because there is different behaviour with and without
 78 2015-11-20 17:31:00 <jtimon_> whatever
 79 2015-11-20 17:31:19 <sipa> why is -> worse than .?
 80 2015-11-20 17:31:45 <jtimon_> if we used -> outside too maybe I wouldn't had complained
 81 2015-11-20 17:32:13 <sipa> anyway, it's a nit; no point discussing it further; you like one more, i like the other more
 82 2015-11-20 17:32:24 <jtimon_> it's the unnecessary divergence what I don't like, but anyway, we agree this is not important
 83 2015-11-20 17:34:41 <jtimon_> I just dislike having to duplicate if (whatever == NULL) return state.invalid(...) everywhere in consensus code, if they're references the compiler will check they are not null for me
 84 2015-11-20 17:35:08 <jtimon_> if I want to signal a special case I can always use a bool or an enum
 85 2015-11-20 17:35:16 <sipa> the compiler does not check that for you
 86 2015-11-20 17:35:23 <sipa> it's just undefined behaviour
 87 2015-11-20 17:36:23 <jtimon_> well, I just don't expect many people to call functions with *NULL as parameter (doesn't the compiler catch that if done inline?)
 88 2015-11-20 17:36:36 <sipa> maybe it does
 89 2015-11-20 17:36:56 <sipa> i understand what you're saying: you don't like using a pointer to indicate an optional value?
 90 2015-11-20 17:37:27 <sipa> but i don't think that special casing an empty vector is any better as a means to indicate that
 91 2015-11-20 17:37:47 <jtimon_> yes, I don't like using thisparam == NULL to indicate special cases, thisparam is either necessary or not
 92 2015-11-20 17:38:14 <sipa> i like using thisparam.size() == 0 even less :)
 93 2015-11-20 17:38:42 <jtimon_> I don't specially like .size() == 0 either, as said I would prefer a boolean, but that was the less disrupting thing I could do
 94 2015-11-20 17:39:31 <jtimon_> I think what I dislike more is assert(prevHeights == NULL || prevHeights->size() == tx.vin.size());
 95 2015-11-20 17:40:06 <sipa> ok
 96 2015-11-20 17:40:13 <sipa> let me respectfully disagree
 97 2015-11-20 17:40:39 <jtimon_> sure, you said it wasn't possible in that commit and I had to code it
 98 2015-11-20 17:42:23 <jtimon_> when people tell me there's something impossible that I  know I can do relatively fast I don't know what happens...
 99 2015-11-20 17:47:24 <btcdrak> Regarding the meeting yesterday, BIP68 bip text has been updated with the current working implementation and also text has been extensively clarified as people generally seemed to have difficulty with the presentation. I made some more updates/polishing since this morning if anyone looked earlier: https://github.com/bitcoin/bips/pull/245
100 2015-11-20 19:22:13 <BW^-> how outdated is  v0.9.1?
101 2015-11-20 19:22:20 <BW^-> could you use it for anything?