1 2016-07-24 01:33:53	0|goatpig|is this the right place to ask about some segwit mechanics?
  2 2016-07-24 01:43:04	0|sdaftuar|goatpig: sure
  3 2016-07-24 01:43:48	0|goatpig|im mostly concerned about the changes to the transaction format
  4 2016-07-24 01:43:57	0|goatpig|does it change anything for outputs?
  5 2016-07-24 01:47:34	0|sdaftuar|the serialization of the outputs hasn't changed, just the serialization for transactions with witness have two extra bytes, i believe
  6 2016-07-24 01:48:13	0|goatpig|there was nothing about changes in txout format in the bips so i was a bit confused
  7 2016-07-24 01:48:52	0|sdaftuar|you're looking at bip144 i assume?
  8 2016-07-24 01:49:05	0|goatpig|aside from the commitment in the coinbase scriptpubkey, are wtxids used elsewhere?
  9 2016-07-24 01:49:19	0|goatpig|141 143 and 144
 10 2016-07-24 01:50:24	0|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
 11 2016-07-24 01:50:28	0|sdaftuar|https://github.com/bitcoin/bips/pull/423
 12 2016-07-24 01:51:15	0|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
 13 2016-07-24 01:51:48	0|goatpig|so outputs are still referred to by hash in inputs and the merkle root is still built of off hashes?
 14 2016-07-24 01:52:13	0|sdaftuar|yes that's right
 15 2016-07-24 01:52:32	0|sdaftuar|(hash == txid)
 16 2016-07-24 01:52:48	0|goatpig|right
 17 2016-07-24 01:52:50	0|goatpig|so
 18 2016-07-24 01:53:11	0|goatpig|how does that reduce maleability attack surface?
 19 2016-07-24 01:53:31	0|achow101|signatures aren't hashed because they are in the witness
 20 2016-07-24 01:53:44	0|goatpig|oic
 21 2016-07-24 01:53:49	0|goatpig|right that makes sense now
 22 2016-07-24 01:54:03	0|achow101|but only for segwit output types
 23 2016-07-24 01:54:41	0|goatpig|you mean outputs defined by segwit'd inputs?
 24 2016-07-24 01:55:50	0|sdaftuar|no, outputs that are defined by being version 0 segwit outputs
 25 2016-07-24 01:56:09	0|achow101|these are defined in bip141
 26 2016-07-24 01:56:36	0|achow101|p2wpkh, p2wsh, and those can also be nested in a normal p2sh
 27 2016-07-24 01:57:36	0|goatpig|you mean the stuff in the example section of bip141?
 28 2016-07-24 01:57:41	0|achow101|yes
 29 2016-07-24 01:58:16	0|goatpig|those look like signed inputs to me
 30 2016-07-24 01:58:41	0|sdaftuar|goatpig: can you explain what you mean?  i don't follow
 31 2016-07-24 01:58:49	0|goatpig|you mean the prepended 0 in the scriptPubKey part?
 32 2016-07-24 01:59:26	0|goatpig|sdaftuar: my current understanding of segwit is this
 33 2016-07-24 01:59:43	0|goatpig|inputs can be segwit enabled, with the proper construct
 34 2016-07-24 01:59:47	0|goatpig|nothing changes in outputs at all
 35 2016-07-24 01:59:50	0|sdaftuar|ah
 36 2016-07-24 02:00:08	0|goatpig|if im wrong, that explains why im confused
 37 2016-07-24 02:00:15	0|sdaftuar|no, the right way to think about this is that we've carved out some of the output space to have special semantics
 38 2016-07-24 02:00:28	0|goatpig|that's the prepended 0?
 39 2016-07-24 02:00:36	0|sdaftuar|yeah that's the OP_0
 40 2016-07-24 02:01:03	0|goatpig|ok so you have to first use a non segwit input redemption to create a segwit enabled output
 41 2016-07-24 02:01:03	0|sdaftuar|so a segwit version 0 P2WSH output looks like this: [OP_0, 32-byte-hash]
 42 2016-07-24 02:01:10	0|goatpig|then you can segwit input redeem it?
 43 2016-07-24 02:01:10	0|sdaftuar|yes, that's right
 44 2016-07-24 02:01:14	0|achow101|yes
 45 2016-07-24 02:01:16	0|goatpig|ok now it makes sense
 46 2016-07-24 02:01:18	0|goatpig|thanks =)
 47 2016-07-24 02:01:33	0|sdaftuar|sure!
 48 2016-07-24 02:02:47	0|goatpig|achow101: so if the wtxid isn't used anywhere but in the coinbase commitment, what where you using that for?
 49 2016-07-24 02:03:08	0|goatpig|armory doesn't implement much of the concensus layer, certainly something that deep
 50 2016-07-24 02:03:30	0|achow101|It isn't used at all.
 51 2016-07-24 02:03:55	0|achow101|I had to change that hashing stuff to hash the transaction with segwit stuff stripped out
 52 2016-07-24 02:04:15	0|goatpig|oh i case of raw block data with the witness data appended?
 53 2016-07-24 02:04:22	0|achow101|yes
 54 2016-07-24 02:04:31	0|goatpig|ok makes sense
 55 2016-07-24 02:06:59	0|goatpig|so in regard to the p2p layer, transcations with witness are inv'd by wtxid right?
 56 2016-07-24 02:07:35	0|achow101|no, by normal txid
 57 2016-07-24 02:08:27	0|achow101|there is an inv type to get the transaction with witness serialization
 58 2016-07-24 02:08:36	0|goatpig|getdata type you mean?
 59 2016-07-24 02:08:58	0|achow101|yes
 60 2016-07-24 02:09:06	0|goatpig|is there any reason to use anything but MSG_WITNESS_TX in getdata packets instead of MSG_TX?
 61 2016-07-24 02:09:37	0|goatpig|i guess besides backwards compatibility with older nodes
 62 2016-07-24 02:09:55	0|achow101|^that
 63 2016-07-24 02:10:02	0|goatpig|ok so a non issue for armory then
 64 2016-07-24 02:10:36	0|goatpig|aight guys, thanks for the help
 65 2016-07-24 02:17:45	0|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.
 66 2016-07-24 02:17:59	0|NicolasDorier|any idea of something obvious I could have forgot ?
 67 2016-07-24 02:21:33	0|goatpig|anyone here familiar with the BIP151 discussion?
 68 2016-07-24 02:21:49	0|goatpig|any reason ChaCha20-Poly1305 was picked over AES-GCM?
 69 2016-07-24 02:26:12	0|NicolasDorier|https://www.irccloud.com/pastebin/at6M00hU/
 70 2016-07-24 02:26:25	0|NicolasDorier|holy cow Connect transactions takes 70s
 71 2016-07-24 02:28:41	0|NicolasDorier|ah no 32s... still...
 72 2016-07-24 02:31:06	0|NicolasDorier|ok... did not sleep well 1000ms = 1s. Nevermind what I said.
 73 2016-07-24 02:50:36	0|GitHub73|[13bitcoin] 15cqtenq opened pull request #8396: remove outdated legacy code (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8396
 74 2016-07-24 04:09:24	0|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 ?
 75 2016-07-24 05:08:23	0|wumpus|NicolasDorier: what kind of CPU/disk?
 76 2016-07-24 05:18:23	0|btcdrak|goatpig: iirc, because SSH uses it. ping jonasschnelli
 77 2016-07-24 05:36:04	0|NicolasDorier|wumpus: 2 core 2.20Ghz, 3.5 RAM. Neither are capped
 78 2016-07-24 05:36:24	0|NicolasDorier|Basically an A2 on azure (https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/)
 79 2016-07-24 05:37:36	0|wumpus|usually the cause of really slow connect times, when CPU is not at 100%, is i/o bottleneck
 80 2016-07-24 05:53:24	0|NicolasDorier|wumpus:
 81 2016-07-24 05:53:28	0|NicolasDorier|https://usercontent.irccloud-cdn.com/file/UeL6uFo1/
 82 2016-07-24 05:53:35	0|NicolasDorier|it seems kind of strange
 83 2016-07-24 05:53:47	0|NicolasDorier|one sec I check io
 84 2016-07-24 05:54:57	0|NicolasDorier|https://usercontent.irccloud-cdn.com/file/glkQVh8o/
 85 2016-07-24 05:54:59	0|NicolasDorier|mmh
 86 2016-07-24 05:55:04	0|wumpus|I've also noticed really slow i/o on windows, but assumed it was just the slow laptop
 87 2016-07-24 05:55:05	0|NicolasDorier|may me that...
 88 2016-07-24 05:55:16	0|NicolasDorier|well on my side it can be worse because
 89 2016-07-24 05:55:19	0|NicolasDorier|it is a VM on azure
 90 2016-07-24 05:55:42	0|wumpus|right
 91 2016-07-24 07:48:36	0|jonasschnelli|[09:47:47]  <goatpig>	[04:21:48] any reason ChaCha20-Poly1305 was picked over AES-GCM?
 92 2016-07-24 07:48:45	0|jonasschnelli|ChaCha20-Poly1305 is also faster
 93 2016-07-24 08:15:14	0|gmaxwell|The recommendation sipa and I made is because it is considerably faster on anything without hardware AES.
 94 2016-07-24 08:15:43	0|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)
 95 2016-07-24 08:16:31	0|gmaxwell|helpfully it also requires very little code for a good implementation. The same can't really be said for AES-GCM.
 96 2016-07-24 08:30:23	0|adiabat|also stream cipher beats block cipher any day of the week (imho)
 97 2016-07-24 08:31:08	0|gmaxwell|both are stream ciphers.
 98 2016-07-24 08:31:29	0|adiabat|well, AES isn't... GCM sortof makes it into one
 99 2016-07-24 08:32:25	0|gmaxwell|There is no sort of, there. And what was being discussed was AES-GCM not AES-CBC or otherwise.
