< AdrianG>
whats the alt stack for in bitcoin script?
< luke-jr>
AdrianG: an alternate stack
< AdrianG>
so its a two-stack pushdown automata then?
< AdrianG>
are the stacks fully equivalent?
< sipa>
bitcoin script is not a pushdown automata
< sipa>
because it has OP_PICK
< sipa>
code has access to all elements, always, not just the top
< luke-jr>
AdrianG: no, the alt stack is wiped between scripts, and has fewer opcodes to use it
< * luke-jr>
OP_PICKs sipa
< AdrianG>
sipa: that sounds like it would be a superset of a PDA then?
< sipa>
it also follows intructions, not a state transition table
< gmaxwell>
AdrianG: you can rewrite any script using the altstack without it (just using pick). The altstack is there for the same reason that it's there in any forth implementation-- its a convenience and can result in fewer operations for some things.
< gmaxwell>
apparently you've heard this craig wright stuff, it's pure gibberish.
< gmaxwell>
AdrianG: his gibbering is basically trying to argue that script is universal but you don't need any of this technobable to show that, all you need to show is that it has a controlled-not.
< gmaxwell>
That doesn't mean much of anything interesting though because there are very tight limits on how much computation you can do (which is why it isn't turing complete)
< gmaxwell>
Wright is doing some pattern matching with finite state machines, where there is a well known result that one equipt with two 'stacks' (which are not like the forth-like stacks in bitcoin, but are simple things where you can only access the top elements) can be universal.
< BlueMatt>
gmaxwell: no wonder wright hates you....you dont trivially fall for stupid technobabble like so many others
< wumpus>
craig wright hates us all
< wumpus>
but yes that's a good thing
< wumpus>
results from yesterday's benchmark sync up to block 430241: 0.14.2 took 08:12:29 (29549s), master took 06:20:57 (22857s), so ~23% faster
< wumpus>
really neat
< wumpus>
both with default dbcache setting
< wumpus>
going to time catch-up syncs from there to tip as well
< wumpus>
might be interesting to plot the validation times per block w/ debug=bench too
< wumpus>
not only is the sync faster, it seems to have less impact on the rest of the system, catching up the chain used to make any other things like browsing impossible on this system. Doesn't seem to be so much a CPU difference (CPU wasn't maxed out in either case) but memory usage/IO related.
< gmaxwell>
yea, I've noticed that too. Some of it I think might be the big peak memory usage and gigantic all at once writes was blowing out buffers.
< wumpus>
indeed!
< phantomcircuit>
the configure scripts dont seem to be able to find db5.3 on gentoo
< phantomcircuit>
luke-jr, any idea what's wrong here?
< phantomcircuit>
(and yes i know it's supported to be db 4.8 but i have a wallet that's 5.3)
< luke-jr>
nope, sorry
< luke-jr>
I assume you used --with-incompatible-bdb?
< phantomcircuit>
yeah
< phantomcircuit>
checking the config.log there's no mention of even looking for 5.3
< phantomcircuit>
i wonder if something got removed on accident
< kanzure>
"frustrating that the RPC isn't versioned and massively breaking changes like this are just introduced without any versioning and/or flags" i guess something like that could work, shouldn't getblock start throwing up warnings at least even if not versioned?
< kanzure>
s/shouldn't/couldn't/ is more accurately my question.
< sipa>
kanzure: ?
< sipa>
what is the context?
< sipa>
we try very hard not to break RPC
< kanzure>
btcd issue tracker someone is complaining about getblock/testnet/segwit
< sipa>
oh, btcd
< kanzure>
yes but the complaint is about bitcoind rpc versioning not btcd rpc versioning