< 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
< 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.
< 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
< 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.