1 2015-10-07 00:43:31 <OxADADA> warren: where does the analysis live?
  2 2015-10-07 00:44:37 <warren> OxADADA: i'm asking if anyone know if this has been done before
  3 2015-10-07 00:45:12 <OxADADA> warren: ah
  4 2015-10-07 01:04:27 <alpalp> Is anyone aware of any attempts to build any kind of language or abstraction on top of Bitcoin Scripting?
  5 2015-10-07 02:54:04 <bedeho> can you use  if op code with p2sh ?
  6 2015-10-07 03:12:32 <CodeShark> bedeho: yes
  7 2015-10-07 03:13:26 <CodeShark> unless explicitly marked disabled, I think all the opcodes here can be used in p2sh: https://en.bitcoin.it/wiki/Script
  8 2015-10-07 03:57:59 <bedeho> CodeShark, so, is OP_AND actually illegal with p2sh?
  9 2015-10-07 03:59:47 <CodeShark> the most authoritative place to look is probably https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L238
 10 2015-10-07 05:57:20 <paveljanik> https://bitcoinfees.github.io/#30m - unusual amount of txs ~14788 bytes long...
 11 2015-10-07 06:07:24 <hardyred> Hi there quick question
 12 2015-10-07 06:08:18 <Luke-Jr> hardyred: #bitcoin if it isn't Bitcoin development
 13 2015-10-07 06:08:41 <hardyred> If it's a bitcoin development related question is it alright?
 14 2015-10-07 06:09:09 <Luke-Jr> then don't ask to ask.
 15 2015-10-07 06:11:07 <hardyred> Well if I am using JSON-RPC to connect with bitcoind to access Bitcoin's network (aka searching for information on TXIDs and whatnot) will I quickly run in to a scalability issue?
 16 2015-10-07 06:11:24 <hardyred> Like if I am using it for a public service with 1000+ people accessing it every hour
 17 2015-10-07 06:12:33 <hardyred> I am not planning on sending any transactions or generating any keys, just for transaction lookups
 18 2015-10-07 06:13:42 <paveljanik> hardyred, that would be a good test :-) you can play with rpcthreads. But generally RPC interface is not optimized for such use case. But you can help amking it better!
 19 2015-10-07 06:14:43 <paveljanik> first try to benchmark the service itself with e.g. ab2 - is it able to handle your workload?
 20 2015-10-07 06:15:18 <paveljanik> it is doable, but maybe osme finetuning is needed.
 21 2015-10-07 06:15:34 <hardyred> paveljanik: Will do and record results, I thought as being late to the party there might have been some information already out there that someone might have a reference to :p
 22 2015-10-07 06:16:22 <paveljanik> it is usually done in a different way though - bitcoind as a gateway to the network. Another DB level above it.
 23 2015-10-07 06:16:47 <hardyred> paveljanik: right, I believe most services import the blockchain to a db and then search it from there
 24 2015-10-07 06:16:53 <aj> paveljanik: "another db level above it" -- as in pull the block/txn info out of bitcoin once, put that in a db, and query the db?
 25 2015-10-07 06:17:42 <hardyred> Hey there sorry I was disconnected for a second paveljanik
 26 2015-10-07 06:17:46 <paveljanik> aj, this way or memcached level above it etc.
 27 2015-10-07 06:18:49 <aj> paveljanik: *nod* makes sense
 28 2015-10-07 06:20:12 <paveljanik> but I'd me very intereste in testing our RPC interface under such orkload directly.
 29 2015-10-07 06:20:13 <paveljanik> :-)
 30 2015-10-07 06:20:39 <paveljanik> ... I'd be very interested in...
 31 2015-10-07 06:20:54 <hardyred> paveljanik: I got nothing to do on thursday, I will run some benchmark tests and document how it does
 32 2015-10-07 06:21:24 <paveljanik> plese try bitcoin from master with libevent based web server...
 33 2015-10-07 06:22:09 <paveljanik> and test different values of rpcthreads
 34 2015-10-07 06:45:25 <paveljanik> back to the large mempool now - looks like another "stress test" and none noticed it yet... ;-)
 35 2015-10-07 08:22:08 <smellymoo> hey guys. I am making a VPN provider that only accepts bitcoin. I would like to know if it is possible to use bitcoind in "prune mode" to only notify me of valid transactions to certain addresses?
 36 2015-10-07 08:25:59 <smellymoo> the way I see it, prune mode verifies the POW chain (by only keeping the last 2) and stops double spend by keeping addresses that have an amount of bitcoin, and tracking that. rather than storing the ledger. right? so if bitcoind is in prune, it can notify you of all transactions as they get mined into a block, but not of previous transactions right?
 37 2015-10-07 08:36:56 <btcdrak> well amongst the noise, someone posted an absolutely gem to the mailing list: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html
 38 2015-10-07 08:43:36 <smellymoo> nice btcdrak :)
 39 2015-10-07 08:53:47 <smellymoo> any info? prune mode of bitcoind still allows you to listen (by an other program) to all valid new transactions to certain addresses, right? (can't see why it wouldn't).
 40 2015-10-07 09:51:00 <dcousens> bah
 41 2015-10-07 09:51:34 <smellymoo> wow, is like anyone actually here?
 42 2015-10-07 09:51:45 <dcousens> haha
 43 2015-10-07 09:55:56 <stonecoldpat> smellymoo: according to release notes, it keeps the previous 288 blocks (2 days worth), so it will let you know about new transactions, but wallet functions are disabled by default (according to July release statement)
 44 2015-10-07 09:57:09 <smellymoo> stonecoldpat, thanks :). I read that, I am just verifying. so if I use it in prune, I will be fine to check the last few blocks, great!
 45 2015-10-07 09:58:07 <smellymoo> stonecoldpat, so final question... if you want to implement a client, with a pre-downloaded copy of the pruned block-chain, that would work right?
 46 2015-10-07 10:01:08 <stonecoldpat> smellymoo: what do you mean by client? it depends on your assumptions i guess, the idea for a pruned node is to 1) download everything and 2) discard what it no longer needs, if you already supply the fully pruned node, then the receiver needs to trust that the first step happened.
 47 2015-10-07 10:09:28 <smellymoo> well, just copy the directory that has a full sych then pruned, into another bitcoind folder.
 48 2015-10-07 10:09:38 <smellymoo> I mean the folder that keeps the index.
 49 2015-10-07 10:10:34 <stonecoldpat> i dont see why it wouldnt work (ive never tried)
 50 2015-10-07 10:12:02 <smellymoo> so all the archive of the chain is in one dir, if I make a copy of that, then place it in a new one, it will by syched up until the new point, with no download. Think that should work.
 51 2015-10-07 10:13:58 <stonecoldpat> give it a shot and let me know :) if you copy the blockchain, chainstate and database files it should be okay
 52 2015-10-07 10:20:27 <smellymoo> thanks mate :)
 53 2015-10-07 10:52:55 <ThomasKeller> I have just subscribed to the bitcoin-dev mailing list
 54 2015-10-07 10:53:10 <ThomasKeller> most of the emails in the list are sent by somebody named Venzen Khaosan, who keeps insulting people
 55 2015-10-07 10:53:17 <ThomasKeller> who is this person and why is he so rude ?
 56 2015-10-07 10:54:09 <ThomasKeller> is this normal tone in the list ?
 57 2015-10-07 10:55:37 <stonecoldpat> ThomasKeller: its not normal. generally most of the topics talk about research or development for bitcoin, just lately its getting the wrong attention
 58 2015-10-07 11:11:06 <midnightmagic> Geez. What's with the huge noise ratio on the dev list.
 59 2015-10-07 11:45:41 <btcdrak> trolling for review/ACKs on "Softfork Units" https://github.com/bitcoin/bitcoin/pull/6747
 60 2015-10-07 11:47:41 <btcdrak> ThomasKeller, it will all change soon once we get bitcoin-discuss setup.
 61 2015-10-07 14:16:42 <gribble> I have not seen schildbach.
 62 2015-10-07 14:16:42 <ThomasV> !seen schildbach
 63 2015-10-07 14:16:47 <ThomasV> !seen aschildbach
 64 2015-10-07 14:16:48 <gribble> aschildbach was last seen in #bitcoin-dev 11 weeks, 6 days, 3 hours, 40 minutes, and 8 seconds ago: <aschildbach> How's the TOA?
 65 2015-10-07 17:34:53 <OxADADA> is there documentation surrounding the decision to hash the proof-of-work with SHA256d instead of vanilla SHA256?
 66 2015-10-07 17:40:19 <Luke-Jr> OxADADA: before or after the fact? :P
 67 2015-10-07 17:41:01 <OxADADA> Luke-Jr: either, i'm just curious what properties of d are better than vanilla SHA256
 68 2015-10-07 17:42:29 <Luke-Jr> miners have effectively reduced SHA256d down to a single SHA256 at this point, so yes
 69 2015-10-07 17:49:40 <OxADADA> Luke-Jr: so Yes: SHA256d is in-practice no better a choice than SHA256.
 70 2015-10-07 17:52:15 <Luke-Jr> OxADADA: no, because if it had been just one SHA256, it'd be nothing left
 71 2015-10-07 17:52:47 <OxADADA> Luke-Jr: so search space is much larger.
 72 2015-10-07 18:28:18 <berndj> Luke-Jr, wait, wat? i know you can skip or reduce the last 5 rounds or so, but reducing sha256d to sha256??
 73 2015-10-07 18:28:36 <Luke-Jr> berndj: also remove the start with midstate
 74 2015-10-07 18:28:53 <Luke-Jr> so you skip half the first one, and half the last one
 75 2015-10-07 18:28:57 <Luke-Jr> approx
 76 2015-10-07 18:28:58 <berndj> Luke-Jr, oh, but starting from midstate you still have to do 128 rounds
 77 2015-10-07 18:29:10 <berndj> but ok, i see what you meant now
 78 2015-10-07 18:29:34 <Luke-Jr> not a literal reduction
 79 2015-10-07 20:50:36 <phantomcircuit> Luke-Jr, uhhh not really
 80 2015-10-07 20:51:28 <phantomcircuit> it's more like 1.25 sha256 ops worth of work
 81 2015-10-07 23:18:31 <Luke-Jr> phantomcircuit: pedantic :
 82 2015-10-07 23:19:05 <phantomcircuit> Luke-Jr, you can only get rid of about 15% of the sha256 logic by optimizing for bitcoin :)
 83 2015-10-07 23:21:04 <Luke-Jr> phantomcircuit: I can't argue further due to confidentiality I think.
 84 2015-10-07 23:22:03 <phantomcircuit> :)
 85 2015-10-07 23:43:21 <nwilcox> phantomcircuit: Maybe I'm missing context. I'm surprised at the 15% figure for optimizing sha256 for bitcoin.
 86 2015-10-07 23:43:45 <nwilcox> How did you calculate that?
 87 2015-10-07 23:44:02 <phantomcircuit> nwilcox, sha256 produces a 256 bit output.... but for bitcoin mining you only care about 32 bits of that
 88 2015-10-07 23:44:12 <phantomcircuit> 32 bits of zero == diff1
 89 2015-10-07 23:44:29 <phantomcircuit> (ok maybe you care about 64 bits still)
 90 2015-10-07 23:44:42 <nwilcox> phantomcircuit: Oh neat. I was only thinking of the input side.
 91 2015-10-07 23:44:56 <phantomcircuit> nwilcox, there's also some stuff on the input size
 92 2015-10-07 23:45:15 <nwilcox> I'm still a bit skeptical. Do you mean 15% of the area of an IC implementation?
 93 2015-10-07 23:45:16 <phantomcircuit> sha256 blocksize is 512 bits and in bitcoin we only ever use the first half
 94 2015-10-07 23:45:27 <phantomcircuit> so the second half is constant and you can precompute that
 95 2015-10-07 23:45:32 <phantomcircuit> nwilcox, yeah
 96 2015-10-07 23:45:38 <nwilcox> Should most of the area be consumed by unrolling the rounds, little of which can be omitted?
 97 2015-10-07 23:46:12 <nwilcox> Omitting output bits seems like it would mostly remove the finalization phase.
 98 2015-10-07 23:46:32 <nwilcox> (I could easily be wrong, I'm not an expert at either understanding hash implementations *nor* circuit design. ;-)
 99 2015-10-07 23:46:38 <phantomcircuit> nwilcox, yup but because of how sha256 works being able to fix a full half of the inputs and ~85% of the outputs you can do lots of optimization
100 2015-10-07 23:47:10 <phantomcircuit> nwilcox, there's no finalization round in sha256, each of the rounds is identical
101 2015-10-07 23:48:48 <nwilcox> Ah, ok.