1 2014-11-25 00:19:10 <discreteunit> I wonder whether there's been any discussion around the expected Intel SHA Extensions and their impact on Bitcoin Core, if any?
  2 2014-11-25 00:19:40 <phantomcircuit> discreteunit, effectively zero
  3 2014-11-25 00:19:47 <phantomcircuit> maybe some trivial speed up to verification
  4 2014-11-25 00:21:04 <discreteunit> Is there currently an effective forum for such a conversation?
  5 2014-11-25 00:21:21 <phantomcircuit> you're in it
  6 2014-11-25 00:25:26 <discreteunit> Even CodePlex discussion boards seem preferable to IRC in this context...
  7 2014-11-25 00:29:47 <CodeShark> SHA is not really the bottleneck in Bitcoin Core
  8 2014-11-25 00:29:58 <CodeShark> I/O and ECDSA are much bigger bottlenecks
  9 2014-11-25 00:32:39 <discreteunit> I wonder about it more from a communication perspective. I am not aware of a comparable offering on GitHub, and the SourceForge mailing lists would seem to be a cumbersome reference point at best.
 10 2014-11-25 00:33:42 <CodeShark> sha optimization only has a significant effect on mining - but even with the SHA extensions, CPU mining cannot compete with ASICs
 11 2014-11-25 00:35:07 <CodeShark> CPU optimization on SHA would only matter if the result of SHA calculations had frequent effects on execution path
 12 2014-11-25 00:35:29 <CodeShark> which for bitcoin they do not
 13 2014-11-25 00:35:54 <CodeShark> *for bitcoin mining
 14 2014-11-25 00:36:11 <discreteunit> Undoubtedly so, but this reasoning needs visibility and a feedback loop.
 15 2014-11-25 00:39:35 <CodeShark> a simple calculation - how many sha operations does Bitcoin Core need to perform per second on average?
 16 2014-11-25 00:39:50 <discreteunit> One might argue that the same goes for Gavin's Scalability Roadmap. The Foundation's blog posts offer no commenting functionality.
 17 2014-11-25 00:40:22 <CodeShark> every network message requires a sha256 checksum, every transaction requires hashing, every block header requires hashing
 18 2014-11-25 00:41:16 <CodeShark> but a transaction only requires two sha256 operations to obtain the tx hash and requires a sha256 and a ripemd160 operation to compute pubkey and script hashes
 19 2014-11-25 00:41:30 <CodeShark> so about one per spent output
 20 2014-11-25 00:42:49 <CodeShark> and then another per signature
 21 2014-11-25 00:43:05 <CodeShark> so we're talking about no more than a few thousand sha256 operations per block
 22 2014-11-25 00:44:04 <CodeShark> I don't really think there's much further reasoning required :)
 23 2014-11-25 00:45:09 <CodeShark> to address scalability, the protocol itself will require some significant revamping
 24 2014-11-25 00:45:41 <discreteunit> There may or may not be for Intel SHA Ext. But my questions is broader and inquires about a framework for such discussions a la, say, https://roslyn.codeplex.com/discussions/topics/5998/c-language-design
 25 2014-11-25 00:45:50 <CodeShark> i.e. it's not really sensible for every single node to have to validate every single transaction for every single other node
 26 2014-11-25 00:47:06 <CodeShark> IRC leaves a lot to be desired, for sure
 27 2014-11-25 00:48:15 <discreteunit> Precisely. And GitHub isn't quite filling that void. Neither is SourceForge.
 28 2014-11-25 00:50:07 <CodeShark> you can always try your luck at bitcointalk :p
 29 2014-11-25 00:51:45 <gmaxwell> discreteunit: wrt the sha instructions; patches accepted. (well.. acceptance may be delayed since I could not test them yet. :) ).
 30 2014-11-25 00:52:39 <CodeShark> sha instructions are nice if you're dealing with massive throughput of messages
 31 2014-11-25 00:52:43 <gmaxwell> SHA256 isn't invsible in profiles by any means, ... and it'll get larger as we optimize other things. I expect the improvement to be relatively modest. Intels numbers sounded like they were only on the order of 4-6x faster than a most optimized 4-way SIMD sha256 implementation.
 32 2014-11-25 00:58:06 <Diablo-D3> gmaxwell: intel's sha instruction set?
 33 2014-11-25 00:58:11 <Diablo-D3> I thought it could only do sha1
 34 2014-11-25 01:01:21 <CodeShark> https://software.intel.com/en-us/articles/intel-sha-extensions claims it can do SHA256 as well
 35 2014-11-25 01:01:59 <CodeShark> three instructions for it
 36 2014-11-25 01:03:05 <kadoban> It'd be pretty weird if they were adding it now not to support sha-2
 37 2014-11-25 01:03:21 <CodeShark> what about sha-3? :)
 38 2014-11-25 01:04:33 <CodeShark> or even sha-512? :)
 39 2014-11-25 01:11:06 <gmaxwell> CodeShark: they do all of sha2.
 40 2014-11-25 01:53:44 <gmaxwell> CodeShark: yea, the assert(!"string") pattern is weird. :)
 41 2014-11-25 02:23:27 <Luke-Jr> gmaxwell: I presume it's why _Static_assert takes 2 arguments
 42 2014-11-25 02:52:39 <coderwill> hey all, quick noob BIP 32 question - if I know the word list on electrum or mycelium, i can install either on any device and I'll automatically gain access to my master seed and subsequent assigned to it?
 43 2014-11-25 02:53:08 <coderwill> subsequent BTC*
 44 2014-11-25 02:58:33 <netg> yeah, thats the plan
 45 2014-11-25 03:01:22 <phantomcircuit> coderwill, in theory yes, in practice probably, will it work 100% of the time? probably not
 46 2014-11-25 03:01:32 <phantomcircuit> will it work 99.999% of the time? probably
 47 2014-11-25 03:02:28 <CodeShark> word lists are not part of the BIP32 spec
 48 2014-11-25 03:06:09 <CodeShark> the master seed format is part of BIP32, but the way a wallet organizes the HD tree is not
 49 2014-11-25 03:14:11 <CodeShark> does electrum even use BIP32?
 50 2014-11-25 03:14:31 <CodeShark> oh, yes - it does have support for BIP32 accounts
 51 2014-11-25 03:15:10 <belcher> version 2.0 does
 52 2014-11-25 03:17:50 <flirtcoin> My goodness look at all the devs lol
 53 2014-11-25 03:23:55 <coderwill> thanks all for the feedback on my question
 54 2014-11-25 05:33:57 <abishek> anybody here have experience with bitpay integration?
 55 2014-11-25 05:34:24 <phantomcircuit> #bitcoin
 56 2014-11-25 08:02:01 <Luke-Jr> is this "ABISprotocol" person anyone to pay attention to?
 57 2014-11-25 08:06:05 <gmaxwell> I dread asking why
 58 2014-11-25 08:13:00 <Luke-Jr> gmaxwell: their comments on https://github.com/bitcoin/bitcoin/pull/5231#issuecomment-64320763
 59 2014-11-25 08:17:50 <Luke-Jr> (I'm inclined to ignore them)
 60 2014-11-25 08:17:55 <gmaxwell> Luke-Jr: may make more sense to just bring it up again later, jeff expressed a concern about some potential existing users.
 61 2014-11-25 08:18:11 <gmaxwell> Yes, I'd ignore but in any case, seems perhaps premature.
 62 2014-11-25 08:18:16 <gmaxwell> I wish we had an intermediate option.
 63 2014-11-25 08:22:24 <Luke-Jr> I suppose we could try the "refuse to mine unless a decision is made" path again.. dunno if anyone will go for that
 64 2014-11-25 08:23:42 <gmaxwell> bleh, nah. not worth it. just make the case for this again before the next release, perhaps backed up with some data.
 65 2014-11-25 08:31:11 <Diablo-D3> https://www.kickstarter.com/projects/1942805829/artison-rcc-nano
 66 2014-11-25 08:31:12 <Diablo-D3> man
 67 2014-11-25 08:31:25 <Diablo-D3> kickstarter is kind of a scam
 68 2014-11-25 08:31:33 <Diablo-D3> people fund projects no one gives a fuck about
 69 2014-11-25 08:31:39 <Diablo-D3> but shit like this? nope, no funding
 70 2014-11-25 08:34:54 <Luke-Jr> it's just a speaker, you can get those for like $50
 71 2014-11-25 08:35:20 <gwillen> Diablo-D3: I can't speak for everyone else, but I live in an apartment. "More bass" is anti-valuable to me.
 72 2014-11-25 08:35:47 <Luke-Jr> 
ACTION wonders if the Novena will be delivered Nov as planned :p

 73 2014-11-25 08:35:48 <Diablo-D3> gwillen: I live in an apartment
 74 2014-11-25 08:35:51 <Diablo-D3> Im still getting a sub
 75 2014-11-25 08:36:06 <gwillen> I like keeping the peace with my neighbors too much to get a subwoofer.
 76 2014-11-25 08:36:16 <Diablo-D3> I love my adam audio a3xes and all, but they mangle the audio on bass powerful tracks
 77 2014-11-25 08:36:24 <Diablo-D3> because, well, they can reproduce it.
 78 2014-11-25 08:36:32 <Diablo-D3> they're 4.5" woofers that go the whole way down to 60hz
 79 2014-11-25 08:36:42 <gmaxwell>  <- channel
 80 2014-11-25 08:36:59 <Diablo-D3> ^--- gmaxwell
 81 2014-11-25 08:37:21 <Diablo-D3> this was meant for #bitcoin anyways
 82 2014-11-25 08:41:23 <Diablo-D3> gwillen: the reason to get a sub is to take the load off your main speakers, btw
 83 2014-11-25 08:41:40 <Diablo-D3> if your sub is just a thud machine, your entire theatre setup is just broken
 84 2014-11-25 08:42:38 <Diablo-D3> and yes, a lot of el cheapo home theatre in a box setups have a thud machine for a sub
 85 2014-11-25 08:43:14 <Diablo-D3> sats with 3" mids, entire 5.1 set is like 300w
 86 2014-11-25 08:43:18 <Diablo-D3> whole thing is shit
 87 2014-11-25 10:46:34 <Diablo-D3> http://hitgub.com
 88 2014-11-25 10:53:30 <b_lumenkraft> hehe, that’s cute. :)
 89 2014-11-25 13:09:24 <runeks> Will there be any need for bootstrap.dat once bitcoind is able to do initial sync from multiple peers?
 90 2014-11-25 13:10:11 <Luke-Jr> runeks: unlikely
 91 2014-11-25 13:10:51 <runeks> Luke-Jr: Cool. I guess that's a good thing.
 92 2014-11-25 13:11:58 <sipa> runeks: git master is capable of that right now :)
 93 2014-11-25 13:12:43 <Luke-Jr> sipa: I suspect there may be corner cases *cough*rebroad*cough* that may work less well than the torrent right now? :P
 94 2014-11-25 13:12:58 <sipa> oh, i'm sure
 95 2014-11-25 13:13:30 <runeks> sipa: Cool. I guess I should start using that, so I can serve multiple peers at once.
 96 2014-11-25 13:13:44 <runeks> What's rebroad?
 97 2014-11-25 13:13:50 <sipa> runeks: every version ever could *serve* multiple peers at once
 98 2014-11-25 13:14:11 <sipa> it's just the fetching mechanism that couldn't synchronize from multiple peers at once
 99 2014-11-25 13:14:17 <runeks> Ah, I see.
