1 2016-01-17 01:52:27 <zookolaptop> In praise of the Bitcoin Core devs: https://twitter.com/zooko/status/688527730619514880
  2 2016-01-17 02:08:17 <jtoomim_> any version bits devs in here? maybe sipa?
  3 2016-01-17 03:46:52 <instagibbs> CodeShark, jtimon(not here?), rusty(not here as well?)
  4 2016-01-17 03:47:05 <instagibbs> those were the three taking stabs at it
  5 2016-01-17 03:47:09 <instagibbs> that i know of
  6 2016-01-17 03:47:39 <CodeShark> here but busy...
  7 2016-01-17 03:48:15 <instagibbs> jtoomim_, https://github.com/bitcoin/bitcoin/pull/6816 https://github.com/bitcoin/bitcoin/compare/master...jtimon:versionbits https://github.com/bitcoin/bitcoin/compare/master...rustyrussell:bip-9-versionbits?expand=1
  8 2016-01-17 04:10:08 <morcos> jtoomim_: i messaged you on slack.  i might be taking on the mantle for core
  9 2016-01-17 04:32:40 <brg444> https://github.com/LightningNetwork/lightning-onion
 10 2016-01-17 04:41:50 <Tulsene> hello, I did some brainstorming I wanted to share with you. I have some lack of knowlege to share with you a complete white paper but at least you have the concept : http://pastebin.com/Hg7cxEWN
 11 2016-01-17 05:22:02 <btcdrak> morcos: there is no might, you took it according to the last IRC minutes :-P
 12 2016-01-17 07:42:43 <Guest73650> i loaded up bitcoin core into netbeans. everything build successfully. i want to step through the code, but i don't know where the main function is.
 13 2016-01-17 07:42:51 <Guest73650> its not in main.cpp
 14 2016-01-17 07:42:57 <Guest73650> i see one inside of bitcoind.cpp
 15 2016-01-17 07:43:07 <Guest73650> is that the entry?
 16 2016-01-17 07:56:14 <Guest73650> hello?
 17 2016-01-17 07:56:18 <Guest73650> is bitcoin dead?
 18 2016-01-17 16:59:43 <fredrin> Guest73650: bitcoind is the name of the executable
 19 2016-01-17 17:00:22 <fredrin> Guest73650: by the way, bitcoin has died multiple times :)
 20 2016-01-17 17:26:35 <maaku> Look in init.cpp
 21 2016-01-17 17:31:26 <Snej_> hey any germans here to help a student creating a presentation about bitcoin?
 22 2016-01-17 17:32:52 <Snej_> what grants the btc's the value?
 23 2016-01-17 17:51:31 <jl2012> Snej_ #bitcoin
 24 2016-01-17 18:28:01 <dwn> hey all
 25 2016-01-17 18:28:09 <dwn> looking for someone who has implemented OP_CHECKSIG before
 26 2016-01-17 18:28:38 <dwn> I'm about to jump off a building trying to understand what TxNew and TxPrev represent in this https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png
 27 2016-01-17 18:29:01 <dwn> so
 28 2016-01-17 18:29:07 <dwn> there's #s in the top charts
 29 2016-01-17 18:29:13 <dwn> are those
 30 2016-01-17 18:29:19 <dwn> like byte values? or sizes
 31 2016-01-17 18:29:26 <dwn> 4, VI, 32, 4
 32 2016-01-17 18:29:55 <dwn> LIKE
 33 2016-01-17 18:29:58 <dwn> like ok
 34 2016-01-17 18:31:53 <dwn> we have our transaction we want to verify. it's in hexstring form 01..............00 00 00 00
 35 2016-01-17 18:31:58 <dwn> like one input, one output
 36 2016-01-17 18:32:26 <dwn> should I consider the input as TxNew and output as TxPrev? either way I look at it it doesn't seem to make sense according to that chart
 37 2016-01-17 18:33:00 <dwn> the rest of the diagram makes sense if I could just figure out TxNew/TxPrev in context of a ctransaction of that type
 38 2016-01-17 18:38:00 <maaku> dwn: i suggest looking at the transaction serializer in the script code
 39 2016-01-17 18:51:57 <roconnor> dwn: TxPrev is the transaction containing the output coin being spend.
 40 2016-01-17 18:52:23 <roconnor> TxNew is the transaction that contains an input that is spending said coin.
 41 2016-01-17 18:53:22 <roconnor> The blocks and numbers is a representation of the serialization of a transaction.
 42 2016-01-17 18:54:00 <roconnor> The numbers represents a block of data of n bytes
 43 2016-01-17 18:55:48 <roconnor> some things are of variable length like the script
 44 2016-01-17 18:56:59 <roconnor> variable length blocks are prefixed by the serialization of a variable length integer to represent the number of items.
 45 2016-01-17 18:57:14 <roconnor> these variable length integers are labeled VI
 46 2016-01-17 18:57:33 <roconnor> so the VI just before the script represents the size of the script
 47 2016-01-17 18:57:48 <roconnor> the VI just before the TxOuts represent the number of outputs
 48 2016-01-17 18:57:58 <roconnor> the VI just before the TxIns represent the number of intputs
 49 2016-01-17 19:08:52 <dwn> roconnor: omg! thanks
 50 2016-01-17 19:09:16 <dwn> roconnor: but, from my understanding...I have a single TX right? input is the target to give coins to, output is proof that you can spend it right?
 51 2016-01-17 19:09:23 <dwn> why would they be two TXs?
 52 2016-01-17 19:20:34 <roconnor> dwn: each input of a TX has to be checked against the script authrozing the input coin to be spent.  That script is found inside the tranasction that cointains the coin you are spending.
 53 2016-01-17 20:04:11 <Rebroad> so, I've just read BIPS 141 to 144... these all seem to help with increasing capacity, but none of them seem to address the long-term problem as overall they will increase capacity by just a one-time limited amount, won't they?
 54 2016-01-17 20:05:58 <Luke-Jr> even if we did absolutely nothing, capacity won't be a problem until 2020; segwit buys us maybe 5 more years to 2025; Lightning buys us a few decades
 55 2016-01-17 20:08:10 <zzif> there are quite many almost full blocks: https://blockexplorer.com/
 56 2016-01-17 20:09:25 <Lauda> Luke-Jr are you trying to say that blocks won't be mostly full until 2020?
 57 2016-01-17 20:09:26 <zzif> it is likely to expect 100% increase in transaction count within 3-6 months
 58 2016-01-17 20:09:38 <Luke-Jr> Lauda: yes
 59 2016-01-17 20:09:58 <Luke-Jr> zzif: no, miners are padding them with spam because of mob harassment
 60 2016-01-17 20:10:01 <Lauda> What if there's a trigger event increase the userbase by two times?
 61 2016-01-17 20:10:13 <Lauda> that increases*
 62 2016-01-17 20:10:16 <Luke-Jr> zzif: and no, growth has not been exponential and there is no reason to expect that to change until Bitcoin scales properly
 63 2016-01-17 20:10:28 <Luke-Jr> Lauda: then we'll reach it sooner
 64 2016-01-17 20:10:42 <Luke-Jr> Lauda: worst case we can do an emergency hardfork
 65 2016-01-17 20:11:30 <zzif> Luke-Jr: well, the transaction count has doubled since aug 15
 66 2016-01-17 20:11:42 <Luke-Jr> zzif: there is no evidence of that
 67 2016-01-17 20:11:47 <zzif> https://blockchain.info/charts/n-transactions
 68 2016-01-17 20:11:53 <Luke-Jr> blockchain.info = misinformation
 69 2016-01-17 20:12:00 <Luke-Jr> if they claim it, it's probably wrong
 70 2016-01-17 20:13:17 <MrHodl> Baffling how many people still use blockchain.info for info.
 71 2016-01-17 20:14:37 <Rebroad> Luke-Jr, "mob harassment" - what is that please?
 72 2016-01-17 20:15:08 <Luke-Jr> Rebroad: /r/BTC basically
 73 2016-01-17 20:15:13 <zzif> is there any other graph for transactions? it should not be difficult to parse that information from the blockchain
 74 2016-01-17 20:15:26 <Guest73650> whenever i try to run/debug bitcoin from within netbeans, i am constantly thrown into the main function inside gen_context.c inside the secp2561k folder
 75 2016-01-17 20:15:32 <maaku> Rebroad: the malleability fixes of segwit is really where the scaling happens -- it allows trustless off-chain solutions
 76 2016-01-17 20:15:34 <Luke-Jr> zzif: what's hard is differentiating real transactions from spam
 77 2016-01-17 20:15:39 <Lauda> Luke-Jr but why not prepare for that event right now?
 78 2016-01-17 20:15:59 <Luke-Jr> Lauda: we are, see https://bitcoin.org/en/bitcoin-core/capacity-increases
 79 2016-01-17 20:16:07 <maaku> Lauda: we are.
 80 2016-01-17 20:16:11 <zzif> Luke-Jr: spam transactions are real, not artificial
 81 2016-01-17 20:16:15 <Guest73650> where should i actually be starting from?
 82 2016-01-17 20:16:45 <Lauda> I've read that.
 83 2016-01-17 20:16:49 <Lauda> I wish IBLTs and weak blocks would come sooner.
 84 2016-01-17 20:16:50 <Luke-Jr> zzif: just like spam emails are real, sure
 85 2016-01-17 20:17:20 <maaku> Lauda: procautionary principle: we should increase the on-chain capacity of bitcoin only as much as we can demonstrate the ability to do so safely
 86 2016-01-17 20:17:29 <instagibbs> zzif, transactions arent geting stuck yet, we have time: http://rusty.ozlabs.org/?p=573
 87 2016-01-17 20:17:36 <maaku> right now we have clear evidence that we can do an equivalent of about 2MB or so safely, and that is the plan
 88 2016-01-17 20:17:38 <instagibbs> and forward motion IS being made
 89 2016-01-17 20:17:45 <Luke-Jr> Lauda: I believe they're being worked on in parallel. It's just that segwit will be ready sooner.
 90 2016-01-17 20:17:48 <maaku> but we also need to enable features that will let us get the NEXT increase in due time
 91 2016-01-17 20:18:11 <zzif> instagibbs: thanks, will read that
 92 2016-01-17 20:18:36 <Lauda> Luke-Jr & maaku Who's working on them?
 93 2016-01-17 20:19:06 <Luke-Jr> Lauda: sipa, CodeShark, jl2012, and myself (and probably others!) are working on segwit
 94 2016-01-17 20:19:13 <Luke-Jr> Lauda: I think Rusty is working on IBLT
 95 2016-01-17 20:20:56 <Lauda> Thank you for the information.
 96 2016-01-17 20:21:05 <Lauda> Some users seem to think that SegWit damages the security model
 97 2016-01-17 20:21:14 <Luke-Jr> they're wrong
 98 2016-01-17 20:21:28 <instagibbs> it's the same old thing like p2sh, people are being really deceitful :/
 99 2016-01-17 20:22:00 <Lauda> Example.. http://prntscr.com/9rddlp
