1 2017-05-15 05:39:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/87abe20fc118...41987aa92f0d
  2 2017-05-15 05:39:54	0|bitcoin-git|13bitcoin/06master 14b3cbd55 15Jorge Timón: scripted-diff: Util: Encapsulate mapMultiArgs behind gArgs...
  3 2017-05-15 05:39:54	0|bitcoin-git|13bitcoin/06master 14f2957ce 15Jorge Timón: Util: Create ArgsManager class......
  4 2017-05-15 05:39:55	0|bitcoin-git|13bitcoin/06master 145292245 15Jorge Timón: Util: Put mapMultiArgs inside ArgsManager...
  5 2017-05-15 05:40:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9494: Introduce an ArgsManager class encapsulating cs_args, mapArgs  and mapMultiArgs (06master...060.13-args-class) 02https://github.com/bitcoin/bitcoin/pull/9494
  6 2017-05-15 11:07:36	0|Sylvain85|Bonjours
  7 2017-05-15 11:10:02	0|Sylvain85|y a t il quelqu un qui pourait me dire comme faire une solo pool svp
  8 2017-05-15 11:12:56	0|Sylvain85|o
  9 2017-05-15 12:57:53	0|helo_|hello, are you sure all script tests are correct? specifically "["549755813888", "0x06 0xFFFFFFFF7F EQUAL", "P2SH,STRICTENC", "OK"]," in script_tests.json
 10 2017-05-15 13:00:38	0|helo_|previous test: "["549755813887", "0x05 0xFFFFFFFF7F EQUAL", "P2SH,STRICTENC", "OK"],"
 11 2017-05-15 13:14:40	0|wumpus|I'm confused by that one
 12 2017-05-15 13:14:49	0|arubi|it's fine..
 13 2017-05-15 13:15:29	0|arubi|some number base 10 as input, equals to some base16 thing on the script
 14 2017-05-15 13:16:13	0|wumpus|fairly sure it's fine, but I couldn't quite explain why both of them match with different values
 15 2017-05-15 13:16:44	0|arubi|ohh now I see what you mean
 16 2017-05-15 13:17:16	0|arubi|that is weird.  0xFFFFFFFF7F is not 0x06 bytes
 17 2017-05-15 13:17:28	0|helo_|that's my point :)
 18 2017-05-15 13:18:11	0|wumpus|extrapolating from the previous ones you'd expect it to be 0x06 0x000000008000
 19 2017-05-15 13:18:45	0|arubi|that's the correct encoding fwiw
 20 2017-05-15 13:23:06	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10403: Fix importmulti failure to return rescan errors (06master...06pr/scansame) 02https://github.com/bitcoin/bitcoin/pull/10403
 21 2017-05-15 13:27:17	0|wumpus|["549755813888", "0x06 0x000000008000 EQUAL", "P2SH,STRICTENC", "OK"], passes as well
 22 2017-05-15 13:27:29	0|arubi|so is 549755813888 == 0xFFFFFFFF7F87  ..?
 23 2017-05-15 13:42:03	0|arubi|well not "==" I guess, since the equal op /is/ "eaten" by the 0x06, so not sure.  I do get "unknown error" trying to redeem such a script on regtest (some older client)
 24 2017-05-15 13:42:50	0|arubi|probably doing something wrong though
 25 2017-05-15 13:55:02	0|SopaXorzTaker|wait
 26 2017-05-15 13:55:25	0|SopaXorzTaker|why does the PoW process only calculate the hash of the block header?
 27 2017-05-15 13:55:30	0|SopaXorzTaker|why not the whole block?\
 28 2017-05-15 13:55:57	0|SopaXorzTaker|I understand that there's a Merkle root in the header which allows to verify the transactions attached
 29 2017-05-15 13:56:20	0|SopaXorzTaker|but still, hashing the header only makes room for some optimization
 30 2017-05-15 13:56:20	0|wumpus|right, it indirectly verifies the whole block, that's enough
 31 2017-05-15 13:56:27	0|SopaXorzTaker|and PoW has to be hard
 32 2017-05-15 13:56:54	0|wumpus|it already can be made arbitrarily hard by choosing a low target
 33 2017-05-15 13:57:35	0|wumpus|and the hardness shouldn't really depend on the size of the block or number of transactions
 34 2017-05-15 14:18:40	0|paveljanik|jnewbery: I have now finished current master's test_runner two times without "failed" status. One run before, I received 1 failure TypeError: 'NoneType' object is not iterable and one bitcoind remained unkilled. I'm now trying to reach the status of more than one failure and will investigate how many bitcoinds will remained unkilled.
 35 2017-05-15 14:22:28	0|jnewbery|paveljanik: great. I'm planning to tackle the 'NoneType' object is not iterable errors once #10359 and the following PR are merged. Those 'NoneType' object is not iterable errors are to do with the test framework's tracking of the bitcoind processes. Once that state is handled by the TestFramework class it should be easier to work on.
 36 2017-05-15 14:22:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/10359 | [tests] functional tests should call BitcoinTestFramework start/stop node methods by jnewbery · Pull Request #10359 · bitcoin/bitcoin · GitHub
 37 2017-05-15 14:23:11	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10404: Add logging to FinalizeNode() (06master...062017-05-log-finalize-node) 02https://github.com/bitcoin/bitcoin/pull/10404
 38 2017-05-15 14:23:40	0|paveljanik|ok, great!
 39 2017-05-15 14:54:39	0|wumpus|arubi: yes, the OP_EQUAL is eaten
 40 2017-05-15 14:55:31	0|wumpus|so it exits the script with ffffffff7f87 on the stack, and as CLEANSTACK is not checked for that test, it passes
 41 2017-05-15 14:57:03	0|arubi|somehow I thought CLEANSTACK was included in P2SH
 42 2017-05-15 14:57:36	0|arubi|yep, seeing now that it's not
 43 2017-05-15 14:57:52	0|wumpus|I thought so too but it's the other way around
 44 2017-05-15 14:58:26	0|wumpus|for the json scripttests, CLEANSTACK drags in P2SH and WITNESS
 45 2017-05-15 15:02:52	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL (06master...062017_05_scriptnum_test) 02https://github.com/bitcoin/bitcoin/pull/10405
 46 2017-05-15 15:06:35	0|arubi|wumpus, I think it's missing a ',' ?
 47 2017-05-15 15:08:30	0|arubi|unless github screws with the view somehow, line 352 is missing the final comma
 48 2017-05-15 15:10:01	0|wumpus|ah yes thanks, I copy pasted it from an otherwise empty json
 49 2017-05-15 15:20:41	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/41987aa92f0d...96c850c20913
 50 2017-05-15 15:20:42	0|bitcoin-git|13bitcoin/06master 14c99ab3c 15Luke Dashjr: RPC: Allow multiple names for parameters
 51 2017-05-15 15:20:42	0|bitcoin-git|13bitcoin/06master 14e3c9f2d 15Andrew Chow: Use a verbosity instead of two verbose parameters...
 52 2017-05-15 15:20:43	0|bitcoin-git|13bitcoin/06master 1496c850c 15Wladimir J. van der Laan: Merge #8704: [RPC] Transaction details in getblock...
 53 2017-05-15 15:20:51	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #8704: [RPC] Transaction details in getblock (06master...06getblock-extraverbose) 02https://github.com/bitcoin/bitcoin/pull/8704
 54 2017-05-15 18:46:02	0|dermoth|Hey there... I was thinking about the issue of block size vs. propagation time... If I'm not mistaken Bitcoin already sends header only first so miners can start mining quickly on tip, but they cannot validate/include any transaction until they get the full block...
 55 2017-05-15 18:48:08	0|dermoth|What if the block header includes a bloom filter on tx inputs, so miners could at least include any transactions that the bloom filter tells for sure cannot be double spends from the accompanying block header
 56 2017-05-15 18:48:40	0|sipa|look at BIP152
 57 2017-05-15 18:48:54	0|sipa|that's far smaller than a bloom filter is in normal cases
 58 2017-05-15 18:54:09	0|dermoth|Nice... well I was considering a very small bloom filter.... arguably I didn't even check how small it can be without  ending up being 100% false positive
 59 2017-05-15 18:54:28	0|dermoth|especially considering much larger block sizes
 60 2017-05-15 19:02:10	0|dermoth|sipa, I must say I'm not very familiar with bloom filters besides the concept, but according to https://krisives.github.io/bloom-calculator/, with 1M items and 50% error rate all you need is 176k
 61 2017-05-15 19:02:47	0|sipa|bip152 often relays blocks in a few kb
 62 2017-05-15 19:03:13	0|dermoth|well i'm talking an extreme case... how large would be a block with 1M tx ?
 63 2017-05-15 19:03:33	0|sipa|that many transactions don't fit in a block
 64 2017-05-15 19:04:02	0|dermoth|3k tx, 10% error rate is 1.75kb
 65 2017-05-15 19:04:20	0|dermoth|sipa, i'm thinking wayyyy ahead ;)
 66 2017-05-15 19:04:28	0|gmaxwell|dermoth: mining without validation is pretty toxic to scalablity, because it makes it insecure to use lite wallets.
 67 2017-05-15 19:04:32	0|sipa|perhaps this is more for #bitcoin-wizards then
 68 2017-05-15 19:04:44	0|sipa|also, a bloom filter won't let you find conflicts with other transactions
 69 2017-05-15 19:04:55	0|gmaxwell|tiny amounts are probably irrelevant, but larger amounts not so much.
 70 2017-05-15 19:05:15	0|dermoth|that'S why I said iy would have to be based on inputs rather than tx hhashes
 71 2017-05-15 19:05:18	0|gmaxwell|sipa: well you can filter the inputs that were spent, there was a point on bitcoin-dev about this a year ago.
 72 2017-05-15 19:05:43	0|sipa|ah yes
 73 2017-05-15 19:05:50	0|sipa|anyway, seems offtopic for here
 74 2017-05-15 19:06:38	0|gmaxwell|In pratice miners just combine into a bigger pool in any case. Rather than worrying about adding more complexity handling bloom filter messages,
 75 2017-05-15 19:06:54	0|dermoth|I'm just throwing out the idea... if there's a way to make it work it could be a cheap way to allow miners quickly add tx to new blocks while they're syncing up the block data
 76 2017-05-15 19:08:00	0|dermoth|sipa, yes possibly OT - hoe many bitcoin "dev" channels there is?? :)
 77 2017-05-15 19:08:14	0|sipa|well this channel is about the developement of bitcoin core
 78 2017-05-15 19:08:25	0|sipa|not about ideas to radically change the protocol
 79 2017-05-15 19:13:01	0|dermoth|Maybe I could try drafting up a proposal...Actually all there is needed to add is the bloom hash and any variable parameters (ex if implemented with variable size), as the bloom filter can be generated from the block data. But I'm 100% sure how an input can be uniquely identified; i.e. so there would be no room for double spends
 80 2017-05-15 19:13:18	0|gmaxwell|dermoth: this has already been proposed.
 81 2017-05-15 19:13:32	0|gmaxwell|about a year ago.
 82 2017-05-15 19:14:28	0|gmaxwell|and as I said, I don't think there is any interest: it slaughters light client security, so it isn't a public benefit, and when miners are concerned about orphaning they just respond by centeralizing.
 83 2017-05-15 19:16:07	0|dermoth|gmaxwell, I'm not sure we're talking about the same thing... the bloom filter would be only useful to allow miners to quickly start adding transactions to the blocks. I'm thinking of only additional data in the block header to make this possible
 84 2017-05-15 19:16:55	0|sipa|and there is no way to prove that the bloom filter is correct
 85 2017-05-15 19:17:10	0|sipa|and if it isn't, miners may produce invalid blocks
 86 2017-05-15 19:17:33	0|dermoth|probably something like filter size & hash, then clients could choose to receive the header + bloom and start generating block templates that include transaction that the filter guarantees are not double spends
 87 2017-05-15 19:17:42	0|sipa|please, no shower thought ideas here
 88 2017-05-15 19:18:19	0|sipa|this channel is about implementation and development of the bitcoin core software
 89 2017-05-15 19:19:00	0|dermoth|#bitcoin-dev would be more appropriate?
 90 2017-05-15 19:19:09	0|windsok|#bitcoin-wizards
 91 2017-05-15 19:20:17	0|dermoth|thanks
 92 2017-05-15 19:22:33	0|gmaxwell|dermoth: What was propsoed was creating a bloom filter of the txins spent by a block so that miners could do even more mining without validating and not miss out on collecting (most of the) fees.
 93 2017-05-15 19:23:01	0|sipa|gmaxwell: please, not here
 94 2017-05-15 20:52:42	0|bitcoin-git|13bitcoin/06master 143ba2c08 15John Newbery: [tests] fix disconnect_ban intermittency
 95 2017-05-15 20:52:42	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/96c850c20913...8bd16ee12fc8
 96 2017-05-15 20:52:43	0|bitcoin-git|13bitcoin/06master 148bd16ee 15MarcoFalke: Merge #10376: [tests] fix disconnect_ban intermittency...
 97 2017-05-15 20:53:14	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10376: [tests] fix disconnect_ban intermittency (06master...06disconnect_ban_flakiness) 02https://github.com/bitcoin/bitcoin/pull/10376
 98 2017-05-15 21:58:34	0|bitcoin-git|[13bitcoin] 15metacoin opened pull request #10407: Trivial: fixed spelling, "Bitcion" -> "Bitcoin" (06master...06metacoin-fix-translation-spelling) 02https://github.com/bitcoin/bitcoin/pull/10407
 99 2017-05-15 22:40:27	0|bitcoin-git|13bitcoin/06master 144f3782e 15Simone Madeo: [doc] Removing comments about dirty entries on txmempool
100 2017-05-15 22:40:27	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8bd16ee12fc8...b6ee855b411e
101 2017-05-15 22:40:28	0|bitcoin-git|13bitcoin/06master 14b6ee855 15Pieter Wuille: Merge #10380: [doc] Removing comments about dirty entries on txmempool...
102 2017-05-15 22:40:59	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10380: [doc] Removing comments about dirty entries on txmempool (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10380
103 2017-05-15 23:08:03	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10407: Trivial: fixed spelling, "Bitcion" -> "Bitcoin" (06master...06metacoin-fix-translation-spelling) 02https://github.com/bitcoin/bitcoin/pull/10407