100 2014-11-25 13:14:19 <Luke-Jr> runeks: rebroad is an occasional contributor to Bitcoin Core who has particularly broken internet connection
101 2014-11-25 13:14:38 <runeks> So master can sync from multiple peers that are running earlier versions of bitcoind?
102 2014-11-25 13:14:40 <Luke-Jr> so he's often trying to suggest some bad ideas that might make his node work better
103 2014-11-25 13:14:46 <wumpus> Luke-Jr: and computer
104 2014-11-25 13:14:49 <runeks> Luke-Jr: Ah
105 2014-11-25 13:14:55 <Luke-Jr> wumpus: ?
106 2014-11-25 13:15:23 <sipa> runeks: yes, from versions down to 0.3.18 :)
107 2014-11-25 13:15:42 <wumpus> Luke-Jr: well he also had some very strange behavior before which suggest his computer/install is broken too, but sure it may all be caused by the internet connection :-)
108 2014-11-25 13:15:46 <runeks> sipa: Cool. That's good news. I guess I don't have to update then.
109 2014-11-25 13:16:02 <Luke-Jr> wumpus: heh, why am I not surprised? :>
110 2014-11-25 13:16:04 <Luke-Jr> :P*
111 2014-11-25 13:17:11 <wumpus> on one hand, that works better to find problems than any fuzzer, on the other hand, the solutions he comes up with are usually meh
112 2014-11-25 16:45:06 <eric___> What does blockchain.info, blocktrail.com and chain.com have in common? For a particular address, they are all showing an incorrect recieved amount, with the exact same incorrect recieved amount
113 2014-11-25 16:46:08 <eric___> In fact, merely adding up blockchain.info’s own list of transactions, shows the correct total.
114 2014-11-25 16:46:42 <eric___> I’m having trouble reconsiling the fact that three supposedly independent sites exhibit the same bug
115 2014-11-25 16:54:06 <hearn> eric___: which address?
116 2014-11-25 16:55:32 <eric___> hearn: Ended up figuring it out. If the output address is in the list of the input address, all the above sites exclude it from being considered “total recieved”
117 2014-11-25 16:55:55 <eric___> Which is rather counter-intuitive behavior
118 2014-11-25 16:56:17 <eric___> The problematic transaciton was this one: https://blockchain.info/tx/c2c76704c6c5916d0a5e398d28f47d5df4e7d507917b04ad56eb378e98fcae44
119 2014-11-25 16:56:29 <eric___> Where 13ty… is in both the inputs and the outputs
120 2014-11-25 16:56:37 <eric___> So it doesn’t count toward the “total recieved”
121 2014-11-25 18:53:18 <maraoz> Does Bitcoin Core use the SCRIPT_VERIFY_LOW_S flag on by default to verify transactions? This test https://github.com/bitcoin/bitcoin/blob/ca6fb4e885c899e297e0a6fa723604a41f199aa6/src/test/script_tests.cpp#L415 seems to indicate it doesn't, but I'm not sure
122 2014-11-25 18:55:54 <gmaxwell> maraoz: it doesn't, not yet. Why?
123 2014-11-25 19:06:12 <maraoz> gmaxwell: thanks! just wanted to make sure current bitcore version is not generating invalid txs. I guess implementing BIP62 new rules is a good idea for a future release
124 2014-11-25 19:08:57 <gmaxwell> You should implement low S for all your transactions as soon as you easily can. But indeed, they're fine for the moment.
125 2014-11-25 19:12:02 <gmaxwell> since if there is another wave of mutant transactions miners may begin enforcing low-S as an IsStandard rule or some kind of priortiziation scheme for all transactions to stop the bleeding.
126 2014-11-25 19:19:19 <maraoz> gmaxwell: gotcha. We'll probably include the new BIP62 rules for the next major release in December
127 2014-11-25 19:20:59 <gmaxwell> Well the only thing I think you need to do right away is just the low-S signing. BIP62 isn't deployed yet, and the full thing involves v3 transactions which aren't relayed yet.