1 2015-10-16 04:56:24 <SourabhL> hello
  2 2015-10-16 04:56:40 <SourabhL> exit
  3 2015-10-16 06:53:45 <Luke-Jr> cfields: any chance you can write up gitian-compatible depends/ for BFGMiner dependencies if you get a chance?
  4 2015-10-16 06:53:50 <Luke-Jr> particularly targetting Mac
  5 2015-10-16 10:56:59 <Sigals> I've installed bitcoind on my server and set it to testnet, it's up to date with the latest block but I don't seem to be able to query for transactions, for example https://www.blocktrail.com/tBTC/tx/299f7839e65696441bde7b86a4637298514ae13c3aaff8fc4454a0afb0f7071e this transaction, If I run "bitcoin-cli gettransaction 299f7839e65696441bde7b86a4637298514ae13c3aaff8fc4454a0afb0f7071e" it says error: {"code":-5,"message":"Invalid or
  6 2015-10-16 10:57:28 <Luke-Jr> gettransaction is a wallet method, it only accesses your own wallet
  7 2015-10-16 10:57:48 <Luke-Jr> getrawtransaction is what you probably want, and it only works reliably with txindex=1 in bitcoin.conf (which requires a reindex)
  8 2015-10-16 10:57:55 <Luke-Jr> (and takes up more disk space)
  9 2015-10-16 10:58:42 <Sigals> I tried getrawtransaction too error: {"code":-5,"message":"No information available about transaction"}
 10 2015-10-16 10:59:37 <Sigals> If I try listtransactions, nothing shows up either
 11 2015-10-16 11:01:14 <Sigals> Oh, it seems to be working now for some strange reason... lol
 12 2015-10-16 11:03:47 <matsjj> whats a reasonable bandwidth requirement to run something behind tor? Currently designing some specs around lightning.. Is 100kb/s constant load up and down too much? Where would you define a threshold for a network, such that it can be said to be decentralised, as everyone can run it from home? I'm rather biased by my rather fast connection
 13 2015-10-16 11:07:18 <matsjj> trying to find these 'bathtubs limits'.. 1kb/s can easily be said to allow for strong decentralisation, while 100MB/s will only allow centralised services
 14 2015-10-16 11:13:27 <kuzetsa> O_O
 15 2015-10-16 11:14:16 <kuzetsa> tor-specific bitcoin usage case isn't something I figured was a core development / operations / design goal for bitcoin
 16 2015-10-16 11:14:36 <matsjj> Talking about lightning nodes ;)
 17 2015-10-16 11:14:47 <kuzetsa> I might be biased and buy into the fear of bitcoin being associated with "the darknet" and not want to really discuss it though
 18 2015-10-16 11:16:04 <kuzetsa> is lightning a bitcoin client
 19 2015-10-16 11:16:09 <kuzetsa> not heard of it
 20 2015-10-16 11:16:36 <matsjj> Oh, no it's an overlayer network for instant payments without custodian risks. lightning.network
 21 2015-10-16 11:17:18 <kuzetsa> hmm
 22 2015-10-16 11:17:19 <matsjj> As a plus side, lightning nodes are deeply incentivised to run full bitcoin nodes as well, so it might really solve the problem of the ever dropping node count
 23 2015-10-16 11:17:22 <kuzetsa> sidechain?
 24 2015-10-16 11:17:30 <kuzetsa> is there a lightning BIP?
 25 2015-10-16 11:17:30 <matsjj> nah, payment channels
 26 2015-10-16 11:17:58 <matsjj> It's mostly about engineering, not much BIP to it. We need CLTV+CSV though
 27 2015-10-16 11:18:11 <matsjj> and malleability fix would be ideal
 28 2015-10-16 11:18:43 <Luke-Jr> eh, there's plenty to BIP for Lightning..
 29 2015-10-16 11:19:02 <matsjj> but apparently bitcoin nodes take easily 200kb/s constant bandwidth, so designing with 100kb/s should be good for now
 30 2015-10-16 11:19:16 <kuzetsa> BIPs 68, 112 ... hmm
 31 2015-10-16 11:19:17 <matsjj> Luke-Jr: plenty?
 32 2015-10-16 11:19:38 <Luke-Jr> matsjj: anything that requires interoperability between different implementations
 33 2015-10-16 11:20:16 <matsjj> I'll rather expected a list of all of those.. ;)
 34 2015-10-16 11:20:39 <Luke-Jr> I don't know enough about how Lightning is being implemented to go into detail :P
 35 2015-10-16 11:20:47 <kuzetsa> I've never really explored bip 112 before today. not sure what it has to do with tor though
 36 2015-10-16 11:20:51 <matsjj> kuzetsa: As I said, we are ready to go with CLTV+CSV - no further BIPs are needed luckily
 37 2015-10-16 11:21:19 <matsjj> a sighash for normalized txid would be great, but just as a bonus
 38 2015-10-16 11:21:36 <Luke-Jr> matsjj: for example, there'd need to at least be a BIP describing how two wallets negotiate the payment
 39 2015-10-16 11:22:08 <matsjj> Hm right. I guess I always thought about BIPs as actual consensus changes
 40 2015-10-16 11:22:21 <matsjj> And not as design specifications
 41 2015-10-16 11:22:36 <Luke-Jr> nope, most deal with non-consensus standards
 42 2015-10-16 11:22:52 <matsjj> Good to know. We will have plenty of BIPs then
 43 2015-10-16 11:22:58 <Luke-Jr> ☺
 44 2015-10-16 11:23:07 <kuzetsa> unicode emoji?
 45 2015-10-16 11:23:12 <matsjj> wow
 46 2015-10-16 11:23:14 <matsjj> thats so small
 47 2015-10-16 11:23:20 <Luke-Jr> … emoji didn't exist when ☺ was made in the 80s
 48 2015-10-16 11:23:27 <kuzetsa> ツ
 49 2015-10-16 11:23:39 <kuzetsa> becauase tsu doubles as an emoji, apparently :)
 50 2015-10-16 11:24:07 <kuzetsa> tsu was around before computers :)
 51 2015-10-16 11:24:56 <azku> Does anyone know of bitcoin clients/nodes/libraries that are written in Erlang?
 52 2015-10-16 11:25:20 <matsjj> Luke-Jr: just for the record, would you agree with 100kb/s should be doable by anyone on the world without too much effort?
 53 2015-10-16 11:26:00 <matsjj> Even behind TOR maybe
 54 2015-10-16 11:26:13 <kuzetsa> matsjj: I would say it's not doable by anyone in the world
 55 2015-10-16 11:26:17 <kuzetsa> that's pretty heavy
 56 2015-10-16 11:26:27 <Luke-Jr> matsjj: I think lots of people are stuck behind 56k modems and 2G cellular towers
 57 2015-10-16 11:26:51 <Luke-Jr> realistically, you *won't* get everyone on the world
 58 2015-10-16 11:26:57 <kuzetsa> some people get their internet connections over mobile networks (smartphone tethering, etc.) and with moderate to poor signal, 100kb/s is a tough requirement
 59 2015-10-16 11:27:19 <matsjj> yea I guess that was a bad call - I guess 50% of the world is good already fwiw
 60 2015-10-16 11:27:22 <kuzetsa> 40kb/s is more doable
 61 2015-10-16 11:27:58 <Luke-Jr> indeed, typical high-end 4G in the US is 5 GB/mo, which is under 2 kB/s..
 62 2015-10-16 11:28:11 <kuzetsa> I try not to do streaming radio at higher than 40kb/s if I want my music to keep playing during the commute, for instance
 63 2015-10-16 11:28:35 <matsjj> I guess a better question would be - Is 100kb low enough for most areas in the world to achieve? Income from running a lightning node might vary between $50-$500, depending on the setup
 64 2015-10-16 11:28:48 <kuzetsa> what?
 65 2015-10-16 11:28:52 <kuzetsa> income?
 66 2015-10-16 11:28:53 <matsjj> yep
 67 2015-10-16 11:28:58 <kuzetsa> ...
 68 2015-10-16 11:28:59 <matsjj> thats what I said with incentives
 69 2015-10-16 11:29:02 <kuzetsa> early adopter style?
 70 2015-10-16 11:29:06 <matsjj> No, constant
 71 2015-10-16 11:29:10 <kuzetsa> weird
 72 2015-10-16 11:29:10 <matsjj> for handling transactions
 73 2015-10-16 11:29:13 <kuzetsa> huh ok
 74 2015-10-16 11:29:24 <matsjj> 0.0001% + 1 satoshi
 75 2015-10-16 11:29:26 <matsjj> thought big
 76 2015-10-16 11:29:27 <kuzetsa> I need to leave actually (that commute I mentioned. gonna be late)
 77 2015-10-16 12:14:20 <Cocodude> Hello. What precisely is nTimeSmart in the wallet? A lot of time resyncing is spent trying to figure this out in AddToWallet.
 78 2015-10-16 12:16:49 <Luke-Jr> Cocodude: a reasonable guess at the time a transaction was done
 79 2015-10-16 12:18:02 <Cocodude> Luke-Jr: Thanks. I don't suppose you have a minute to detail to me how it's trying to guess this?
 80 2015-10-16 12:18:12 <Cocodude> The reverse iterator bit of code is very slow on my profiling
 81 2015-10-16 12:19:09 <Luke-Jr> Cocodude: essentially the receive time, unless it's in a block, then the block time; unless whatever time that is is slightly in the past relative to the last transaction in the wallet (in which case it's moved forward)
 82 2015-10-16 12:19:26 <Luke-Jr> (unless it's in a block at the time it is received*)
 83 2015-10-16 12:19:40 <Cocodude> Seems to take ~ 0.01 - 0.1 seconds in this iterator
 84 2015-10-16 12:20:30 <Cocodude> Luke-Jr: Right, so if we take the assumption that we're rescanning from a zapped wallet, the comparisons to the "last transaction in the wallet" are meaningless?
 85 2015-10-16 12:20:41 <Cocodude> Oh, and these will always be a block too
 86 2015-10-16 12:20:45 <Luke-Jr> Cocodude: no, because you're adding them to the wallet..
 87 2015-10-16 12:21:05 <Luke-Jr> if you add A before B, then you don't necessarily want B's time to be before A's
 88 2015-10-16 12:21:16 <Luke-Jr> and block times are not guaranteed to be forward-moving
 89 2015-10-16 12:21:49 <Cocodude> Luke-Jr: Why are block times not forward moving?
 90 2015-10-16 12:21:55 <Luke-Jr> because they're not.
 91 2015-10-16 12:22:15 <Cocodude> But if they build upon each other, then they must be, no?
 92 2015-10-16 12:22:24 <Cocodude> (I know I'm wrong, but why?)
 93 2015-10-16 12:23:16 <aj> Cocodude: a miner's clock could be wrong, so it thinks it's an hour in the future; allowing times to vary a bit handles that fairly gracefully
 94 2015-10-16 12:24:17 <Cocodude> aj: Ah, I can see that being tricky to handle
 95 2015-10-16 12:25:20 <Cocodude> I still don't get why we can't just assume it's the block time for a new transaction though (from a rescan)
 96 2015-10-16 12:25:54 <Cocodude> Can I have an example?
 97 2015-10-16 12:27:53 <Luke-Jr> Cocodude: because *usually* you see transactions before they're in a block, and in any case you almost never want time to go *backwards* in your wallet's ledger
 98 2015-10-16 12:29:13 <Cocodude> Indeed. I'm thinking of optimising this for the rescan scenario you see
 99 2015-10-16 12:30:07 <Cocodude> If I can shave off this ~0.05 seconds per add, it stacks up to ~2.5 hours of rescan time
100 2015-10-16 12:30:18 <Cocodude> (for me, with ~180000 keys)
101 2015-10-16 12:33:16 <Cocodude> Do you thus agree that, for rescan purposes only, that the wallet txn time = the block time?
102 2015-10-16 13:01:26 <Cocodude> Having done some testing with logs of debug statements, I can confirm that it should be the block time (the min(...) is basically min(blocktime, current real time))
103 2015-10-16 13:06:28 <Cocodude> Do you think I could say, "if wtx.nTimeReceived > (blockTime + 1 day) then smartTime = blockTime else smartTime = doIteratorStuff"?
104 2015-10-16 13:18:32 <Cocodude> Unless I'm mistaken, this code is really inefficient (although there is a comment saying this)
105 2015-10-16 13:20:54 <Cocodude> I think it 1. Creates an entirely new map based on wtx->nOrderPos, i.e. iterates over every mapWallet entry to do this (this is in OrderTxItems), and 2. Iterates in reverse over this entire list, without ever breaking out (so I think it iterates right back to wallet entry #1)
106 2015-10-16 13:53:46 <Cocodude> If anyone's around, I think I have a tiny fix which doesn't change the logic. Do you agree it's safe to add the block "if (latestNow < blocktime)" around the whole section of AddToWallet that calls OrderedTxItems and the iterates over it?
107 2015-10-16 14:45:28 <CoinSachs> any back end developers open for a project?
108 2015-10-16 15:05:04 <_SimonD> CoinSachs
109 2015-10-16 15:05:20 <CoinSachs> hey _SimonD
110 2015-10-16 15:05:41 <_SimonD> trying to geta pm.. but, not sure i was doing it correctly..
111 2015-10-16 15:05:54 <matsjj> doesn't the process of inv->getdata->block massively increase the delay of a block to make it through the network?
112 2015-10-16 15:06:18 <matsjj> even worse for a tx?
113 2015-10-16 15:16:07 <treehug88> is there a Makefile target in bitcoin to just build (and perhaps test) libconsensus?
114 2015-10-16 15:18:06 <treehug88> one answer: cd src && make libbitcoinconsensus.la
115 2015-10-16 15:32:31 <cfields> && make bitcoind
116 2015-10-16 15:32:46 <cfields> oh, sorry, misread. yes, yours is correct
117 2015-10-16 15:33:13 <treehug88> is there a target just to run the libbitcoinconsensus tests cfields ?
118 2015-10-16 15:33:38 <cfields> treehug88: no. there's only a minimal test at the moment, and it's baked into the bitcoind tests
119 2015-10-16 15:33:55 <treehug88> ok, thanks cfields
120 2015-10-16 15:35:07 <cfields> Luke-Jr: mm, unlikely any time soon. what are the deps?
121 2015-10-16 15:44:50 <flound1129> any reason bitcoind should be using 18 gigs of memory?
122 2015-10-16 17:06:50 <kanzure> is there a link to a stream for the devcore workshop going on today?
123 2015-10-16 17:17:04 <job_> kanzure that'd be awesome
124 2015-10-16 17:17:16 <job_> I'm in SSF but have to work today :\
125 2015-10-16 17:34:25 <alexor> hello
126 2015-10-16 17:42:41 <cfields> sdaftuar: ping
127 2015-10-16 17:44:11 <cfields> sdaftuar: i suspect that the proposal i gave for #221 is daft, but it traces out ok in my head
128 2015-10-16 17:47:46 <sdaftuar> cfields: i was just about to respond -- someone brought up that suggestion, of sending the message before verack, in yesterday's IRC discussion
129 2015-10-16 17:48:08 <cfields> sdaftuar: i saw that someone mentioned sending it directly _after_ verack
130 2015-10-16 17:48:15 <cfields> i didn't see the discussion about before
131 2015-10-16 17:48:28 <sdaftuar> hm i recall someone being concerned with software not handling messages before a verack
132 2015-10-16 17:48:35 <sdaftuar> one sec
133 2015-10-16 17:49:38 <sdaftuar> 15:12 < sipa> can we require the message be sent between version and verack?
134 2015-10-16 17:49:41 <sdaftuar> 15:13 < sipa> or would this trip up older clients that expect nothing in between
135 2015-10-16 17:49:44 <sdaftuar> 15:13 < davec> that would probably break older clients
136 2015-10-16 17:49:47 <sdaftuar> 15:13 < sdaftuar> well we only send it if the recipient's version is high enough
137 2015-10-16 17:49:50 <sdaftuar> 15:13 < wumpus> I think that will cause potential problems
138 2015-10-16 17:50:20 <cfields> sdaftuar: 2 things there:
139 2015-10-16 17:50:22 <sdaftuar> so maybe a compatibility issue with non-core clients?
140 2015-10-16 17:50:53 <cfields> 1. i believe core can already send out messages in-between those two.
141 2015-10-16 17:51:29 <cfields> 2. other software is going to have to update to deal with sendheaders anyway. But I suppose that's irrelevant since we don't want to break anything that doesn't
142 2015-10-16 17:51:35 <cfields> sec, poking at #1
143 2015-10-16 17:53:00 <sdaftuar> looks like we PushMesage("verack") in the version processing code...
144 2015-10-16 17:53:21 <sdaftuar> so unless we are sending messages before a version, i don't think #1 is true, maybe there's an edge case i'm missing?
145 2015-10-16 17:56:30 <cfields> sdaftuar: ping is the one i'm thinking of, but that might've been a bug in my current code
146 2015-10-16 17:59:42 <cfields> ok yea, i had that mixed up
147 2015-10-16 18:17:16 <lclc> hi, is there any reason adding sendrawtransaction to the HTTP REST API over GET is a bad idea?
148 2015-10-16 18:17:31 <lclc> or is the only reason it's not there yet that nobody did it
149 2015-10-16 18:53:23 <cfields> sdaftuar: aha, that's what i was thinking of. on the receiving side, after receiving version, it doesn't wait for verack before sending ping/getheaders
150 2015-10-16 18:54:51 <sdaftuar> ah
151 2015-10-16 18:54:56 <sdaftuar> but we will send the verack ourselves first?
152 2015-10-16 18:58:36 <cfields> yea
153 2015-10-16 19:42:39 <sdaftuar> cfields: sorry was afk for a bit.  thinking about this more, since the BIP says this message is totally optional anyway for a peer to respond to, i'm not sure it buys us much to constrain it further (eg by specifying when you're allowed to send it, etc)
154 2015-10-16 19:43:02 <sdaftuar> seems easier to just specify that in the implementation, and have the wiggle room to change it reasonably within the constraints of a more permissive BIP
155 2015-10-16 19:43:33 <sdaftuar> the implementation in #6494 sends a "sendheaders" just after the verack
156 2015-10-16 19:43:42 <sdaftuar> but accepts a sendheaders from a peer at any time
157 2015-10-16 19:44:01 <sdaftuar> if there's a reason int he future to ignore sendheaders messages not sent just after the verack, i think we can decide then whether that's what we want to do?
158 2015-10-16 19:44:07 <sdaftuar> the BIP doesn't require us to honor the request
159 2015-10-16 19:48:49 <cfields> sdaftuar: i don't like it at all being unconstrained. But i'm finding it tough to come up with a reason other than "matter of principle" as an argument. And that's not a good argument.
160 2015-10-16 19:50:09 <sdaftuar> cfields: i guess it doesn't make you any happier with it if we say additional constraints are implementation-defined? :)
161 2015-10-16 19:50:39 <cfields> heh. that would help, actually
162 2015-10-16 19:50:53 <cfields> at least that's saying "don't rely on any particular behavior here"
163 2015-10-16 19:51:12 <sdaftuar> yeah i don't think i'd object to adding language along those lines
164 2015-10-16 19:51:20 <sdaftuar> the intent is for this to be a totally optional thing
165 2015-10-16 19:51:44 <sdaftuar> ok, i'll add something and update the pull
166 2015-10-16 19:53:00 <cfields> sdaftuar: understood. though i would argue that more implementions would be likely to opt-in if they could set up the behavior at node-setup time and be done with it.
167 2015-10-16 19:54:21 <Luke-Jr> cfields: libcurl, libjansson, libpdcurses, hidapi, libmicrohttpd, libevent, libusb
168 2015-10-16 19:54:39 <sdaftuar> you mean, if we did something like require these kinds of "capability" flags before the verack, say?
169 2015-10-16 19:54:54 <sdaftuar> i agree with you that seems cleaner, but that seems like a heavier lift to avoid breaking other people's software :(
170 2015-10-16 19:55:47 <sdaftuar> my only concern with changing this to a generic "capabilities" message is that i think we'll run into the same synchronization problems with changing it in the future, that we're running into now with say extending the version message or something
171 2015-10-16 19:56:13 <sdaftuar> (and i don't have a use case in mind for something in the future, but presumably other people do)
172 2015-10-16 19:56:29 <treehug88> Is it valid to use an output with 0 satoshis as an input to a transaction? I think the answer is "no" but I'm making sure for 'reasons'
173 2015-10-16 19:56:50 <Luke-Jr> treehug88: it's fine
174 2015-10-16 19:57:01 <Luke-Jr> you can't create them, though
175 2015-10-16 19:57:24 <treehug88> can't create what, a 0 satoshi output?
176 2015-10-16 19:58:01 <Luke-Jr> right
177 2015-10-16 19:58:06 <treehug88> great, thanks
178 2015-10-16 19:58:44 <morcos> Luke-Jr: huh?  you can create 0 satoshi outputs
179 2015-10-16 19:59:15 <sdaftuar> i think he's saying they're non-standard?
180 2015-10-16 19:59:30 <Luke-Jr> morcos: per the consensus rules, yes, but afaik not a single node considers them policy-okay, and they're almost certain to violate the social agreement
181 2015-10-16 20:00:45 <treehug88> Luke-Jr, morcos : so technically they could be used as inputs to a transaction too (except for 'standard transaction' rejections)?
182 2015-10-16 20:01:03 <aj> it fails IsDust, right?
183 2015-10-16 20:01:07 <morcos> treehug88: that i'm not sure about, but don't see why not
184 2015-10-16 20:01:29 <morcos> dust is also just policy
185 2015-10-16 20:01:35 <Luke-Jr> treehug88: it can be used as inputs cleanly, afaik
186 2015-10-16 20:02:00 <Luke-Jr> I don't know of any policy code that prevents using them as inputs.
187 2015-10-16 20:02:23 <maaku> IsDust is only checked for outputs
188 2015-10-16 20:02:35 <treehug88> ok, so the summary is - you can create 0 satoshi outputs, and use them as inputs to another transaction, but (many) miners will reject 0 satoshi output transactions as being non-standard?
189 2015-10-16 20:02:56 <treehug88> ... and it's dust
190 2015-10-16 20:03:27 <morcos> that sounds right to me
191 2015-10-16 20:03:45 <treehug88> thanks morcos and everyone
192 2015-10-16 20:04:13 <aj> treehug88: also, most nodes won't relay them, so miners won't even see them (i think)
193 2015-10-16 20:04:27 <treehug88> aj sounds legit, thanks again
194 2015-10-16 20:06:29 <cfields> sdaftuar: sorry, phone, back in a few
195 2015-10-16 21:59:54 <cfields> sdaftuar: understood and agreed on all counts
196 2015-10-16 23:34:39 <PRab> Anyone have any ideas about https://github.com/bitcoin/bitcoin/issues/6840? I'm still stuck.
197 2015-10-16 23:35:01 <PRab> Oops, I meant to put that in #bitcoin.