< goatpig>
is this the right place to ask about some segwit mechanics?
< sdaftuar>
goatpig: sure
< goatpig>
im mostly concerned about the changes to the transaction format
< goatpig>
does it change anything for outputs?
< sdaftuar>
the serialization of the outputs hasn't changed, just the serialization for transactions with witness have two extra bytes, i believe
< goatpig>
there was nothing about changes in txout format in the bips so i was a bit confused
< sdaftuar>
you're looking at bip144 i assume?
< goatpig>
aside from the commitment in the coinbase scriptpubkey, are wtxids used elsewhere?
< goatpig>
141 143 and 144
< sdaftuar>
wtxid's are not yet used elsewhere, though we can expect they will be soon. sipa just proposed an extension to BIP 152 (compact blocks) that would use them
< sdaftuar>
there's been some discussion about whether tx relay might be better with wtxid's rather than txid's, but that hasn't been settled yet from what i can tell
< goatpig>
so outputs are still referred to by hash in inputs and the merkle root is still built of off hashes?
< sdaftuar>
yes that's right
< sdaftuar>
(hash == txid)
< goatpig>
right
< goatpig>
so
< goatpig>
how does that reduce maleability attack surface?
< achow101>
signatures aren't hashed because they are in the witness
< goatpig>
oic
< goatpig>
right that makes sense now
< achow101>
but only for segwit output types
< goatpig>
you mean outputs defined by segwit'd inputs?
< sdaftuar>
no, outputs that are defined by being version 0 segwit outputs
< achow101>
these are defined in bip141
< achow101>
p2wpkh, p2wsh, and those can also be nested in a normal p2sh
< goatpig>
you mean the stuff in the example section of bip141?
< achow101>
yes
< goatpig>
those look like signed inputs to me
< sdaftuar>
goatpig: can you explain what you mean? i don't follow
< goatpig>
you mean the prepended 0 in the scriptPubKey part?
< goatpig>
sdaftuar: my current understanding of segwit is this
< goatpig>
inputs can be segwit enabled, with the proper construct
< goatpig>
nothing changes in outputs at all
< sdaftuar>
ah
< goatpig>
if im wrong, that explains why im confused
< sdaftuar>
no, the right way to think about this is that we've carved out some of the output space to have special semantics
< goatpig>
that's the prepended 0?
< sdaftuar>
yeah that's the OP_0
< sdaftuar>
so a segwit version 0 P2WSH output looks like this: [OP_0, 32-byte-hash]
< goatpig>
ok so you have to first use a non segwit input redemption to create a segwit enabled output
< goatpig>
then you can segwit input redeem it?
< sdaftuar>
yes, that's right
< achow101>
yes
< goatpig>
ok now it makes sense
< goatpig>
thanks =)
< sdaftuar>
sure!
< goatpig>
achow101: so if the wtxid isn't used anywhere but in the coinbase commitment, what where you using that for?
< goatpig>
armory doesn't implement much of the concensus layer, certainly something that deep
< achow101>
It isn't used at all.
< achow101>
I had to change that hashing stuff to hash the transaction with segwit stuff stripped out
< goatpig>
oh i case of raw block data with the witness data appended?
< achow101>
yes
< goatpig>
ok makes sense
< goatpig>
so in regard to the p2p layer, transcations with witness are inv'd by wtxid right?
< achow101>
no, by normal txid
< achow101>
there is an inv type to get the transaction with witness serialization
< goatpig>
getdata type you mean?
< achow101>
yes
< goatpig>
is there any reason to use anything but MSG_WITNESS_TX in getdata packets instead of MSG_TX?
< goatpig>
i guess besides backwards compatibility with older nodes
< achow101>
^that
< goatpig>
ok so a non issue for armory then
< goatpig>
aight guys, thanks for the help
< NicolasDorier>
I have am synching a node (from currrent master) from another single localhost node. At around 320 000 it takes several second per block (around 5 seconds) my CPU is not speaking, nor disk access, nor memory access.
< NicolasDorier>
any idea of something obvious I could have forgot ?
< goatpig>
anyone here familiar with the BIP151 discussion?
< goatpig>
any reason ChaCha20-Poly1305 was picked over AES-GCM?
< NicolasDorier>
my connect block takes really long, I'm not sure it is normal. Some blocks take more than 15s... I never benchmarked before, is it normal ?
< wumpus>
NicolasDorier: what kind of CPU/disk?
< btcdrak>
goatpig: iirc, because SSH uses it. ping jonasschnelli
< wumpus>
I've also noticed really slow i/o on windows, but assumed it was just the slow laptop
< NicolasDorier>
may me that...
< NicolasDorier>
well on my side it can be worse because
< NicolasDorier>
it is a VM on azure
< wumpus>
right
< jonasschnelli>
[09:47:47] <goatpig>[04:21:48] any reason ChaCha20-Poly1305 was picked over AES-GCM?
< jonasschnelli>
ChaCha20-Poly1305 is also faster
< gmaxwell>
The recommendation sipa and I made is because it is considerably faster on anything without hardware AES.
< gmaxwell>
And the devices with hardware AES it is only slightly slower, and those devices we largely don't care about how fast it is (as they're faster hardware)
< gmaxwell>
helpfully it also requires very little code for a good implementation. The same can't really be said for AES-GCM.
< adiabat>
also stream cipher beats block cipher any day of the week (imho)
< gmaxwell>
both are stream ciphers.
< adiabat>
well, AES isn't... GCM sortof makes it into one
< gmaxwell>
There is no sort of, there. And what was being discussed was AES-GCM not AES-CBC or otherwise.
< gmaxwell>
it is unambigiously a stream cipher. Which is an appropritate tool here even though stream ciphers have a long and well established history of resulting, in practice, in insecure protocols usually because of the fragility of IV handling, and how often developers mishandle them.
< adiabat>
maybe linked to the "very little code", I think using a counter mode to make a stream cipher is more complex than starting with one
< gmaxwell>
much of the code complexity for AES-GCM comes from sidechannel resistance for AES being hard, especially if performance must be maintained. chach20 (which is _also_ a block cipher in CTR mode internally) is unusually simple however.
< adiabat>
I mean, I understand that the code is what matters but if you look up "AES", people call it a block cipher, and "chacha20", people call a stream cipher
< adiabat>
I guess chacha20 is more specified than aes, which has a plethora of modes
< adiabat>
You can certainly shoot yourself in the foot with any of them though
< sipa>
adiabat: chacha20 is internally also a block transformation, which is being used in counter mode
< sipa>
except there is no standardization for the pure transformation
< sipa>
NicolasDorier: what is your db cache?
< NicolasDorier>
kept default
< NicolasDorier>
good idea, trying to change it to see how it goes
< sipa>
it helps massively on systems with slow io
< NicolasDorier>
just changed to 1024 to see how it goes
< NicolasDorier>
does not seems to improve it that much... It may come from some kind of IO threshold I may be hitting on Azure. If nobody experience that it's fine
< NicolasDorier>
this is highly possible, as I have several bitcoind instance as well as an indexer for my blockexplorer on the same machine
< NicolasDorier>
I'll try on a brand new VM later, I think it is just some IO threshold of azure
< NicolasDorier>
or try to just update the disk to be SSD on the vm, on a separate azure storage account (the threshold "domain"). I think we can disregard my machine for now, if nobody experience such slowness it is probably my VM's fault
< sipa>
are these recent blocks?
< sipa>
or during initial sync?
< NicolasDorier>
initial sync
< sipa>
can you run eith -debug=bench ?
< NicolasDorier>
it is what I did, look the screenshot I sent
< goatpig>
gmaxwell: adiabat: so to summarize, ChaCha20-Poly1305 has a simpler implementation (less chance of mishandling) and is faster on desktop CPUs.
< goatpig>
is there a stand alone implementation of that cypher or does one have to go to OpenSSL?
< goatpig>
also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
< NicolasDorier>
There is a refactoring I am thinking about as part as libconsenus work: Instead of calling UTXOs database directly in the consensus code lazily as we need them, aggressively fetching them before calling consensus functions. This would also mean we can parallelize previous coin fetching more easily.
< NicolasDorier>
*lazily as we need the previous coins
< NicolasDorier>
might make the Connect Transaction quicker
< goatpig>
can someone answer some more SW related questions?
< sipa>
NicolasDorier: that's actually what happens
< sipa>
NicolasDorier: haveinputs gets called first
< sipa>
which loads everything in the cache
< NicolasDorier>
oooh so that's what the dbcache is about ?
< NicolasDorier>
I thought the dbcache was just about keeping recent output in cache as they have higher chance to get used later
< sipa>
there are several layers of cache :)
< sipa>
NicolasDorier: there is pcoinsTip
< sipa>
but there is also a second cache in ConnectBlock, which fetches the inputs, does validation, applies the changes to the utxo set to thid 2nd cache
< sipa>
and when validation succeeds, the changes in the 2nd cache are pushed to pcoinsTip
< sipa>
if validatiin fails, the changes in the second cache are discarded
< gmaxwell>
::sigh:: cookie auth picks passwords which are apparer to be incompatible with the python json rpc stuff. (apparently it can't handle passwords with / in them)
< sipa>
file an issue
< sipa>
this sounds like a simple introduction task
< gmaxwell>
I think the bug is in some python URL lib, though for the code that provided recommended rpcpasswords in the past I used base58 in order to avoid any characters that would get mishandled in URLs.
< sipa>
we need base66 code
< sipa>
there are 66 url-safe characters (a-z, A-Z, 0-9, _, -, ., ~)
< Chris_Stewart_5>
When checking signatures for a SIGHASH_ALL, do you remove all inputs AFTER the input index you are checking?
< sipa>
check the code :)
< sipa>
there are two versiond
< sipa>
one in script/interpreter, one in test/sighash_testz
< Chris_Stewart_5>
sipa: Does it make sense to have a correct r value when creating a digital signature but an incorrect s value (and that is not related to low-s)?
< sipa>
Chris_Stewart_5: make sense for whatm
< sipa>
every value for r can be correct
< Chris_Stewart_5>
hmm yeah, I guess I don't know really what I am trying to say. It seems strange that only one of the values would be incorrect on a signature and not both of them
< sipa>
you can't individually judge them
< Chris_Stewart_5>
when trying to recreate a digital signature from bitcoin core
< sipa>
your r is right but the s is not?
< Chris_Stewart_5>
yes
< Chris_Stewart_5>
and it is not due to low-s, i've made to sure to check that
< sipa>
can you paste the signature?
< Chris_Stewart_5>
sure, i'll paste the correct one the one i have generated