< gmaxwell>
Good news: for a dbcache of size 2000, sipa's "per utxo" cache model is now 22.6% faster than master in a signature validation free chainstate reindex! (benchmarking with a cache size of 300 now, will report back in a few hours)
< kallle>
According to the bitcoin.it wiki, "CompactSize" is a var int, and CVarInt is an "even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here)". But it's described in all documentation there and elsewhere as a "varint". So the varint is the compact size and the CVarInt/VARINT refer to something else. Doesn't that cause confusion?
< sipa>
the CVarInt in serialize.h is a bitcoin core internal thing, only used for the utxo database and undo data
< sipa>
and it doesn't appear anywhere in the p2p protocol
< sipa>
CompactSize is the varint type used in the p2p protocol for vector sizes etc
< sipa>
and yes, it's confusing...
< sipa>
historical reasons :)
< kallle>
Seems like a candidate for renaming but I can see how it would cause issues as people have used the two as they are for years... esp if COMPACTSIZE becomes VARINT.
< Chris_Stewart_5>
What is the criteria for setting the default dbcache value? Does a BIP have to be proposed to change it?
< sipa>
no
< sipa>
it doesn't affect the network in any way
< sipa>
only your own memory/cpu tradeoff
< Chris_Stewart_5>
What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)
< Chris_Stewart_5>
I know blocksize/dbcache aren't really related, but I think I was thinking about that as policy for some defaults in bitcoin core.
< sipa>
sure, but it doesn't need any consideration ahead of time
< sipa>
we can just occasionally change defaults to keep up with technology trends
< sipa>
i think bitcoin-qt for example should just detect how much memory you have at startup, and based on that, choose something and let the user customize
< sipa>
it's harder to do that in bitcoind, which we exapct to run on low-power devices too
< Chris_Stewart_5>
I guess it seems like it could break out into a very politicized change, which is why I think the BIP process would be needed -- but I understand what you mean by it doesn't affect consensus
< gmaxwell>
Chris_Stewart_5: that would be like having a BIP for the color of your theme... it's a purely local thing .. it doesn't matter to you what anyone else uses.
< gmaxwell>
It isn't something where "interoperability" is required.
< sipa>
BIP42 suggests that the currency symbol color should be considered
< Chris_Stewart_5>
sipa: That is interesting. I kind of like that idea wrt to reading mem and just setting it off of that.
< sipa>
what idea?
< Chris_Stewart_5>
your comment wrt to bitcoin-qt
< sipa>
Chris_Stewart_5: not only does not affect consensus - it doesn't affect anything
< sipa>
BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
< gmaxwell>
Chris_Stewart_5: it would be a wrong assumption to assume the user wants all their memory used by bitcoin. :(
< Chris_Stewart_5>
gmaxwell: absurd! :P
< gmaxwell>
we could certantly reduce it based on the amount of free memory!
< Chris_Stewart_5>
ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #9359: Fix CWalletTx::GetImmatureCredit() returning stale values. (master...pr/immature) https://github.com/bitcoin/bitcoin/pull/9359
< Chris_Stewart_5>
sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
< gmaxwell>
I currently have a node running 8695, 8808, 9039, 9045, 9125, 9138, and 9199 ... surprisingly all applied without conflict.
< NicolasDorier>
When I do "fundrawtransaction" followed by a "getnewaddress" I noticed the generated address and the change of funrawtransaction are the same
< NicolasDorier>
is it on purpose ?
< NicolasDorier>
it is like funrawtransaction does not increment the index for generating the next address
< NicolasDorier>
I can do a getnewaddress manually after FundRawTransaction, but first I would like if it is on purpose
< bitcoin-git>
[bitcoin] kallewoof opened pull request #9361: Fix: OSX compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
< jonasschnelli>
NicolasDorier: thats right. Fundrawtransaction does not keep the reserve key.
< NicolasDorier>
what about adding a new parameter to fundrawtransaction for it to be the case ? I don't want same key used twice by mistake
< jonasschnelli>
NicolasDorier: what you can and should do is call getrawchangeaddress and use this with fundrawtransaction (you can specify a change address there)
< NicolasDorier>
ah
< NicolasDorier>
yes
< NicolasDorier>
will do that thanks
< jonasschnelli>
NicolasDorier: yes. We should do that-.
< jonasschnelli>
It feels llike a serious bug
< jonasschnelli>
I'm opening an issue
< NicolasDorier>
thanks
< bitcoin-git>
[bitcoin] rebroad opened pull request #9363: Don't provide blocktxns for old blocks on a fork. (master...MinChainWorkBlocktxns) https://github.com/bitcoin/bitcoin/pull/9363
< gmaxwell>
rebroad: you know you can run all the tests that travis runs locally?
< rebroad>
gmaxwell, I assumed it was possible, although I have not yet worked out how to make it do so... I chose the --enable-extended-rpc-tests on the configure, but then couldn't work out what to do following that.
< rebroad>
and anyway, "make check" is failing on my system... I raised an issue for it.
< rebroad>
gmaxwell, what prompted you to mention the travis tests?
< rebroad>
(well, 9 times out of 10 - re "make check")
< gmaxwell>
rebroad: number of failing test on PR opens from you suggested to me that you weren't aware you could run them locally. (e.g. I follow the link when the bot mentions it in IRC and its failed already).
< rebroad>
gmaxwell, how do I run them locally please? (I am re-reading the docs now, but have not seen this info as yet)
< rebroad>
and that failed only on 1 of the 6 platforms
< rebroad>
I'm assuming if I run the tests locally it only tests my own platform
< gmaxwell>
RE your latest PR, the same behavior exists for blocks it is pointless to be much more restrictive there for getblocktxn than blocks themselves. Also, we don't want to fail to reply to a getblocktxn we might have just offered by sending a compact block and then immediately having a reorg, as that will dos attack our peer. For the code that avoids fingeringprinting with blocks search for "To pre
< gmaxwell>
vent fingerprinting" in net_processing.cpp.
< rebroad>
gmaxwell, "same behavior exists for blocks" - same behavior as what? For blocks it checks if it is more than 1 month old - quite different logic than is used for getblocktxns
< rebroad>
it also checks if it is in the activechain - it doesn't do this for getblocktxns
< gmaxwell>
rebroad: well you may not be able to test osx locally, though you could test windows if you wanted. You can actually see exactly what travis runs by looking in the file .travis.yml but the relevant command is qa/pull-tester/tpc-tests.py
< rebroad>
for getblocktxns (from what I can tell) it checks if the height it within a certain height - a height comparison
< rebroad>
gmaxwell, thanks (re rpc-tests.py) runnnig it now.. somewhat obscure command which I would not have tried unless told
< gmaxwell>
rebroad: yes but there is no point for the purpose of avoiding fingerprinting in making the test there _more_ restrictive than the one for blocks.
< wumpus>
(this is all linked from the main README.md, you should have no problem finding this documentation if you bothered looking even casually)
< wumpus>
I'm disappointed that you're constantly submitting issues and even pull request while you apparently don't even know how to run the tests
< rebroad>
wumpus, I see the section now - yes, it is there - not sure how I missed it last time
< rebroad>
I don't know when that info was added but it wasn't in there when I last read it - I'm not sure how often I am expected to re-read the README file
< jonasschnelli>
Also, rebroad: you can setup travis for your own development branch
< jonasschnelli>
(in case you open PRs to have them run though travis)
< wumpus>
it was there for a long time, has been updated a few times
< rebroad>
jonasschnelli, that would be very useful indeed. thanks
< wumpus>
and yes you're supposed to keep up to date with the (extrememly minimal) development documentation if you do development
< jonasschnelli>
and enable you rebroad/bitcoin repo
< rebroad>
jonasschnelli, it appears I enabled travis for my rebroad/bitcoin more than 9 months ago. I have just revisited it now, but so far am struggling to understand the interface
< jonasschnelli>
understand travises interface?
< wumpus>
travis, too, has documentation
< wumpus>
it looks like the fundrawtransaction.py test is flaky at the moment
< rebroad>
running the extended tests locally fundrawtransaction.py passed, but walletbackup.py failed!
< rebroad>
my one line change doesn't touch things that either of those tests test
< wumpus>
jonasschnelli: interesting - it's supposed to update the change address when it is actually used
< wumpus>
jonasschnelli: apparently that logic doesn't work
< rebroad>
gmaxwell, I am struggling to understand the context of what you are referring to. you mention a "more restrictive test" - but I am not sure which test you mean. The test was previously checking that the height was within 10 blocks from active-tip - it is still that test, but no longer assumes only one chain.
< rebroad>
gmaxwell, by making that assumption it would respond to requests for any block of that height, whether on the active chain or not
< rebroad>
(at least, this is my understanding from the code)
< rebroad>
given the reason for the restriction was to avoid delving into old data and hard-disk read access, then the new check seems a better way, and doesn't apply any additional restrictions over the previous check (other than disallowing other chains where the work would have been much lower - therefore not a problem disabling this from what I can see)
< rebroad>
if it is intentional to allow access to old blocks on alt chains, but not on the active chain, then I am at a loss why this would be intentional
< rebroad>
my understanding is that as compact blocks relys on the memory pool, that old blocks on any chain are unnecessary
< wumpus>
yes this is intentional, it avoids fingerprinting attacks
< rebroad>
wumpus, it would allow fingerprint attacks, not avoid them
< wumpus>
peers could fingerprint nodes based on what alt-chains they own - this is avoided now
< rebroad>
wumpus, which PR are you referring to?
< rebroad>
wumpus, my PR is a change that avoids fingerprinting. the current master allows it
< wumpus>
I'm not refering to a PR, but to the reason that access is not allowed to old blocks on alt chains
< rebroad>
wumpus, my PR stops access to old blocks on alt chains
< rebroad>
in order to stop fingerprinting
< wumpus>
anyhow I can't reproduce the fundrawtransaction problem locally either
< rebroad>
in order for the fingerprinting to happen, a peer would need to be fed blocks on an alt chain until height within 10 from the current active tip
< rebroad>
then once that is done, a getblocktxn request would reveal the fingerprint
< rebroad>
I have not tested this can be done, but from reading the code I believe it could
< rebroad>
i would like to be able to write a test to show this - i need to become more familiar with the python tests to be able to do this. apologies if I am wrong about my assumption based on reading the code
< rebroad>
and to be honest, I am not even sure what the big deal about fingerprinting is, but given it is coded to be protected against, I assumed this vector ought to be closed also
< wumpus>
I don't understand why you write and submit a patch to do something that you don't even know it's a big deal?
< wumpus>
why are you working on that at all, then?
< rebroad>
I don't claim to know anything as Aristotle once said
< rebroad>
I can go only on assumptions therefore
< wumpus>
I just don't understand your motivation
< rebroad>
wumpus, to help. what is your motivation?
< wumpus>
either you believe fingerprint attacks are a serious attack vector and you try to improve mitigation of them, or you don't just leave the logic alone
< wumpus>
for which change?
< rebroad>
wumpus, for the project i mean
< wumpus>
that's off topic here and certainly not something I want to get into
< rebroad>
sorry, I answered assuming you were referring to the project, not the PR
< wumpus>
the only thing relevant here is the motivation to make specific changes to the code, as you need that to convince other people to care about your change
< rebroad>
wumpus, I assume that given anti-fingerprinting code is already in the code, then a sufficient number of core developers appreciate its importance. I didn't consider that I therefore needed to appreciate it also
< rebroad>
I mean understand not appreciate
< rebroad>
anyway, if I was wrong, and it's not important. I will close the PR
< rebroad>
but it does make me question why it was important for blocks but not blocktxns
< wumpus>
well your described angle is fine if you care about it: write a test that demonstrates it, then demonstrate that your code fixes that attack
< rebroad>
wumpus, ok, I will get to work on that.. but before I do.. can anyone explain to me why fingerprinting attacks are bad?
< wumpus>
if you don't, then don't waste your time
< rebroad>
wumpus, because if they are not that bad, then it's a lot of effort for something trivial
< wumpus>
if you don't think they are bad then donj't spend effort on it!
< rebroad>
wumpus, lol.. ok
< wumpus>
why do you need to be hand-held through every little thing
< rebroad>
wumpus, it takes two to hold hands
< wumpus>
fingerprinting has to do with privacy, especially over tor or other anonymity layers. Theoretically you should not be able to identify a peer connecting to you over tor, but with fingerprinting tricks you can.
< rebroad>
wumpus, I mean that we both needed to understand each other to work out the way forward
< rebroad>
wumpus, ah... thanks. i understand now in that context. thank you for explaining
< wumpus>
if you can distinguish and thus identify peers sending you a transaction you gain information you shouldn't have
< wumpus>
if you don't care about that, then well, don't
< rebroad>
wumpus, based on that explanation, I shall work on creating that test you asked for
< wumpus>
okay thanks
< wumpus>
so fundrawtransaction.py test very regularly fails on travis with "Assertion failed: Mempool sync failed"
< wumpus>
but I can't reproduce this locally
< luke-jr>
timing maybe?
< wumpus>
some recent change must have triggered it, it was not the case before
< jonasschnelli>
wumpus: fundrawtx should not keep the CReserveKey, sendrawtx could, but what solutions do we offer for users broadcastign over different channels...
< jonasschnelli>
Maybe we should add a call
< jonasschnelli>
to reserve the used change key of a funded raw tx
< jonasschnelli>
or to reserve a key by a specific address
< jonasschnelli>
(and release)
< wumpus>
jonasschnelli: well for broadcasting over separate channels we can't offer automatic change address functionality
< wumpus>
jonasschnelli: unless there would be a way to tell the wallet of a transaction without broadcasting it
< jonasschnelli>
ah,.. right.
< wumpus>
right now the only way to tell the wallet is sendrawtransaction, which always broadcasts (walletbroadcast=0 setting won't help you there)
< jonasschnelli>
I guess we should add detecting the change key in sendrawtx and make sure we reserve it from the keypool
< wumpus>
either that or indeed it should be an explicit step to reserve a change address, which should be returned if not used
< wumpus>
this was overlooked in the fundrawtransaction design
< wumpus>
fundrawtransaction doesn't even consistently fail in the same place (!)
< wumpus>
if travis will consistently pass with that reverted, I'm going to revert it on master too
< wumpus>
in the mean time I've still managed to reproduce it locally 0 times - what makes this so special that it only happens on travis, I wonder
< wumpus>
btw can anyone else get results from seed.bitcoin.sipa.be? it's been giving me nothing for something like two weeks now
< wumpus>
but I've heard no one else compain about it
< jonasschnelli>
wumpus: we have a bug in the seeder somewhere...
< jonasschnelli>
I couldn't track it down.
< jonasschnelli>
Seems to be introduced with the filtering option
< wumpus>
jonasschnelli: okay - yes your testnet seed fails too
< jonasschnelli>
Must be something with the cache... seeder is running but not results empty responses.
< jonasschnelli>
(need to attach the debugger)
< jonasschnelli>
But my long term plan is, to split the seeder in a crawler and a server
< jonasschnelli>
As server, I'd like to use djbdns
< jonasschnelli>
Shouldn't be that hard.
< wumpus>
so it never returns results, or starts returning nothing after a while?
< wumpus>
gah my dummy commit passed travis. Stupid heODODisenbug :)
< wumpus>
heisenbug*
< btcdrak>
wumpus: I also get no results from the seed, and I have complained about it on occasion
< MarcoFalke>
wumpus: It should fail at most 25% of the time
< rebroad_>
wumpus, my plan is to adapt the fingerprint test that (I presume) is already written to test that blocks cannot be fingerprinted - would you know which test file does that please? Is there a test already written to test fingerprint attacks at all?
< wumpus>
btcdrak: okay, hadn't noticed then
< wumpus>
MarcoFalke: that seems true on travis - but I'm running it locally in a loop, has run ~100 times or so, no failures
< wumpus>
in any case #9365 seems to be consistently passing with #9313 reverted
< rebroad_>
MarcoFalke, I already checked that file - it seems to be a test for compact blocks - I was asking about the test that tests that old alt-chain full-blocks cannot be requested... this would be the closest to the test I want to create
< rebroad_>
MarcoFalke, thanks though
< rebroad_>
these python tests are new territory for me.. so a bit of a learning curve..
< rebroad_>
my goodness the pruning test seems to take a while to run...
< bitcoin-git>
[bitcoin] kallewoof opened pull request #9366: Fix: OSX QT compile: use built-in swap if available, or defer (master...macosx-qt-build-fix2) https://github.com/bitcoin/bitcoin/pull/9366
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
< morcos>
MarcoFalke: thanks... i just got a chance to sit down and look and i'd forgotten how fundrawtransaction sets exactly min_relay_tx_fee, but i think the way you fixed it makes the most sense.
< phantomcircuit>
wumpus, can you tell me about commit e8ef3da7 ?
< phantomcircuit>
it's from 2011 so im not expecting much
< phantomcircuit>
commit message is just "update core to d0d80170a2ca73004e08fb85007fe055cbf4e411 (CWallet class)"
< phantomcircuit>
nvm i see i should actually be asking sipa maybe?
< phantomcircuit>
nvm i see i should be asking s_nakamoto
< instagibbs>
this is a bit #bitcoin but rebroad, you only need a segwit wallet to spend segwit outputs that you receive... but by definition you won't ask for them and receive legacy payments
< rebroad>
instagibbs, ah. yes, makes sense. thanks.
< rebroad>
gmaxwell, did zander change his article or did you misquote it? the sentence "So if a person doesn't upgrade they will eventually not be able to accept money from anyone." does not appear to be in the URL you posted on here
< bitcoin-git>
[bitcoin] s-matthew-english opened pull request #9368: change to declarative sentences. simplify links (master...patch-13) https://github.com/bitcoin/bitcoin/pull/9368
< phantomcircuit>
instagibbs, uh do you even need a segwit compatible wallet to spend segwit outputs?
< phantomcircuit>
i didn't think you did
< phantomcircuit>
i don't think you do actually
< Chris_Stewart_5>
phantomcircuit: Pretty sure you do, you won't be able to construct the tx in the proper structure without it
< phantomcircuit>
the utxo entries aren't changes
< phantomcircuit>
changed*
< phantomcircuit>
you'd have to know that there is a transaction output in the utxo to begin with
< phantomcircuit>
but if you have someone providing you transactions with the signatures stripped in normal format
< Chris_Stewart_5>
segwit P2WPKH outputs require a empty script sig, and P2WSH requires a push only scriptSig of 32 bytes i think
< phantomcircuit>
ok?
< phantomcircuit>
so
< phantomcircuit>
you're talking about inputs not outputs
< phantomcircuit>
which is what the person spending cares about
< phantomcircuit>
i mean maybe it's not easy to do
< phantomcircuit>
but you certainly should be able to
< Chris_Stewart_5>
how doe thes person spending an output not care about the input? Isn't that by definition the inputs to the script program to make it evaluate to true?
< phantomcircuit>
Chris_Stewart_5, why would they care about the inputs to a transaction they're spending the outputs of?
< Chris_Stewart_5>
phantomcircuit: 'transactions stripped in normal format' -- so you mean someoen is just providing you a serialized tx to hash, then sign the hash?
< rebroad>
phantomcircuit, if you have a non-segwit wallet, then you can spend any SegWit transaction... but it will never get mined :)
< rebroad>
well, it could get mined by the 5% still on the non-segwit fork.. but would soon get orphaned
< phantomcircuit>
rebroad, why?
< phantomcircuit>
the scriptPubKey is the same right?
< phantomcircuit>
wait maybe it's not
< phantomcircuit>
hmm
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #9369: Factor out CWallet::nTimeSmart computation into a method. (master...pr/atw-timesmart) https://github.com/bitcoin/bitcoin/pull/9369
< bitcoin-git>
bitcoin/master fa16b8f MarcoFalke: If we don't allow free txs, always send a fee filter (take 2)
< bitcoin-git>
bitcoin/master 8c7947e Wladimir J. van der Laan: Merge #9367: If we don't allow free txs, always send a fee filter (take 2)...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
< instagibbs>
phantomcircuit, if your wallet doesn't understand segwit, it has no idea how to sign, if nothing else
< instagibbs>
(sorry missed convo)
< rebroad>
phantomcircuit, segwit as I understand is an extra bunch of rules that pre-segwit wallets have no knowledge of... pre-segwit wallets simply see segwit txs as txs that anyone can spend, so the only thing pre-segwit wallets can do is treat them as such, which segwit wallets and miners will reject as it ignores the segwit rules
< sipa>
rebroad: no wallet does anything with outputs they do not understand
< sipa>
*nodes* will treat those outputs as anyonecanspend, yes
< sipa>
but wallets don't
< sipa>
your wallet does not show you all anyonecanspend outputs on the network now, right?
< sipa>
the only way you will receive a segwit output is if you give out a segwit address, which will only happen if your wallet supports it
< rebroad>
sipa, well, nodes, and modified pre-segwit wallets ;)
< sipa>
sure
< sipa>
they can try
< sipa>
but they won't confirm
< rebroad>
sipa, if they did confirm, miners would build upon those blocks
< rebroad>
at least, pre-segwit activation anyway
< rebroad>
but people would have to be a little foolish to create such a tx pre-segwit
< sipa>
pre-activation you shouldn't be creating segwit outputs
< sipa>
that's very dangerois
< Victorsueca>
creating a segwit transaction without miners and nodes enforcing segwit yet can potentially lead to anyone-can-spend outputs
< sipa>
not potentially
< sipa>
by definition, they will be anyonecanspend outputs
< rebroad>
they need to be anyonecanspend outputs for segwit to be possible
< Victorsueca>
just had a quick thought about this....
< Victorsueca>
let's say the last block in a 2016 block period is the one that decides if segwit activates in that moment or it will in the next period (or even, hopefully not, never)...
< Victorsueca>
and with that block it reaches 95% required to activate it
< sipa>
that's not possible
< sipa>
there is another 2016 block before it activates
< Victorsueca>
ahh right
< sipa>
the 95% makes it go to the LOCKEDIN state
< Victorsueca>
welp, that solves it pretty much
< Victorsueca>
my quick thoughts don't make sense most of the times.... but last time one of them made sense it was a disaster
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370
< jonasschnelli>
I would say that #9370 (or one of the alternative solutions) is a candidate for a 0.13.2 backport.
< phantomcircuit>
instagibbs, you're signing the new transaction not the old one
< phantomcircuit>
rebroad, that's not saying that the wallet needs to understand segwit
< phantomcircuit>
just that it needs to get the utxo entries from somewhere other than the transaction data
< phantomcircuit>
wait no
< phantomcircuit>
the SIGNATURE isn't needed by the person spending
< phantomcircuit>
yeah im 99.99% sure you're wrong
< phantomcircuit>
sipa, segwit doesn't change the outputs at all, just the inputs with the signature
< phantomcircuit>
or does it and i am just very tired and hungry
< sdaftuar>
phantomcircuit: see BIP 141. segwit outputs are constructed differently than non-segwit outputs.
< phantomcircuit>
hmm
< * phantomcircuit>
goes to find a thermometer
< gmaxwell>
rebroad: he changed the text, many times. Last I checked the current text was still wrong as heck.
< phantomcircuit>
101...
< phantomcircuit>
ok then
< phantomcircuit>
oh right
< Victorsueca>
101ºC?
< Victorsueca>
;)
< sipa>
phantomcircuit: p2sh witness outputs are indistinguishable to the network from other p2sh outputs
< sipa>
but they are distinguishable to the receiver... who either knows the redeemscript and how to spend it, or not
< phantomcircuit>
sipa, it's the same as p2sh originally right
< phantomcircuit>
and is because of the change to the signature hashing basically meaning it's a "new" script language
< Victorsueca>
basically you can't know whether it is P2SH, P2WSH or P2WPKH until the outputs are redeemed
< sipa>
phantomcircuit: new signature hashing, and it takes inputs from the witness rather than from the scriptSig directly
< Victorsueca>
some extra privacy, that's always good
< profall>
Hello, what is the default rpcworkqueue on 13.1 ?
< profall>
I want to increase it but I have no idea what the starting value is
< sipa>
16
< profall>
Thank You
< gmaxwell>
sipa: So the chainstate reindex without signature verification test with 300MB dbcache completed, entry-per-txout is ~25% _faster_ than master!
< sipa>
gmaxwell: woah
< sipa>
wasn't only 6% at some point during sync?
< gmaxwell>
I was screwing up the comparison when I was giving you those figures.
< sipa>
wasn't it around the same number for a 2000MB dbcache?
< sipa>
anyway great... more work, now we need to investigate this idea further
< matrix01>
Who can help to gave me a small amount of BTC or borow me some pm me thx!
< sipa>
matrix01: for experimenting purpose, use a testnet faucet. otherwise: this is not a place for begging
< gmaxwell>
Hm? git log --no-merges shows commits from ~150 contributors (some name dupes) from 2015-12-16 to now.
< arubi>
replacing 'type=c' with a mock 'type=none' lists 100 people
< achow101>
maybe some of the authors don't have their emails registered with github so they aren't shown?
< achow101>
they might also be counting committers and not authors
< gmaxwell>
achow101: nope, far too many.
< gmaxwell>
achow101: e.g. you're listed.
< btcdrak>
sounds like we need to report this to github, their data processing appears to be bugged
< achow101>
well I made commits. there are some commits that are like "X committed with Y" so they might be counting that commit as made by Y and not X
< gmaxwell>
achow101: yea, no-- not that either.
< gmaxwell>
there are people not listed that made PRs and had them merged.