100 2016-01-17 20:22:38 <maaku> I'm working on segwit as well
101 2016-01-17 20:22:46 <maaku> other people are reviewing
102 2016-01-17 20:23:02 <maaku> Lauda: absolutely wrong. it is exactly the same as P2SH
103 2016-01-17 20:23:48 <Lauda> maaku I understand that. I think there's a lack of communication between developers and users though (nice new website).
104 2016-01-17 20:24:28 <maaku> Lauda: then please help us out and spread what you learn
105 2016-01-17 20:24:53 <Lauda> I am, whenever possible @BTCT.
106 2016-01-17 20:24:58 <Lauda> Bitcoin does not use Java right?
107 2016-01-17 20:24:58 <Rebroad> What I would like to understand is, why don't we work towards creating a hard-fork of bitcoin that only kicks in when the a significant majority of miners agree to it, and allows the miners themselves how to scale bitcoin (i.e. allow them to increase and decrease capacity - i.e. a vote in each block produced)?
108 2016-01-17 20:25:26 <Rebroad> rather than a fixed prediction of how the network needs to scale
109 2016-01-17 20:26:02 <maaku> i mean a certain part of me gets very frustrated by this situation. we organized a series of open-access workshops, with webcast archives, we did bitcoin meetup presentations, we got major news outlets to do fair reporting on the tech (thanks AaronvanW!)
110 2016-01-17 20:26:44 <maaku> Type "segregated witness" in google and the very first result is an excellent explanation of the technology in layman terms
111 2016-01-17 20:27:07 <maaku> Is the problem here really that -we- haven't been communicating?
112 2016-01-17 20:27:42 <maaku> Lauda: bitcoin is written entirely in C++ with some C
113 2016-01-17 20:27:51 <belcher> from some of my talking to people, its worrying how little the "hostile hard forks undermine digital scarcity" argument convinces people
114 2016-01-17 20:28:03 <belcher> if they just use bitcoin, rather than owning lots of it
115 2016-01-17 20:29:45 <Lauda> maaku apparently people need more, maybe a video like the one found on bitcoin.org on segwit
116 2016-01-17 20:29:51 <Lauda> to explain it for people without a IT background.
117 2016-01-17 20:29:55 <Lauda> Then I can't be of use ATM.
118 2016-01-17 20:29:56 <belcher> maaku could we try posting the explaination on reddit and upvoting to the top ?
119 2016-01-17 20:30:45 <Rebroad> what is a "hostile hard fork"?
120 2016-01-17 20:31:01 <maaku> belcher: it's been there (Aaron's bitcoin magazine article is what I was referring to)
121 2016-01-17 20:31:04 <Rebroad> not all hard forks are hostile
122 2016-01-17 20:49:57 <Lauda> https://www.reddit.com/r/Bitcoin/comments/41ehxy/can_a_core_dev_explain_again_whats_the_problem/
123 2016-01-17 20:53:49 <phantomcircuit> Lauda, it would take ~12 days to synchronize from the wifi here at 1MB
124 2016-01-17 20:54:23 <Rebroad> phantomcircuit, how relevant is that?
125 2016-01-17 20:55:03 <belcher> Rebroad very, being easy to set up a full node keeps the system decentralized
126 2016-01-17 20:55:41 <belcher> many people running a full node and using it as their wallet is the only thing that stops miners inflating the currency or confiscating coins
127 2016-01-17 20:56:20 <Rebroad> 12 days seems like a very long time...  to download how many GB?
128 2016-01-17 20:56:52 <belcher> like 45gb
129 2016-01-17 20:58:23 <phantomcircuit> Rebroad, 12 days is easily long enough that the vast majority of people would just give up
130 2016-01-17 20:58:39 <phantomcircuit> we have people who show up and say they're giving up after as little as 4 hours
131 2016-01-17 20:58:57 <belcher> phantomcircuit can you even keep up with with the chain at that point? download and verify a block in 10 minutes
132 2016-01-17 20:58:58 <Rebroad> phantomcircuit, well, clearly they are not the people who will run a full node then
133 2016-01-17 20:59:41 <Rebroad> phantomcircuit, clearly they are people who don't know what they are doing
134 2016-01-17 20:59:52 <phantomcircuit> belcher, i believe so, but i dont have enough storage space so this machine runs in pruned mode
135 2016-01-17 21:00:00 <phantomcircuit> if anything goes wrong i'd have to wait another 12 days
136 2016-01-17 21:00:15 <phantomcircuit> oops gtg!
137 2016-01-17 21:04:15 <Chris_Stewart_5> Can anyone comment on validation times of txs when running monster scripts? I thought libsecpk2561 alleviated these issues?
138 2016-01-17 21:04:19 <Lauda> phantomcircuit 12 days..?
139 2016-01-17 21:16:58 <Rebroad> Lauda, I think phantomcircuit has very slow WiFi.. it doesn't take me that long... but I might have to run some newer tests though...
140 2016-01-17 21:17:13 <Lauda> That seems like quite long.
141 2016-01-17 21:17:24 <Rebroad> Lauda, anyway, 12 days is not a long time for someone wanting to run a full-node... I mean, what's the rush?!
142 2016-01-17 21:17:41 <Lauda> That's almost half a month.. it is long to set up one.
143 2016-01-17 21:17:50 <Rebroad> Lauda, yes, but why the rush?
144 2016-01-17 21:18:02 <belcher> time is money
145 2016-01-17 21:18:05 <Lauda> Exactly.
146 2016-01-17 21:18:15 <Rebroad> belcher, running a full node doesn't make money
147 2016-01-17 21:18:39 <belcher> Rebroad if you're using bitcoin instead of some other currency, presumably its valuable to you
148 2016-01-17 21:18:44 <Lauda> You lose money waiting.
149 2016-01-17 21:18:52 <belcher> it doesnt make you "money" per se but theres still economic value in it
150 2016-01-17 21:18:52 <Rebroad> Lauda, how would you lose money?
151 2016-01-17 21:18:59 <Lauda> If you're paying for a VPS
152 2016-01-17 21:19:04 <Lauda> 12 days of lost money.
153 2016-01-17 21:19:21 <Rebroad> Lauda, if you're running a full node, it'll cost you the same to run it no matter how long it takes to download the blockchain
154 2016-01-17 21:19:24 <Lauda> Imagine compiling code that takes 12 days instead of 1?
155 2016-01-17 21:19:28 <Lauda> No time lost?
156 2016-01-17 21:20:06 <Rebroad> Lauda, belcher, I don't think you understand what motivates people to run full-nodes
157 2016-01-17 21:20:22 <Lauda> ...
158 2016-01-17 21:20:25 <Lauda> you're weird.
159 2016-01-17 21:20:31 <Lauda> So let's not use SSDs because why the rush
160 2016-01-17 21:20:33 <Lauda> HDDs are fine
161 2016-01-17 21:20:51 <Rebroad> Lauda, you've still now answered my question. Rush to do what?
162 2016-01-17 21:20:53 <Lauda> Time is valuable, time should not be wasted unless necessary.
163 2016-01-17 21:21:48 <Rebroad> Lauda, you could argue that running a full-node IS a waste of time... it's either a waste of time to run it, or it isn't... but running it involves downoading the blockchain.. it's part and parcel of running a full-node
164 2016-01-17 21:22:20 <Lauda> I wouldn't bother setting up a node that takes 12 days to set up.
165 2016-01-17 21:22:21 <Lauda> No way.
166 2016-01-17 21:22:31 <belcher> Rebroad running a full node is the most privacy way to use bitcoin, you only need to look at your hard drive instead of telling some random server all your addresses
167 2016-01-17 21:22:34 <Rebroad> anyway, this a a conversation for #bitcoin, not #bitcoin-dev
168 2016-01-17 21:22:52 <belcher> for many use-cases, full node is the only way, and 12 days is costly in time
169 2016-01-17 21:23:15 <Lauda> Imagine a situation where user has no full node, they need it for reason X to use Y
170 2016-01-17 21:23:24 <Lauda> so wait 12 days before using it?
171 2016-01-17 21:24:38 <roconnor> Chris_Stewart_5: https://www.reddit.com/r/Bitcoin/comments/3yulwv/any_examples_of_the_10_minute_script_thats_a/cyhb33d
172 2016-01-17 21:24:47 <roconnor> but the reference link is broken :(
173 2016-01-17 21:25:14 <roconnor> ``The problem is that the algorithm used for SIGHASH_ALL is O( n2 ), and requires that you hash 1.2 GB of data for a 1 MB transaction.'' -- jtoomim
174 2016-01-17 23:03:46 <drnet> a question to address prefixes: is a hardfork needed to add another type of adress like 2/4?
175 2016-01-17 23:06:15 <maaku> Addresses are pure user interface
176 2016-01-17 23:07:04 <drnet> ah ok, so an old client would accept blocks/transactions if a newer client sent coins to "4blablabla"?
177 2016-01-17 23:19:34 <maaku> They wouldn't even be aware, yes.
178 2016-01-17 23:20:35 <drnet> ah great, that helped alot thanks!
179 2016-01-17 23:39:37 <AaronvanW> maaku: thanks (re: segwit articles)
180 2016-01-17 23:39:44 <sinetek> hey has anyone tried to compile recently on FreeBSD? I get errors about pkg-config
181 2016-01-17 23:40:28 <AaronvanW> have you guys considered doing like a weekly AMA session or something like that? core devs could take turns, might help get rid of a lot of FUD
182 2016-01-17 23:44:27 <roconnor> If a transaction is made up of SIGHASH_SINGLE is it considered mabliable (by rearranging the inputs)?
183 2016-01-17 23:47:01 <roconnor> oops
184 2016-01-17 23:47:13 <roconnor> If a transaction is made up of SIGHASH_ANYONECANPAY is it considered mabliable (by rearranging the inputs)?
185 2016-01-17 23:54:25 <AaronvanW> does 0.12.0 have blockchain pruning, by the way?
186 2016-01-17 23:55:19 <belcher> yep, even 0.11 did
187 2016-01-17 23:55:43 <belcher> roconnor yes, or even adding new inputs