< bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/87abe20fc118...41987aa92f0d
< bitcoin-git> bitcoin/master f2957ce Jorge Timón: Util: Create ArgsManager class......
< bitcoin-git> bitcoin/master b3cbd55 Jorge Timón: scripted-diff: Util: Encapsulate mapMultiArgs behind gArgs...
< bitcoin-git> bitcoin/master 5292245 Jorge Timón: Util: Put mapMultiArgs inside ArgsManager...
< bitcoin-git> [bitcoin] laanwj closed pull request #9494: Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs (master...0.13-args-class) https://github.com/bitcoin/bitcoin/pull/9494
< Sylvain85> Bonjours
< Sylvain85> y a t il quelqu un qui pourait me dire comme faire une solo pool svp
< Sylvain85> o
< helo_> hello, are you sure all script tests are correct? specifically "["549755813888", "0x06 0xFFFFFFFF7F EQUAL", "P2SH,STRICTENC", "OK"]," in script_tests.json
< helo_> previous test: "["549755813887", "0x05 0xFFFFFFFF7F EQUAL", "P2SH,STRICTENC", "OK"],"
< wumpus> I'm confused by that one
< arubi> it's fine..
< arubi> some number base 10 as input, equals to some base16 thing on the script
< wumpus> fairly sure it's fine, but I couldn't quite explain why both of them match with different values
< arubi> ohh now I see what you mean
< arubi> that is weird. 0xFFFFFFFF7F is not 0x06 bytes
< helo_> that's my point :)
< wumpus> extrapolating from the previous ones you'd expect it to be 0x06 0x000000008000
< arubi> that's the correct encoding fwiw
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10403: Fix importmulti failure to return rescan errors (master...pr/scansame) https://github.com/bitcoin/bitcoin/pull/10403
< wumpus> ["549755813888", "0x06 0x000000008000 EQUAL", "P2SH,STRICTENC", "OK"], passes as well
< arubi> so is 549755813888 == 0xFFFFFFFF7F87 ..?
< 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)
< arubi> probably doing something wrong though
< SopaXorzTaker> wait
< SopaXorzTaker> why does the PoW process only calculate the hash of the block header?
< SopaXorzTaker> why not the whole block?\
< SopaXorzTaker> I understand that there's a Merkle root in the header which allows to verify the transactions attached
< SopaXorzTaker> but still, hashing the header only makes room for some optimization
< wumpus> right, it indirectly verifies the whole block, that's enough
< SopaXorzTaker> and PoW has to be hard
< wumpus> it already can be made arbitrarily hard by choosing a low target
< wumpus> and the hardness shouldn't really depend on the size of the block or number of transactions
< 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.
< 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.
< 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
< bitcoin-git> [bitcoin] sdaftuar opened pull request #10404: Add logging to FinalizeNode() (master...2017-05-log-finalize-node) https://github.com/bitcoin/bitcoin/pull/10404
< paveljanik> ok, great!
< wumpus> arubi: yes, the OP_EQUAL is eaten
< wumpus> so it exits the script with ffffffff7f87 on the stack, and as CLEANSTACK is not checked for that test, it passes
< arubi> somehow I thought CLEANSTACK was included in P2SH
< arubi> yep, seeing now that it's not
< wumpus> I thought so too but it's the other way around
< wumpus> for the json scripttests, CLEANSTACK drags in P2SH and WITNESS
< bitcoin-git> [bitcoin] laanwj opened pull request #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL (master...2017_05_scriptnum_test) https://github.com/bitcoin/bitcoin/pull/10405
< arubi> wumpus, I think it's missing a ',' ?
< arubi> unless github screws with the view somehow, line 352 is missing the final comma
< wumpus> ah yes thanks, I copy pasted it from an otherwise empty json
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/41987aa92f0d...96c850c20913
< bitcoin-git> bitcoin/master c99ab3c Luke Dashjr: RPC: Allow multiple names for parameters
< bitcoin-git> bitcoin/master e3c9f2d Andrew Chow: Use a verbosity instead of two verbose parameters...
< bitcoin-git> bitcoin/master 96c850c Wladimir J. van der Laan: Merge #8704: [RPC] Transaction details in getblock...
< bitcoin-git> [bitcoin] laanwj closed pull request #8704: [RPC] Transaction details in getblock (master...getblock-extraverbose) https://github.com/bitcoin/bitcoin/pull/8704
< 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...
< 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
< sipa> look at BIP152
< sipa> that's far smaller than a bloom filter is in normal cases
< 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
< dermoth> especially considering much larger block sizes
< 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
< sipa> bip152 often relays blocks in a few kb
< dermoth> well i'm talking an extreme case... how large would be a block with 1M tx ?
< sipa> that many transactions don't fit in a block
< dermoth> 3k tx, 10% error rate is 1.75kb
< dermoth> sipa, i'm thinking wayyyy ahead ;)
< gmaxwell> dermoth: mining without validation is pretty toxic to scalablity, because it makes it insecure to use lite wallets.
< sipa> perhaps this is more for #bitcoin-wizards then
< sipa> also, a bloom filter won't let you find conflicts with other transactions
< gmaxwell> tiny amounts are probably irrelevant, but larger amounts not so much.
< dermoth> that'S why I said iy would have to be based on inputs rather than tx hhashes
< gmaxwell> sipa: well you can filter the inputs that were spent, there was a point on bitcoin-dev about this a year ago.
< sipa> ah yes
< sipa> anyway, seems offtopic for here
< gmaxwell> In pratice miners just combine into a bigger pool in any case. Rather than worrying about adding more complexity handling bloom filter messages,
< 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
< dermoth> sipa, yes possibly OT - hoe many bitcoin "dev" channels there is?? :)
< sipa> well this channel is about the developement of bitcoin core
< sipa> not about ideas to radically change the protocol
< 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
< gmaxwell> dermoth: this has already been proposed.
< gmaxwell> about a year ago.
< 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.
< 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
< sipa> and there is no way to prove that the bloom filter is correct
< sipa> and if it isn't, miners may produce invalid blocks
< 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
< sipa> please, no shower thought ideas here
< sipa> this channel is about implementation and development of the bitcoin core software
< dermoth> #bitcoin-dev would be more appropriate?
< windsok> #bitcoin-wizards
< dermoth> thanks
< 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.
< sipa> gmaxwell: please, not here
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/96c850c20913...8bd16ee12fc8
< bitcoin-git> bitcoin/master 3ba2c08 John Newbery: [tests] fix disconnect_ban intermittency
< bitcoin-git> bitcoin/master 8bd16ee MarcoFalke: Merge #10376: [tests] fix disconnect_ban intermittency...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10376: [tests] fix disconnect_ban intermittency (master...disconnect_ban_flakiness) https://github.com/bitcoin/bitcoin/pull/10376
< bitcoin-git> [bitcoin] metacoin opened pull request #10407: Trivial: fixed spelling, "Bitcion" -> "Bitcoin" (master...metacoin-fix-translation-spelling) https://github.com/bitcoin/bitcoin/pull/10407
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bd16ee12fc8...b6ee855b411e
< bitcoin-git> bitcoin/master 4f3782e Simone Madeo: [doc] Removing comments about dirty entries on txmempool
< bitcoin-git> bitcoin/master b6ee855 Pieter Wuille: Merge #10380: [doc] Removing comments about dirty entries on txmempool...
< bitcoin-git> [bitcoin] sipa closed pull request #10380: [doc] Removing comments about dirty entries on txmempool (master...master) https://github.com/bitcoin/bitcoin/pull/10380
< bitcoin-git> [bitcoin] fanquake closed pull request #10407: Trivial: fixed spelling, "Bitcion" -> "Bitcoin" (master...metacoin-fix-translation-spelling) https://github.com/bitcoin/bitcoin/pull/10407