1 2016-01-05 01:00:36 <rusty> Hmm, can anyone shed light for me on the claim that due to the minrelay increase "The core wallet itself issued double spends using inputs from  semi-propagated tx’s that never confirmed due to the min realy fee  increase. It was an issue for all wallets."
  2 2016-01-05 01:01:51 <rusty> I was under the impression that the core wallet would not, by default, produce a tx lowfee enough to hit a 5000 satoshi relay limit.
  3 2016-01-05 01:02:15 <sipa> and if it did, it would not get relayed at all
  4 2016-01-05 01:02:21 <sipa> i think
  5 2016-01-05 01:02:29 <pigeons> where is that claim from? it won't spend unconfirmed inputs either unless 1) they are yours and 2) you specifically change the default
  6 2016-01-05 01:03:36 <rusty> pigeons: conspiracy theorist commenting on my blog post http://rusty.ozlabs.org/?p=573
  7 2016-01-05 01:11:48 <Luke-Jr> sounds pretty bogus to me
  8 2016-01-05 01:12:08 <Luke-Jr> the only time Core has ever issued double spends was due to a bug in master, but that was never in any release
  9 2016-01-05 01:12:48 <sipa> indeed, master before 0.12 did for a while
 10 2016-01-05 02:13:59 <morcos> rusty: by default core might produce a tx with a very low fee rate for sure
 11 2016-01-05 02:14:29 <morcos> The GUI defaults to estimatefee 25, which for a long period of time was returning a feerate of 1000 sat/kB
 12 2016-01-05 02:15:49 <morcos> Also rather annoyingly if it couldn't get an estimate for 1 confirmation then it would default to the minimum fee rate.
 13 2016-01-05 02:16:18 <morcos> For 0.12 it is more conservative on the rate it returs and the only time it'll default to a low rate is if there just isn't enough data at all to give any estimate
 14 2016-01-05 02:16:40 <morcos> Perhaps it would make sense to default to a different number other than the relay minimum in that case though
 15 2016-01-05 02:17:35 <rusty> morcos: interesting... well, min fee rate was still 10,000, but using a feerate of 1000 if more than half the nodes won't relay it sounds like a trainwreck.
 16 2016-01-05 02:18:50 <rusty> morcos: I'm not sure how fast the increase to 5000 spread (the advice was to adjust manually IIRC), but it seems that core could have easily had stuck transactions.
 17 2016-01-05 02:19:37 <morcos> ok, so i just looked at the code, and it looks to me like there is a separate default min feerate, but right now that is 1000 sat/kb
 18 2016-01-05 02:20:27 <morcos> core could definitely have had stuck txs...  and will still have that possibility in the future, although we should do all we can to lessen the liklihood
 19 2016-01-05 02:20:56 <morcos> if one of us is willing to risk wumpus ostracizing us, we could suggest changing DEFAULT_TRANSACTION_MINFEE
 20 2016-01-05 02:21:11 <rusty> morcos: hmm, do we have any idea how many nodes will propagate 1000 sat fees?
 21 2016-01-05 02:21:23 <morcos> in 0.12 the relay minimum is back to 1000
 22 2016-01-05 02:21:25 <morcos> btw
 23 2016-01-05 02:21:43 <rusty> morcos: interesting, so it was really a transitory issue.
 24 2016-01-05 02:21:58 <morcos> so if you have a fee estimate you can go below the default min tx fee, but you can not go below the default min relay fee regardless of whether you have an estimate
 25 2016-01-05 02:22:31 <morcos> but the default min tx fee serves as what you pay if your estimates aren't working
 26 2016-01-05 02:23:24 <morcos> rusty: no not necessarily .  the issue doesn't go away b/c the hard coded relay min is 1000, b/c there can be an effectively higher required rate to relay based on full mempools
 27 2016-01-05 02:24:06 <morcos> when are you saying min fee rate was 10,000, and which rate are you talking about?
 28 2016-01-05 02:25:47 <sipa> rusty: the raise to 5000 is only in 0.11.2 as a temporary measure to reduce mempools exploding
 29 2016-01-05 02:26:18 <sipa> rusty: 0.12 has 1000 again, though the effective relay fee rate is there determined by mempool evictions
 30 2016-01-05 02:26:24 <morcos> sipa: i thikn rusty has a point though, the fall back to 1000 doesn't make sense.
 31 2016-01-05 02:26:25 <rusty> sipa: ... combined with the advice to increase manually, the claim is that it's causing the "stuck txs" people are complaining about.
 32 2016-01-05 02:27:11 <rusty> aj: have you shared your graphs yet, mind if I do?
 33 2016-01-05 02:27:55 <morcos> given that we only fall back if we don't have estiamtes, its fine if the fall back is a bit too high a fee on average...  we can always pay less than that with estimates
 34 2016-01-05 02:32:23 <rusty> morcos: sorry, the 10k number came from the default behaviour of other wallets, AFAICT.  It's the most common fee level, looking at the blockchain.
 35 2016-01-05 02:34:39 <morcos> rusty: you are talking not about a feerate but a fee right.  from what i remember it used to be the case that a fee of 10k sat was very common which typicall led to a fee rate around 44000 sat/KB
 36 2016-01-05 02:35:37 <rusty> morcos: both cases: I can get numbers if you want. Things like trezor do 10k fee *fixed*.
 37 2016-01-05 02:36:02 <morcos> thats ok, i've seen enough fee numbers for one lifetime
 38 2016-01-05 02:41:25 <rusty> morcos: the lack of transparency as to what's actually happening is pretty horrifying :(  I know that the 5000 bump was kind of an emergency fix, but it's not clear how many wallets may be effected.
 39 2016-01-05 02:41:57 <morcos> rusty: not following exactly what you mean
 40 2016-01-05 02:42:14 <morcos> i think the problem is that Core like every other wallet wasn't super prepared to handle a fee market
 41 2016-01-05 02:42:36 <morcos> so several improvements are in place for 0.12
 42 2016-01-05 02:43:00 <morcos> but the bump to 5000 didn't really have that bad effect i think you're imagining
 43 2016-01-05 02:43:08 <rusty> morcos: it's worse than that, I think.  Even with fee estimation, which was supposed to fix fee issues, you can go below the 5000 satoshi relay floor.
 44 2016-01-05 02:43:14 <rusty> morcos: how would we know?
 45 2016-01-05 02:43:52 <morcos> rusty: the badness was there b/c we all of a sudden started being in a position where fees mattered, b/c there were more txs than block space
 46 2016-01-05 02:44:10 <morcos> fee estimation was just v0.1 of how to handle that
 47 2016-01-05 02:44:16 <morcos> now its maybe at v0.2
 48 2016-01-05 02:44:17 <gijensen> I sent a TX with 2000 sat/KB about a month ago and it confirmed in about 18 hours IIRC. Not so bad IMO
 49 2016-01-05 02:44:54 <morcos> so if your own node had a min relay fee of 5000 sat per kb then you would not ever send a tx with a lower feerate
 50 2016-01-05 02:45:08 <rusty> morcos: sure, but the last one to upgrade loses, right?
 51 2016-01-05 02:45:09 <morcos> however if your own node still had a 1000 sat per kb feerate then sure you might
 52 2016-01-05 02:45:36 <morcos> but to the extent fee esitmation is working, its not going to give you an answer less than that, b/c those txs are clearly not getting included in blocks if no one is relaying them
 53 2016-01-05 02:45:42 <morcos> now fee estimation is far from perfect
 54 2016-01-05 02:46:07 <morcos> and thats one of the areas in which it is particularly bad, it takes a while to recognize that something that used to be getting confirmed is now no longer
 55 2016-01-05 02:46:18 <morcos> but this is an evolution
 56 2016-01-05 02:46:29 <morcos> and jeez, it sure would help if people would review this stuff
 57 2016-01-05 02:46:32 <rusty> morcos: sure, but what if your 8 connections are all insisiting on 5000, but there are others which aren;t?  Estimation will fail you htere.
 58 2016-01-05 02:47:11 <morcos> rusty: no, b/c your fee estimation will stop seeing <5000 feerate txs and eventually stop saying those are good enough
 59 2016-01-05 02:47:19 <morcos> if you don't see it in your mempool its not a data point
 60 2016-01-05 02:47:28 <morcos> you dont' care about txs in blocks that you didn't see
 61 2016-01-05 02:47:33 <rusty> morcos: even if it's in blocks?  Interesting....
 62 2016-01-05 02:47:49 <morcos> i had v0.2 of fee estimation written 6 months ago and no one reviewed it
 63 2016-01-05 02:48:01 <morcos> v0.3 also written, but i never even bothered with a PR
 64 2016-01-05 02:48:11 <sipa> rusty: see it this way: miners choose which transactions to include, and may be payed through various means
 65 2016-01-05 02:48:22 <morcos> sipa: HA!
 66 2016-01-05 02:48:25 <morcos> thats not helpful
 67 2016-01-05 02:48:36 <morcos> that screws up fee esitmation even more, bc you may have seen those txs
 68 2016-01-05 02:48:46 <sipa> rusty: the p2p network, the mempool, and tx fees together form one means of distributing transactions
 69 2016-01-05 02:48:57 <sipa> and fee estimation only applies to thay
 70 2016-01-05 02:49:27 <rusty> sipa: Or, see it this way: user spends bitcoin, it doesn't work, doesn't know why.
 71 2016-01-05 02:49:29 <sipa> so anything that wasn't in the mempool before confirmationz from your point of view, was distributed through another means
 72 2016-01-05 02:50:11 <rusty> sipa: yes, that makes some degree of sense.
 73 2016-01-05 02:50:17 <sipa> rusty: i'm aware that's a problem; i'm not talking about that - just explaining why txn not seen in the mempool are not estimation data points
 74 2016-01-05 02:50:25 <morcos> rusty: for sure, its not perfect at all.  And you raise a great point that we need increase the default minimum.  (And turns out that breaks some other UI stuff, b/c its not really clear what that number is supposed to be for)
 75 2016-01-05 02:50:41 <morcos> Damn priority is making things complicated again, so its not trivial to just raise it without confusing people
 76 2016-01-05 02:50:58 <rusty> sipa: one might argue for the minimum of the two estima.  You might be seeing a crapload of spam, which miners are ignoring.  But maybe it already does that, I should read the code :)
 77 2016-01-05 02:51:15 <morcos> sipa: they are also not estimation data points b/c you don't know how long it took them to make it into a block
 78 2016-01-05 02:51:30 <morcos> rusty: maximum
 79 2016-01-05 02:51:48 <rusty> morcos: .... err, yeah.
 80 2016-01-05 02:51:50 <sipa> morcos: right
 81 2016-01-05 02:52:10 <dgenr8> morcos: why did you write those features?  wasn't there somebody who wanted them who would review them?
 82 2016-01-05 02:52:27 <morcos> the clear improvement that needs to happen now is to see how many blocks deep the tx would be just based on your mempool, and use that as another lower/upper/whatever bound
 83 2016-01-05 02:52:53 <morcos> dgenr8: like all of bitcoin development, everybody wants it and about a dozen people are wiling to review it
 84 2016-01-05 02:53:10 <dgenr8> they must not want it that much if they won't try it
 85 2016-01-05 02:53:36 <rusty> On a slightly-related note, is full-RBF privacy compromising if you use it naively to just bump the fee?  So either you need to ask the vendor for a new address, or add another input and output?
 86 2016-01-05 02:54:23 <morcos> privacy compromising b/c it gives away which is your change?
 87 2016-01-05 02:55:18 <rusty> morcos: yeah... seems like you you need to use if in FSS mode, or get a new address.
 88 2016-01-05 05:22:34 <rusty> aj: I'll wait then.  Your table on rates was actually more germane to the feeraate conversation though
 89 2016-01-05 05:27:57 <aj> rusty: hmm, i dumped my mempool to disk when i shutdown bitcoind the other day to run bitcoin-iterate. looking at the dump file, i've got 16k transactions (~90%) that are between 10kB and 30kB in size (20kB/58kB in hex encoding). real txes? spam? a covert communications channel made up of txes that will never confirm?
 90 2016-01-05 05:28:40 <rusty> aj: what's your minrelayfee?
 91 2016-01-05 05:29:03 <sipa> aj: i remember seeing behaviour of growing average txn in the mempool, when testing eviction
 92 2016-01-05 05:29:33 <sipa> aj: likely caused by more conplex transactions with many dependencies not being considered directly by miners
 93 2016-01-05 05:29:44 <sipa> so the smaller txn get confirmed faster
 94 2016-01-05 05:30:16 <aj> rusty: looks like i have it set at 100 satoshi (!)
 95 2016-01-05 05:31:07 <rusty> aj: the network thanks you...
 96 2016-01-05 05:31:18 <aj> rusty: does it though? :)
 97 2016-01-05 05:32:14 <rusty> aj: sure, you can collect all the gratitude you deserve, via reddit!
 98 2016-01-05 05:38:08 <aj> oh wow, it's someone trying to sweep up dust from july still
 99 2016-01-05 05:51:12 <aj> and making a pretty good showing of it too... https://blockchain.info/address/135zDqhbNcmPk3gbyeJmH75yiLdVZechsK?sort=1&filter=2