100 2016-07-24 08:33:34	0|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.
101 2016-07-24 08:33:40	0|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
102 2016-07-24 08:36:17	0|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.
103 2016-07-24 08:38:18	0|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
104 2016-07-24 08:38:56	0|adiabat|I guess chacha20 is more specified than aes, which has a plethora of modes
105 2016-07-24 08:40:19	0|adiabat|You can certainly shoot yourself in the foot with any of them though
106 2016-07-24 09:02:37	0|sipa|adiabat: chacha20 is internally also a block transformation, which is being used in counter mode
107 2016-07-24 09:10:32	0|sipa|except there is no standardization for the pure transformation
108 2016-07-24 09:11:14	0|sipa|NicolasDorier: what is your db cache?
109 2016-07-24 09:11:46	0|NicolasDorier|kept default
110 2016-07-24 09:12:53	0|NicolasDorier|good idea, trying to change it to see how it goes
111 2016-07-24 09:16:21	0|sipa|it helps massively on systems with slow io
112 2016-07-24 09:17:03	0|NicolasDorier|just changed to 1024 to see how it goes
113 2016-07-24 09:26:44	0|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
114 2016-07-24 09:27:18	0|NicolasDorier|this is highly possible, as I have several bitcoind instance as well as an indexer for my blockexplorer on the same machine
115 2016-07-24 09:33:45	0|sipa|are you hitting swap space?
116 2016-07-24 09:35:56	0|NicolasDorier|sipa: nop
117 2016-07-24 09:36:00	0|NicolasDorier|https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
118 2016-07-24 09:36:05	0|NicolasDorier|my ram seems fine
119 2016-07-24 09:36:10	0|NicolasDorier|and cpu as well
120 2016-07-24 09:36:38	0|NicolasDorier|I'll try on a brand new VM later, I think it is just some IO threshold of azure
121 2016-07-24 09:38:21	0|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
122 2016-07-24 09:39:09	0|sipa|are these recent blocks?
123 2016-07-24 09:39:19	0|sipa|or during initial sync?
124 2016-07-24 09:39:28	0|NicolasDorier|initial sync
125 2016-07-24 09:39:34	0|sipa|can you run eith -debug=bench ?
126 2016-07-24 09:39:44	0|NicolasDorier|it is what I did, look the screenshot I sent
127 2016-07-24 09:39:51	0|sipa|oops missed that
128 2016-07-24 09:40:07	0|NicolasDorier|https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
129 2016-07-24 09:41:00	0|sipa|ok, it's spending really all the time fetching inputs
130 2016-07-24 09:41:36	0|NicolasDorier|"connect transactions" mean fetching the inputs ?
131 2016-07-24 09:41:42	0|sipa|yes
132 2016-07-24 09:42:24	0|sipa|well, it does more than that
133 2016-07-24 09:42:39	0|sipa|but fetching inouts is the only slow part
134 2016-07-24 09:43:17	0|NicolasDorier|ok yeah so no worry. I'll try with better hard drive and separate on another azure storage account and see if it is better later
135 2016-07-24 10:27:12	0|GitHub192|[13bitcoin] 15asteroidsbg opened pull request #8397: 0.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/8397
136 2016-07-24 10:40:01	0|GitHub81|[13bitcoin] 15jonasschnelli closed pull request #8397: 0.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/8397
137 2016-07-24 12:39:06	0|goatpig|gmaxwell: adiabat: so to summarize, ChaCha20-Poly1305 has a simpler implementation (less chance of mishandling) and is faster on desktop CPUs.
138 2016-07-24 12:39:25	0|goatpig|is there a stand alone implementation of that cypher or does one have to go to OpenSSL?
139 2016-07-24 12:40:05	0|goatpig|also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
140 2016-07-24 14:27:09	0|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.
141 2016-07-24 14:27:27	0|NicolasDorier|*lazily as we need the previous coins
142 2016-07-24 14:27:57	0|NicolasDorier|might make the Connect Transaction quicker
143 2016-07-24 15:47:08	0|goatpig|can someone answer some more SW related questions?
144 2016-07-24 15:49:30	0|sipa|NicolasDorier: that's actually what happens
145 2016-07-24 15:49:41	0|sipa|NicolasDorier: haveinputs gets called first
146 2016-07-24 15:49:51	0|sipa|which loads everything in the cache
147 2016-07-24 15:50:18	0|NicolasDorier|oooh so that's what the dbcache is about ?
148 2016-07-24 15:50:49	0|NicolasDorier|I thought the dbcache was just about keeping recent output in cache as they have higher chance to get used later
149 2016-07-24 15:58:28	0|sipa|there are several layers of cache :)
150 2016-07-24 16:22:32	0|sipa|NicolasDorier: there is pcoinsTip
151 2016-07-24 16:23:06	0|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
152 2016-07-24 16:23:23	0|sipa|and when validation succeeds, the changes in the 2nd cache are pushed to pcoinsTip
153 2016-07-24 16:23:40	0|sipa|if validatiin fails, the changes in the second cache are discarded
154 2016-07-24 21:57:35	0|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)
155 2016-07-24 22:00:57	0|sipa|file an issue
156 2016-07-24 22:01:13	0|sipa|this sounds like a simple introduction task
157 2016-07-24 22:02:21	0|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.
158 2016-07-24 22:04:58	0|sipa|we need base66 code
159 2016-07-24 22:05:43	0|sipa|there are 66 url-safe characters (a-z, A-Z, 0-9, _, -, ., ~)
160 2016-07-24 22:07:27	0|gmaxwell|https://github.com/bitcoin/bitcoin/issues/8399
161 2016-07-24 22:07:39	0|gmaxwell|base58 is fine.
162 2016-07-24 22:15:46	0|sipa|but but but 3.18% less space efficient for the same information density
163 2016-07-24 22:38:34	0|GitHub87|[13bitcoin] 15yurizhykin opened pull request #8400: [qa]: enable rpcbind_test (06master...06rpcbind-test) 02https://github.com/bitcoin/bitcoin/pull/8400
164 2016-07-24 22:39:49	0|gmaxwell|sipa: who cares. :P
165 2016-07-24 23:12:37	0|Chris_Stewart_5|When checking signatures for a SIGHASH_ALL, do you remove all inputs AFTER the input index you are checking?
166 2016-07-24 23:17:59	0|sipa|check the code :)
167 2016-07-24 23:18:03	0|sipa|there are two versiond
168 2016-07-24 23:18:27	0|sipa|one in script/interpreter, one in test/sighash_testz
169 2016-07-24 23:40:43	0|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)?
170 2016-07-24 23:51:36	0|sipa|Chris_Stewart_5: make sense for whatm
171 2016-07-24 23:52:15	0|sipa|every value for r can be correct
172 2016-07-24 23:52:20	0|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
173 2016-07-24 23:52:43	0|sipa|you can't individually judge them
174 2016-07-24 23:52:45	0|Chris_Stewart_5|when trying to recreate a digital signature from bitcoin core
175 2016-07-24 23:53:00	0|sipa|your r is right but the s is not?
176 2016-07-24 23:53:03	0|Chris_Stewart_5|yes
177 2016-07-24 23:53:21	0|Chris_Stewart_5|and it is not due to low-s, i've made to sure to check that
178 2016-07-24 23:53:35	0|sipa|can you paste the signature?
179 2016-07-24 23:53:55	0|Chris_Stewart_5|sure, i'll paste the correct one the one i have generated
180 2016-07-24 23:58:59	0|Chris_Stewart_5|http://pastebin.com/L9veUyXV