1 2015-12-28 00:09:11 <Lyth0s> can any of you smart guys help me estimate bitcoin mining hashes/second into FLOPS?
  2 2015-12-28 00:09:32 <sipa> it's easy: 0
  3 2015-12-28 00:09:42 <sipa> bitcoin mining does not use any floating point operations
  4 2015-12-28 00:10:05 <sipa> so measuring it in FLOPS (which is floating point operations per second) is meaningless/0
  5 2015-12-28 00:11:10 <Lyth0s> didn't gmaxwell recently publish some sort of estimation of hashes to flops
  6 2015-12-28 00:11:13 <Lyth0s> in terms of processing power
  7 2015-12-28 00:11:31 <sipa> that would seriously surprise me
  8 2015-12-28 00:12:05 <sipa> bitcoin asics cannot do anything else, so for all intends and purposes, their FLOPS rating is 0
  9 2015-12-28 00:12:28 <sipa> and the other way around, using general purpose hardware (with nonzero FLOPS) will be pointless for bitcoin mining
 10 2015-12-28 00:13:13 <Lyth0s> im probably confusing things
 11 2015-12-28 00:13:29 <Lyth0s> is this article completely bullshit? http://www.coindesk.com/bitcoin-network-out-muscles-top-500-supercomputers/
 12 2015-12-28 00:14:47 <PRab> "Two, the estimates used to convert hashes to flops (resulting in about 12,700 flops per hash) date to 2011, before ASIC devices became the norm for bitcoin mining. ASICs don't handle flops at all, so the current comparison is very rough." is key
 13 2015-12-28 00:15:58 <Lyth0s> hmm so there is no way to compare supercomputers to bitcoin miners in terms of processing power then?
 14 2015-12-28 00:16:02 <Lyth0s> I know ASICS are specific
 15 2015-12-28 00:16:27 <Lyth0s> but what if you had a supercomputer try to mine bitcoins and you knew how many FLOPS it could do
 16 2015-12-28 00:16:45 <Lyth0s> wouldn't there be a good FLOPS:Hashes/sec ratio that would apply to most supercomputers?
 17 2015-12-28 00:17:06 <Lyth0s> or would the ratio not hold across multiple supercomputers?
 18 2015-12-28 00:17:31 <jcorgan> the ratio is meaningless; hashing is not a floating-point operation
 19 2015-12-28 00:17:38 <sipa> Lyth0s: there is no supercomputer in the world that could make a dent in the hashrate
 20 2015-12-28 00:18:47 <Lyth0s> sipa yeah I'm aware of that. I'd just like to be able to tell my buddies something like "The Bitcoin network has more processing power than the top x supercomputers in the world combined"
 21 2015-12-28 00:18:54 <Lyth0s> but I would need a good way to calculate that
 22 2015-12-28 00:19:03 <sipa> Lyth0s: it would be a total lie
 23 2015-12-28 00:19:09 <Lyth0s> yeah I see
 24 2015-12-28 00:19:16 <sipa> the bitcoin network has zero processing power that it relevant in that statement
 25 2015-12-28 00:19:36 <Lyth0s> well it does in mining bitcoins
 26 2015-12-28 00:19:45 <Lyth0s> application specific, but processing power none the less
 27 2015-12-28 00:19:55 <sipa> then you should express it in Watts
 28 2015-12-28 00:20:04 <sipa> as the computation itself is not comparable
 29 2015-12-28 00:20:08 <Lyth0s> I see
 30 2015-12-28 00:20:14 <Lyth0s> what about in transistors?
 31 2015-12-28 00:20:23 <Lyth0s> someone in #bitcoin was talking about that
 32 2015-12-28 00:20:56 <jcorgan> you seem determined to come up with a number when there isn't one.  just make one up then.
 33 2015-12-28 00:21:24 <Lyth0s> I'm determined to find a way to compare them, not the same as determined to make shit up
 34 2015-12-28 00:22:30 <sipa> ;;nethash
 35 2015-12-28 00:22:31 <gribble> 862223310.092
 36 2015-12-28 00:23:11 <sipa> if you need a catchy statement, tell them that if the Bitcoin network would be doing SHA-1 instead of SHA-256, at the current hashrate, it would be finding a collision in SHA-1 every 16 days
 37 2015-12-28 00:23:36 <sipa> (but that would also require a ton of memory to store and compare the hashes, beyond what is reasonable)
 38 2015-12-28 00:23:55 <Lyth0s> ok thanks for your help sipa
 39 2015-12-28 00:24:13 <Lyth0s> I think I like your idea about comparing wattage in looking at energy consumed
 40 2015-12-28 00:25:11 <Lyth0s> SHA-1 collisions is going to be way above the intellect level of the people I'm going to talk to
 41 2015-12-28 00:25:42 <sipa> how about this
 42 2015-12-28 00:25:52 <sipa> it computes a billion billion hashes per second
 43 2015-12-28 00:26:40 <jcorgan> how many library of congresses is that?
 44 2015-12-28 00:26:48 <MrHodl> lol
 45 2015-12-28 00:31:45 <Lyth0s> any predictions on when we will hit a yottahash? :O
 46 2015-12-28 00:32:58 <Lyth0s> we're going to need bigger SI prefixes
 47 2015-12-28 00:34:21 <sipa> no we won't
 48 2015-12-28 00:34:28 <sipa> not any time soon :)
 49 2015-12-28 00:34:45 <Lyth0s> 10 years?
 50 2015-12-28 17:06:38 <morcos> Are we proposing using ISM for segwit then and delaying version bits?
 51 2015-12-28 17:17:06 <phantomcircuit> morcos, ism?
 52 2015-12-28 17:27:50 <Luke-Jr> morcos: frankly, I prefer BIP16-style over ISM :/
 53 2015-12-28 17:31:33 <morcos> phantomcircuit: IsSuperMajority?
 54 2015-12-28 17:33:03 <sipa> morcos: not decided, i just need code that works now for a testnet
 55 2015-12-28 17:33:12 <sipa> deployment can easily be changed to something else later
 56 2015-12-28 17:33:32 <sipa> Luke-Jr: as in: time based?
 57 2015-12-28 17:33:47 <Luke-Jr> sipa: tag in coinbase
 58 2015-12-28 17:36:11 <sipa> heh
 59 2015-12-28 17:37:27 <Luke-Jr> otoh, maybe it's better than every software needs to update (eg, Eloipool, BFGMiner) with SegWit
 60 2015-12-28 17:38:40 <jl2012> sipa: I left some comments for the commitment validation but seems they are gone after you refresh the branch
 61 2015-12-28 17:39:09 <sipa> yeah, always comment on the PR, not on individual commits
 62 2015-12-28 17:39:33 <jl2012> i'm still new to github
 63 2015-12-28 17:39:33 <sipa> Luke-Jr: all software that selects its own transactions will need to uodate
 64 2015-12-28 17:39:42 <sipa> (or of course, reject segwit)
 65 2015-12-28 17:40:17 <jl2012> are segwit tx now nonstandard?
 66 2015-12-28 17:40:28 <Luke-Jr> sipa: yes, the last 2 or 3 softforks had no need for it though
 67 2015-12-28 17:40:34 <Luke-Jr> it was merely bumping a number in the code
 68 2015-12-28 17:40:56 <Luke-Jr> jl2012: basically nothing is nonstandard now
 69 2015-12-28 17:41:04 <Luke-Jr> non-IsStandard*
 70 2015-12-28 17:41:56 <jl2012> do we need to turn it into non-IsStandard? like BIP113?
 71 2015-12-28 17:42:10 <sipa> Luke-Jr: they are efectively non-standard currently, due to the superfluous pushes rule
 72 2015-12-28 17:42:23 <sipa> (enforced via a script flag, not via isstansard)
 73 2015-12-28 17:42:47 <Luke-Jr> sipa: oh? I thought that only checked superfluous pushes in scriptSig, not scriptPubKey?
 74 2015-12-28 17:42:58 <Luke-Jr> otoh, I guess it would be difficult to differentiate
 75 2015-12-28 17:43:13 <sipa> Luke-Jr: there is a push-only rule for scriptSig
 76 2015-12-28 17:43:18 <morcos> sipa
 77 2015-12-28 17:43:28 <morcos> oops.  sipa: is there a PR somehwere
 78 2015-12-28 17:43:36 <sipa> and there is a only-one-element-on-the-stack-after-evaluation rule
 79 2015-12-28 17:43:41 <morcos> i was just reading through your branch and was wondering if you wanted comments and where to give them
 80 2015-12-28 17:43:54 <sipa> morcos: oh, there is no PR yet, of course
 81 2015-12-28 17:43:58 <Luke-Jr> sipa: is that not the case for SegWit?
 82 2015-12-28 17:44:01 <sipa> there will be one this year
 83 2015-12-28 17:44:12 <jl2012> a native witness program is a single push in scriptPubKey, so there is no superfluous push
 84 2015-12-28 17:44:21 <sipa> ha!
 85 2015-12-28 17:44:24 <sipa> good point
 86 2015-12-28 17:44:40 <jl2012> same for P2SH, i guess
 87 2015-12-28 17:45:50 <sipa> P2SH is older than the cleanstack rule
 88 2015-12-28 17:46:09 <sipa> and, no segwit will fail cleanstack
 89 2015-12-28 17:46:21 <sipa> unless its execution stack is empty
 90 2015-12-28 17:46:39 <sipa> which would imply an anyonecanspend (even post segwit)
 91 2015-12-28 17:47:32 <sipa> nvm
 92 2015-12-28 17:47:34 <sipa> i'm confused
 93 2015-12-28 17:48:21 <jayd3e> why can't I find main() anywhere in init.cpp?
 94 2015-12-28 17:48:35 <sipa> it's in bitcoind.cpp
 95 2015-12-28 17:48:46 <sipa> (also, #bitcoin-core-dev for that)
 96 2015-12-28 17:49:20 <morcos> sipa: so should i hold off on nit level code comments for now then?  and if not, where would you like them
 97 2015-12-28 17:49:22 <jayd3e> kk cool
 98 2015-12-28 17:49:55 <sipa> jl2012: so, you're right; this is annoying
 99 2015-12-28 17:54:29 <sipa> jl2012: making witness programs use an opcode is one way (though adds an unnecessary byte)
100 2015-12-28 17:55:05 <jl2012> what is the biggest problem with not making it nonstandard?
101 2015-12-28 17:56:46 <Luke-Jr> jl2012: the code is already out there..
102 2015-12-28 17:57:14 <Luke-Jr> sipa: the version could be a separate push.. that doesn't inflate it until we get past some version number
103 2015-12-28 17:57:41 <sipa> Luke-Jr: that seems reasonable
104 2015-12-28 17:57:50 <sipa> it's also more flexible
105 2015-12-28 18:01:10 <jl2012> so v17 or above will take one more byte. When we reach that number, and if we really want to save a byte, we can switch back to the current format with softfok
106 2015-12-28 18:01:40 <jl2012> Luke-Jr: excellent!
107 2015-12-28 18:02:45 <Luke-Jr> hopefully we'll have hardforked by then anyway
108 2015-12-28 18:04:11 <jl2012> even a hardfork may not fix a problem like this, to minimize the impact on SPV nodes
109 2015-12-28 18:07:13 <veyor> Hey all! I’m newish to exploring BitCoins in general (still need to setup a wallet), fascinated with the live transaction data. I’d love to showcase transactions being “solved” or unverified as they hit around the world on a web page (also helps me learn this stuff). Is blockchain.info the preferred API for tapping into the live data? Any other alternatives you enjoy (or do I need to make my own?)
110 2015-12-28 18:07:49 <sipa> veyor: this channel is for development of bitcoin's protocol and implementation itself
111 2015-12-28 18:08:07 <veyor> aha. I’m sorry about that. I’ll move this conversation. Have a great day
112 2015-12-28 18:08:29 <jl2012> it's unlikely to reach v17 in 10 years, anyway. New script system should include OP_RETURNTRUE, which allow softfork of any new OP codes. So we don't need a new script version for every new code: https://bitcointalk.org/index.php?topic=1106586.0
113 2015-12-28 18:08:57 <sipa> jl2012: alternatively, we can introduce version bytes inside the witness script too
114 2015-12-28 18:09:27 <sipa> veyor: though in general people here will frown upon using a centralized service for such data, as you can just run a bitcoind yourself, and get the verified data directly from the p2p network
115 2015-12-28 18:09:50 <sipa> jl2012: so, agree
116 2015-12-28 18:10:00 <sipa> Luke-Jr: thanks for that suggestion; will implement
117 2015-12-28 18:10:17 <jl2012> sipa: ok.....so basically it's infinity. Luke-Jr is Bitcoin script ninja
118 2015-12-28 18:10:26 <veyor> thanks for that. “bitcoind” is the magic word of the day. :D
119 2015-12-28 18:26:22 <jl2012> sipa: just in theory: with the version byte separated, if the hash of a v1 witness program is all-0, it becomes invalid
120 2015-12-28 18:26:45 <sipa> jl2012: i'm perfectly fine with that :)
121 2015-12-28 18:28:14 <jl2012> just to confirm: the script engine will first validate with existing semantic, and only if it passes, it will move on to SW semantic
122 2015-12-28 18:30:02 <sipa> yup
123 2015-12-28 18:30:13 <sipa> the SW logic only introduces new "return false"s
124 2015-12-28 20:17:10 <morg> Increase the blocksize!