100 2016-01-05 06:37:13 <qie> Hi ~
101 2016-01-05 08:06:34 <aj> jl2012: first segwit-enabled-soft-forking script improvement! nice!
102 2016-01-05 08:07:06 <jl2012> aj, I'm just writing for sipa
103 2016-01-05 08:10:19 <aj> jl2012: it's still cool!
104 2016-01-05 08:12:38 <aj> jl2012: the segwit bip still doesn't seem to have a limit on segregated sigops, but i'm guessing that's just because the "Other consensus critical constraints" section isn't filled in yet?
105 2016-01-05 08:13:10 <jl2012> aj, yes, sipa is working on that
106 2016-01-05 08:13:33 <jl2012> that section is reserved for these purposes
107 2016-01-05 09:00:02 <btcdrak> aj: ping
108 2016-01-05 11:35:12 <bedeho> when adding a data item to the bloom filter, the docs say that following setting all nHashNum bits, each byte of the filter is set to a little endian byte? what does this mean
109 2016-01-05 11:35:55 <bedeho> why would endianness even be relevant, bytes in the filter have no ordering relationship w.r.t. one another?
110 2016-01-05 11:36:14 <bedeho> by docs I mean: https://bitcoin.org/en/developer-reference#filterload
111 2016-01-05 13:09:01 <nederhoed> hello there, testnet has become a nightmare, someone is mining without processing transactions, our test applications are getting stalled
112 2016-01-05 13:09:14 <nederhoed> http://tbtc.blockr.io/block/list/
113 2016-01-05 13:09:28 <nederhoed> we've tried running counterparty on testnet in box, but did not succeed
114 2016-01-05 13:10:01 <nederhoed> can anyone explain why someone is mining on testnet this way?
115 2016-01-05 15:32:32 <D4CH> Would it be possible to run bitcoin core (to help the network) on a raspberry pi, and with the blockchain located on a NAS?
116 2016-01-05 15:32:46 <D4CH> Or is this the wrong place to ask?
117 2016-01-05 15:33:46 <instagibbs> run it to help yourself secure your money and privacy, not the network, and #bitcoin :P
118 2016-01-05 15:37:04 <D4CH> Aye, but is my solution plausible?
119 2016-01-05 15:53:42 <D4CH> I have bitcoin core running now, how do I prune database? My DB is 60 GB
120 2016-01-05 15:54:24 <instagibbs> #bitcoin <-- that way
121 2016-01-05 17:20:15 <Lightsword> does core currently support intel sse optimized sha256 instructions etc?
122 2016-01-05 17:22:21 <sipa> no
123 2016-01-05 17:22:43 <Lightsword> sipa, is that something that would help much?
124 2016-01-05 17:23:01 <sipa> no
125 2016-01-05 17:23:04 <sipa> :)
126 2016-01-05 17:23:12 <sipa> we don't spend much time hashing
127 2016-01-05 17:24:36 <Lightsword> sipa, are there any architecture specific instruction sets that provide any benefit for other operations core does?
128 2016-01-05 17:25:16 <Lightsword> sipa, one reason I’m asking is for building pool servers
129 2016-01-05 17:25:35 <Lightsword> if I should be looking for anything special cpu wise
130 2016-01-05 17:27:51 <Lightsword> I’ve heard that one private fork of bitcoind is using arch specific instruction sets
131 2016-01-05 17:27:57 <Lightsword> for mining
132 2016-01-05 17:28:15 <sipa> bitcoind doesn't mine...
133 2016-01-05 17:28:21 <Lightsword> sipa, I mean for pool servers
134 2016-01-05 17:28:28 <Lightsword> for improved validation speeds
135 2016-01-05 17:28:38 <sipa> i know too little about pool software to comment
136 2016-01-05 17:28:46 <Lightsword> sipa, I mean on the bitcoind side of things
137 2016-01-05 17:29:38 <Lightsword> the patchset was to bitcoind itself apparently
138 2016-01-05 17:29:39 <sipa> most of the work of bitcoind when used for powering a pool is getblocktemplate
139 2016-01-05 17:29:58 <sipa> in 0.12 GBT is made spectacularly faster
140 2016-01-05 17:31:07 <Lightsword> yeah, that was apparently also rewritten for the private fork based off of 0.11.2 to the point that validation speeds were becoming a good percentage of that bottleneck
141 2016-01-05 17:31:19 <sipa> validation?
142 2016-01-05 17:31:24 <Lightsword> block validation
143 2016-01-05 17:31:45 <sipa> there is only one block to be validated every 10 minutes
144 2016-01-05 17:31:58 <sipa> oh, do you mean TestBlockValidity in GBT?
145 2016-01-05 17:32:20 <sipa> in 0.12 almost all the GBT work is in testblockvalifity
146 2016-01-05 17:32:22 <Lightsword> performance only matters for the incoming block that happens every 10 minutes
147 2016-01-05 17:32:36 <sipa> switch to 0.12 then
148 2016-01-05 17:32:48 <sipa> it's 5-7 faster for block validation
149 2016-01-05 17:32:59 <Lightsword> is 0.12 safe for mining yet?
150 2016-01-05 17:33:17 <sipa> there will be an rc1 soon
151 2016-01-05 17:33:51 <Lightsword> but yeah, regular GBT poll performance doesn’t really matter, those can take as long as they want, it’s only the first GBT call on blockchange that matters
152 2016-01-05 17:34:01 <sipa> ok
153 2016-01-05 17:34:39 <Lightsword> ok, so rc1 is reasonably safe to run in production environments? I would still have a backup node as well of course that the pool would fail over to
154 2016-01-05 17:36:55 <Lightsword> sipa, and secp256k1 just needs fast clock speeds right? no specific instruction sets?
155 2016-01-05 18:11:22 <jtimon> sipa: doesn't libsecp256k1 use some assembly for signature validation?
156 2016-01-05 18:12:26 <jtimon> optionally or something? I guess no for multi-platform consensus
157 2016-01-05 18:13:56 <jtimon> mhmm, I've been thinking lately about GPGPU for parallelizing signature validation, I hadn't thought about openCL/CUDA being compiled differntly and how that could potentially break consensus...
158 2016-01-05 18:38:12 <flozon_> hey guys, on the german bitcoin wiki it says you need ninja, truster or trusted status to contribute
159 2016-01-05 18:38:18 <flozon_> but it doesnt say anything on how to get that status
160 2016-01-05 18:40:22 <sipa> Lightsword: libsecp256k1 has assembly optimized for x86_64 intel/amd cpus
161 2016-01-05 18:40:33 <sipa> Lightsword: and perhaps soon for ARM
162 2016-01-05 18:40:40 <sipa> but they're not used in Bitcoin
163 2016-01-05 18:41:21 <Lightsword> sipa, the x86_64 assembly is generic though right, not specific to intel or amd?
164 2016-01-05 18:42:08 <sipa> Lightsword: indeed, no special instruction sets
165 2016-01-05 18:42:18 <Lightsword> so for signature validation I just want faster clocks in general right? throwning more cores into the mix won’t really help much right?
166 2016-01-05 18:43:26 <Lightsword> throwing*
167 2016-01-05 18:47:26 <sipa> yes it will
168 2016-01-05 18:47:39 <sipa> signature validation in blocks is muktithreaded
169 2016-01-05 18:49:26 <jtimon> I suspect the "special instruction set" is SSE2 (wich is supported by both intel and amd)
170 2016-01-05 18:49:52 <jtimon> I see, so it's there but not used for bitcoin, makes sense
171 2016-01-05 18:52:36 <Lightsword> sipa, well beyond a certain amount of cores I mean, say does upping from 12 cores to 24 cores make much difference
172 2016-01-05 18:53:20 <jtimon> now that I think about it, I doubt multi-core CPUs have multiple XMM coprocesors, so the threaded validation in bitcoin core could actually get worse by turning the SSE2 optimizations on!
173 2016-01-05 18:54:05 <Lightsword> what about newer instruction sets like SSE4?
174 2016-01-05 18:55:10 <jtimon> I think it should, if I understand the code correctly, you validate the whole block without the signatures and then schedule all the scripts for threaded validation ConncetBlock() -> CheckInputs()
175 2016-01-05 18:55:22 <jtoomim> jtimon: they do have multiple XMM coprocessors, at least for intel
176 2016-01-05 18:55:46 <jtoomim> AMD tends to have some stuff shared between pairs of processors in their recent architectures
177 2016-01-05 18:55:54 <Lightsword> jtimon, sig validation typically shouldn’t be as big an issue for blockchanges because of sigcache though right?
178 2016-01-05 18:56:11 <jtimon> sure, I guess they will use newer sets, I used SSE with MMX and SSE2 with XMM, but of course that must have keep on advancing
179 2016-01-05 18:56:12 <jtoomim> it's either FPU/SSE or integer that's shared, can't remember which
180 2016-01-05 18:56:37 <jtimon> jtoomim: I didn't know
181 2016-01-05 18:56:55 <jtoomim> but yeah, intel cores are all completely independent (ignoring hyperthreading)
182 2016-01-05 18:57:07 <jtoomim> the only thing intel shares is cache and memory
183 2016-01-05 18:57:28 <jtimon> IIRC FPU and SSE both use the XMM coprocessors, so they're "incompatible" in that sense (you can't use both simultanously)
184 2016-01-05 18:57:57 <jtoomim> in x86_64, the FPU registers are deprecated
185 2016-01-05 18:58:08 <jtoomim> and you actually use SSE2 code for regular FPU stuff, IIRC
186 2016-01-05 18:58:21 <jtoomim> no FPU stack, or something like that
187 2016-01-05 18:58:31 <jtoomim> but 32-bit still has the FPU stack
188 2016-01-05 18:58:47 <jtoomim> XMM is the prefix for the register
189 2016-01-05 18:58:58 <jtoomim> there's not really such a thing as an XMM coprocessor
190 2016-01-05 18:59:07 <jtoomim> it's just a different section of the same Core
191 2016-01-05 18:59:10 <jtoomim> different execute engines
192 2016-01-05 18:59:48 <jtoomim> but usually the execution engines are split into integer, load/store, and FPU/SSE/AVX
193 2016-01-05 18:59:54 <jtimon> well, XMM is the machine, FPU/SSE2 are the two intructions set you can run on the machine (or at least it was like this in SSE2 times)
194 2016-01-05 19:00:04 <jtoomim> so the FPU/SSE/AVX/MMX unit also does integer math in vectorized operations
195 2016-01-05 19:00:50 <jtimon> yep, XMM is basically a vectorial architecture (did I translate this correctly?), GPUs have that too
196 2016-01-05 19:00:51 <jtoomim> XMM is just a register naming scheme. XMM0 through XMM7 for original SSE
197 2016-01-05 19:01:10 <jtoomim> with 8 more added in 64 bit SSE
198 2016-01-05 19:02:30 <jtoomim> so you have some instructions that operate on those XMM registers, and other instructions that operate on the original x86 gen purpose registers like eax, ebx etc
199 2016-01-05 19:02:34 <jtimon> my teacher called the co-processor containing the XMM registries an "XMM co-processor"
200 2016-01-05 19:02:43 <jtoomim> i don't like your teacher
201 2016-01-05 19:02:50 <jtimon> "64 bit SSE" you mean SSE2
202 2016-01-05 19:03:06 <jtoomim> no, i mean SSE2's implementation on x86_64
203 2016-01-05 19:03:41 <jtimon> well, it is actually a separate machine from the "main" processor (or at least it used to be) as said it has quite a different architecture
204 2016-01-05 19:04:06 <jtoomim> the Athlon 64 was the first x86_64 CPU, and also the first CPU to add SSE2 to AMD's line, so it's mostly equivalent
205 2016-01-05 19:04:23 <jtimon> or at least that was the case for the pentium MMX and the first CPUs with 64 bits and XMM
206 2016-01-05 19:04:53 <jtoomim> > actually a separate machine -- I do not agree, it's the same module that runs FPU code
207 2016-01-05 19:05:05 <jtoomim> and people don't describe the FPU as being a co-processor any more
208 2016-01-05 19:05:23 <jtoomim> not since it was merged onto the same silicon die for everything, and began using the same decoder engine, etc
209 2016-01-05 19:05:59 <jtoomim> most modern CPUs actually have multiple execution units of each type, but with slightly different capabilities
210 2016-01-05 19:06:36 <jtoomim> for example, a CPU might have one FPU execution unit that can only do multiplies and adds, and another FPU execution unit that can do division, sqrt, SSE, etc
211 2016-01-05 19:08:45 <jtoomim> https://bbgsmc.files.wordpress.com/2014/02/intel-dual-core.jpg
212 2016-01-05 19:09:56 <jtoomim> the FPU also does integer SSE/mmx stuff, so you can theoretically get better integer performance by combining integer SSE and regular ALU integer math
213 2016-01-05 19:10:12 <jtimon> but regular processors are SISM and the XMM co-processor is SIMD, no?
214 2016-01-05 19:10:24 <jtoomim> no
215 2016-01-05 19:10:32 <jtoomim> regular processors have some SISM and some SIMD instructions
216 2016-01-05 19:10:56 <jtoomim> the SIMD instructions were added more recently
217 2016-01-05 19:11:00 <jtimon> not even MMX was a separate co-processor?
218 2016-01-05 19:11:06 <jtoomim> but they share execution units
219 2016-01-05 19:11:09 <jtoomim> even MMX
220 2016-01-05 19:11:18 <jtoomim> nothing since the old x87 FPUs were a coprocessor
221 2016-01-05 19:11:31 <jtoomim> MMX was an instruction set extension
222 2016-01-05 19:11:37 <jtimon> mhmm, I wonder where he got that from then
223 2016-01-05 19:11:37 <jtoomim> which came with register extensions
224 2016-01-05 19:12:51 <jtimon> anyway, intersting talk, but I need to go
225 2016-01-05 19:16:48 <flozon_> anyone that can help here to get the account verified in the wiki?
226 2016-01-05 19:17:07 <flozon_> for all but the english versions of the wiki it says one needs truster,trusted or ninja status
227 2016-01-05 19:17:55 <pigeons> i think the channel is #bitcoin-wiki to request access
228 2016-01-05 19:18:31 <pigeons> yep
229 2016-01-05 19:41:10 <flozon_> thx
230 2016-01-05 19:42:49 <TD-Linux> for future reference re instruction sets: http://www.agner.org/optimize/microarchitecture.pdf
231 2016-01-05 20:09:18 <arubi> a bit silly question maybe, why when verifying the chain, does the client verifies it from the earliest block to the tip? if so, why not backwards?  the tip points to the block with <that> hash before it, and so on.  ask the node connected to you for the previous block that has <this> hash, and check pow.  upon hearing about two different possible parents, check both paths and quickly(?) decide which path has most work. is checking for the best
232 2016-01-05 20:09:18 <arubi> chain a sane thing to do backwards?
233 2016-01-05 20:09:54 <belcher> arubi how do you know you've started from the genesis block then ?
234 2016-01-05 20:10:11 <arubi> not started, got to.  genesis is hard coded
235 2016-01-05 20:10:20 <arubi> but no checkpoints.. I think.
236 2016-01-05 20:10:49 <sipa> arubi: you can't verify backwards
237 2016-01-05 20:10:58 <sipa> arubi: as you don't have the outputs being spent yet
238 2016-01-05 20:11:12 <arubi> oh, I understand.
239 2016-01-05 20:11:22 <arubi> thanks, I completely dismissed it.
240 2016-01-05 20:47:07 <arubi> er, sipa, though it would still require more than the network's hash power to create a longer _and_ valid competing chain up to genesis, wouldn't it?  at which point you might as well follow that?
241 2016-01-05 20:48:11 <sipa> arubi: yes, so?
242 2016-01-05 20:48:20 <sipa> arubi: to be able to see it is valid, you need to verify it
243 2016-01-05 20:48:53 <arubi> sipa, I guess with 'current' definition of 'valid' you'd have to check for proper outputs
244 2016-01-05 20:49:50 <sipa> arubi: script validation
245 2016-01-05 20:50:06 <sipa> you can't do script validation without knowing the outputs being spent
246 2016-01-05 20:50:17 <sipa> and you can't check for fee/subsidy constraints
247 2016-01-05 20:51:01 <arubi> sipa, what can't you check for exactly with script validation that is not given with this specific block?
248 2016-01-05 20:51:31 <sipa> arubi: a txout says "spendably by pubkey X"
249 2016-01-05 20:51:40 <sipa> a txin says "here is a signature"
250 2016-01-05 20:51:49 <sipa> you need to know what X is to verify whether the signature is valid
251 2016-01-05 20:52:04 <arubi> oh, I see now.  right.
252 2016-01-05 20:52:06 <sipa> but the output being spent is usually in an earlier block
253 2016-01-05 20:52:25 <arubi> yea, scriptpubkey is not given
254 2016-01-05 20:52:35 <sipa> nor can it be given
255 2016-01-05 20:52:41 <sipa> you'd still need to check that it matches
256 2016-01-05 20:53:02 <arubi> right.  there's no way to tell.
257 2016-01-05 20:53:52 <arubi> thanks again.
258 2016-01-05 22:27:10 <mist_> heya guys, i'm trying to validate multisig addresses. the pubkey for bitcoin is 00, but what is it for multisig?
259 2016-01-05 22:27:57 <sipa> mist_: the pubkey for bitcoin is 00... what?
260 2016-01-05 22:28:10 <mist_> https://en.bitcoin.it/wiki/Base58Check_encoding
261 2016-01-05 22:28:15 <mist_> looking at the "Version bytes"
262 2016-01-05 22:28:18 <sipa> oh, the version byte
263 2016-01-05 22:28:22 <sipa> it's not a pubkey
264 2016-01-05 22:28:27 <sipa> addresses don't contain a pubkey
265 2016-01-05 22:28:41 <mist_> yeah sorry that was poorly formulated
266 2016-01-05 22:28:44 <sipa> there also does not actually exist a multisig address type
267 2016-01-05 22:28:54 <mist_> Argh...
268 2016-01-05 22:29:02 <mist_> So how would i go about validating it then? =/
269 2016-01-05 22:29:02 <sipa> only a P2SH address type which supports any type of script
270 2016-01-05 22:29:33 <sipa> mist_: 5, as said on that page
271 2016-01-05 22:29:44 <sipa> Bitcoin script hash
272 2016-01-05 22:29:53 <mist_> ohh
273 2016-01-05 23:01:09 <petertodd> arubi, sipa: you can verify it backwards, in fact I proposed that a few years ago as a way of transitioning from SPV to full node security
274 2016-01-05 23:03:37 <sipa> petertodd: by caching the scriptSigs, and then verifying them when you encounter the output spent by it?
275 2016-01-05 23:03:46 <petertodd> sipa: yup
276 2016-01-05 23:04:23 <sipa> that does require more memory than going forward, though
277 2016-01-05 23:04:26 <sipa> for that cache
278 2016-01-05 23:04:30 <sipa> i think?
279 2016-01-05 23:05:05 <petertodd> sipa: probably a wash, and the security is probably a bit better sooner
280 2016-01-05 23:06:04 <petertodd> sipa: though I doubt anyone's going to write the code to do that anytime soon :)
281 2016-01-05 23:06:48 <sipa> petertodd: saying so probably does not help making that happen