1 2015-03-26 00:10:51 <Luke-Jr> sipa: do we automatically reconsiderblock if it was rejected for time being too new?
  2 2015-03-26 00:11:15 <sipa> Luke-Jr: no need
  3 2015-03-26 00:11:34 <sipa> Luke-Jr: being too new does not mark the block as invalid
  4 2015-03-26 00:11:46 <sipa> it just doesn't accept it
  5 2015-03-26 00:11:49 <Luke-Jr> hm, just temporarily prevents it from being considered for best?
  6 2015-03-26 00:12:22 <sipa> no, it temporarily prevents it from being accepted into our database
  7 2015-03-26 00:12:31 <sipa> like, not in ram, not on disk, not validated, ...
  8 2015-03-26 00:13:01 <Luke-Jr> i c
  9 2015-03-26 00:13:16 <sipa> reconsiderblock is for retrying a block index entry that is known but marked as permanently invalid
 10 2015-03-26 01:31:39 <evoskuil> sipa: How one is allowed to spend/receive money has quite a bit to do with free speech, even if limited to SCOTUS precedent.
 11 2015-03-26 02:09:39 <fanquake> ;;blocks
 12 2015-03-26 02:09:40 <gribble> 349262
 13 2015-03-26 07:17:57 <wumpus> <petertodd> sipa: well... if the blockchain had more uses than purely finance we'd be in a better position, maybe <- hah, add more baby to the bathwater for moral defense
 14 2015-03-26 07:45:04 <hno> petertodd, but it does have more uses than purely finance..
 15 2015-03-26 08:04:49 <wumpus> I don't think you need to tell petertodd that
 16 2015-03-26 13:04:06 <JackH> arent we just waiting for sidechains to be "done"?
 17 2015-03-26 13:04:14 <JackH> and then all these problems are over with
 18 2015-03-26 13:45:48 <jonasschnelli> regarding accounts and wallet-ng. What would changing accounts to labels mean? IMO we should then remove also balance by account/label, etc. Labels should only be a text-addition for addresses.
 19 2015-03-26 14:50:09 <wumpus> jonasschnelli: I have posted on github about that a few times: demoting accounts to labels would indeed mean getting rid of balance per account, as well as the 'account address', as well as a few calls such as 'move'
 20 2015-03-26 14:50:52 <wumpus> labels are just an identifier for addresses
 21 2015-03-26 14:51:10 <gmaxwell> instead you should get listtransactions by labels, and recieved/sent by labels.
 22 2015-03-26 14:59:15 <wumpus> right, those wouldn't really change
 23 2015-03-26 15:16:00 <morcos> i think i figured out what was causing the assert fail reported in the autoprune pull, 5863.  can one of you help me think of what the right solution is?
 24 2015-03-26 15:16:51 <morcos> in the middle of connect block, we write undo information, if pruning happened there, we'd be flushing pcoinsTip, while we have another view that is backed by it, so the assumption that things will be in the cache of pcoinsTip is broken
 25 2015-03-26 15:17:17 <morcos> when we flush the view used in connect block after its connected
 26 2015-03-26 16:06:30 <gmaxwell> gavinand1esen: So the additional thread in 'ThreadSybilCheck' is another ~16mbytes of memory usage. It would be preferable to handle that without adding another thread; also, why add another boost dependency just to get a constant?  Last nit: it really should be called partitioncheck or something other than sybilcheck.
 27 2015-03-26 16:07:11 <gavinand1esen> gmaxwell: 16 megabytes for a thread?  really?
 28 2015-03-26 16:08:00 <gavinand1esen> … back later, lunch now...
 29 2015-03-26 16:39:58 <Eliel> Is there an RPC call to get the "reverse" of listsinceblock? That is, get a list of all wallet transactions with less than X confirmations.
 30 2015-03-26 16:58:29 <Luke-Jr> gavinand1esen: stack space; maybe there's a way to reduce it for some threads, but that complicates things
 31 2015-03-26 17:08:09 <dabura667> Question on refund_to in the Payment message of BIP70... is this required for the client to send to the merchant or is it optional? If the latter is there a way to require it?
 32 2015-03-26 17:12:24 <Luke-Jr> dabura667: you can require it by refusing to acknowledge a payment missing it
 33 2015-03-26 17:14:16 <dabura667> Luke-Jr: so if I ignored their payment, they would automatically retry with a refund output attached? Is that the standard for clients? (I can't find that mentioned in the BIP)
 34 2015-03-26 17:14:35 <Luke-Jr> dabura667: don't ignore it, send a rejection of it
 35 2015-03-26 17:14:48 <Luke-Jr> I don't know of any software that attempts to do a refundless payment, though
 36 2015-03-26 17:15:14 <gavinand1esen> gmaxwell: okey dokey… so do we have a scheduler of any sort in the code already?  Or how would you implement an I-want-something-to-happen-every-N-seconds task?
 37 2015-03-26 17:16:35 <dabura667> ok, so sending the refund output is standard for clients, and if there is no refund output then I send back a rejection response to their request... I think I got it. Thanks.
 38 2015-03-26 17:18:12 <IngCr3at1on> does anyone know why a gitian build would give an error with apt-get and held packages while apt itself works fine outside of gitian?
 39 2015-03-26 17:24:50 <Luke-Jr> oh, lovely. master doesn't build :<
 40 2015-03-26 17:36:01 <gavinand1esen> Luke-Jr gmaxwell: on what OS does a new boost::thread take 16MB of memory? And are you talking allocated or resident? I’m not seeing any effect on resident set size on OSX…
 41 2015-03-26 17:36:31 <sipa> Luke-Jr: what fails on master?
 42 2015-03-26 17:38:45 <gavinand1esen> hmm, looks like 72MB of virtual memory on 64-bit linux, but that’s just make-pretend memory… http://stackoverflow.com/questions/12135226/boost-thread-memory-usage-on-64bit-linux
 43 2015-03-26 17:38:53 <Shark0> I want some help with understanding HashCash algorithm , is there anybody that can guide me ?
 44 2015-03-26 17:40:17 <sipa> gavinand1esen: on 32-bit, several MB of virtual memory may be undesirable due to address space limitations
 45 2015-03-26 17:40:26 <sipa> gavinand1esen: i don't know the effect on resident memory
 46 2015-03-26 17:40:50 <sipa> gavinand1esen: but it may make sense to have a simple event handler thread for short, scheduled tasks (like wallet locking, for example)
 47 2015-03-26 17:41:18 <gavinand1esen> sipa: “premature optimization is the root of all evil” or something….
 48 2015-03-26 17:41:45 <gavinand1esen> … and I vote we drop support for 32-bit machines.
 49 2015-03-26 17:41:45 <sipa> gavinand1esen: i mean: we _already_ have a thread
 50 2015-03-26 17:41:53 <gmaxwell> gavinand1esen: the 16mb was approximate, I know from the dnsseeder thread that it was a couple megabyte rss and a whole lot of virt. We already have other periodic processing in a thread.
 51 2015-03-26 17:42:18 <sipa> gavinand1esen: i definitely do not vote to drop it; 32-bit ARM devices are pretty interesting as a target
 52 2015-03-26 17:42:50 <gavinand1esen> gmaxwell: ok, happy to hijack some other thread.  It just isn’t clear to me which one to hijack....
 53 2015-03-26 17:43:01 <sipa> gavinand1esen: let me hack something up
 54 2015-03-26 17:43:17 <sipa> when i get checkblockindex working
 55 2015-03-26 17:43:25 <Luke-Jr> sipa: bisecting it now
 56 2015-03-26 17:43:41 <gmaxwell> gavinand1esen: I don't even know that it needs to be a periodic process... this test could be run whenever a block is accepted, no? (as confirm count will only go up at that time)
 57 2015-03-26 17:43:55 <gavinand1esen> gmaxwell: no
 58 2015-03-26 17:44:08 <Luke-Jr> gavinand1esen: not only 32-bit machines run with 32-bit address space
 59 2015-03-26 17:44:11 <gavinand1esen> gmaxwell: it must run even when no new blocks come in, that’s the point
 60 2015-03-26 17:44:39 <gmaxwell> gavinand1esen: if no blocks at all have come in you won't see anything as confirmed though.
 61 2015-03-26 17:44:45 <Luke-Jr> gavinand1esen: the new amd64 "x32" ABI, for example, only works on 64-bit hardware, but only has 32-bit address space for applications
 62 2015-03-26 17:44:59 <gmaxwell> (so I thought it was for 'few' blocks rather than 'none')
 63 2015-03-26 17:45:04 <gavinand1esen> It seems to me the REFERENCE IMPLEMENTATION should be aiming for secure, easy-to-audit code.  And it seems to me having separate threads is the most straightforward, easy-to-see-correct way to do that.
 64 2015-03-26 17:45:48 <gavinand1esen> It also seems to me there is a lot of premature optimization happening here....
 65 2015-03-26 17:46:22 <gmaxwell> gavinand1esen: one of the main blockers for usage has been (and continues) to be memory usage.  You're talking about adding a signficant memory overhead for a very narrow feature, which can be _easily_ avoided.
 66 2015-03-26 17:47:12 <gavinand1esen> I still don’t follow— are you saying that we’re near the 32-bit virtual memory limit, and an extra X GB of VM allocation will put us over?
 67 2015-03-26 17:47:17 <Luke-Jr> gmaxwell: main blocker is memory usage or address space? I've never seen the latter as an issue afaik
 68 2015-03-26 17:47:29 <gmaxwell> gavinand1esen: Both are true.
 69 2015-03-26 17:48:01 <gavinand1esen> … excuse me, X MB….
 70 2015-03-26 17:48:03 <Luke-Jr> actually, I suppose the bad_alloc issue should be address space.. I wonder why I get it only on ARM
 71 2015-03-26 17:48:13 <gmaxwell> Luke-Jr: we've had quite a few reports of VM exhaustion from 32 bit folks.
 72 2015-03-26 17:48:21 <gavinand1esen> 32-bit machines would be falling down as the mempool gets too big if we were near that limit, right?
 73 2015-03-26 17:48:22 <Luke-Jr> hm
 74 2015-03-26 17:48:24 <gmaxwell> (on IRC, in the 0.10 release announcment thread)
 75 2015-03-26 17:49:08 <Luke-Jr> master build issue: 4414f5ffe130f46becdc75c8e59ee74604e978aa is the first bad commit: build: Endian compatibility
 76 2015-03-26 17:49:21 <gavinand1esen> Has anybody looked at what is using 4GB of memory?
 77 2015-03-26 17:50:45 <cfields> Luke-Jr: what build issue?
 78 2015-03-26 17:50:47 <gmaxwell> gavinand1esen: 3GB (kernel+userland split means you only get 3GB virt on 32bit); virt consumption overhead seems to be largely a mix of threads and fragmentation. When you measure it be sure to actually use a 32 bit build, the 64bit ones blow through virt with mmaps.
 79 2015-03-26 17:50:52 <Luke-Jr> cfields: it's trying to redefine htobe*
 80 2015-03-26 17:51:24 <gavinand1esen> gmaxwell: I’m not going to measure it, I think supporting 32-bit is a waste of time.  I vote we drop support for 32-bit.
 81 2015-03-26 17:51:30 <cfields> Luke-Jr: grr... delete src/bitcoin-config.h
 82 2015-03-26 17:51:53 <gmaxwell> I disagree strongly.
 83 2015-03-26 17:52:12 <sipa> x86 32-bit is dying out, but it's hardly the only relevant 32-bit platform
 84 2015-03-26 17:52:15 <cfields> blah, i suspected that wasn't an isolated issue.. bug was reported a while back
 85 2015-03-26 17:52:26 <Luke-Jr> cfields: didn't help
 86 2015-03-26 17:52:28 <gmaxwell> (Because arm, otherwise I'd be more indifferent)
 87 2015-03-26 17:52:40 <sipa> and there is no reason why we couldn't run in a 32-bit address space
 88 2015-03-26 17:52:52 <gavinand1esen> gmaxwell: okey dokey.  I think life is too short to try to support every hardware platform in the world. And our resources are stretched too thin....
 89 2015-03-26 17:53:17 <gmaxwell> Also, the issue there isn't fundimental. It's not like we have any need to use anywhere near 3gb of ram.
 90 2015-03-26 17:53:27 <cfields> Luke-Jr: make clean and rebuild. i strongly suspect that should've fixed
 91 2015-03-26 17:53:28 <Luke-Jr> gavinand1esen: so we should only support /one/ platform, that people are working on obsoleting?
 92 2015-03-26 17:53:50 <Luke-Jr> cfields: nope, same issue
 93 2015-03-26 17:54:07 <gavinand1esen> Luke-Jr: no, not /one/ platform….
 94 2015-03-26 17:54:35 <sipa> gavinand1esen: bitcoin core is not just a reference implementation right now; there is no way afaik to get something remotely consensus safe using any other implementation
 95 2015-03-26 17:54:37 <Luke-Jr> there's only one platform I know of with any use and 64-bit address space
 96 2015-03-26 17:54:51 <gavinand1esen> So, what I’m hearing:  we’re broken on 32-bit systems right now.  We don’t know why, really.  And so… something something new threads are bad.
 97 2015-03-26 17:55:10 <sipa> gavinand1esen: if there were a complete consensus library and actual other implementations using it, they could have a different focus
 98 2015-03-26 17:55:15 <gmaxwell> gavinand1esen: If thats what you're hearing then you're not listening in here.
 99 2015-03-26 17:55:40 <sipa> but right now i don't think we should just gratuitously throw away support for a very widely deployed class of hardware
100 2015-03-26 17:55:43 <gavinand1esen> gmaxwell: do you know for sure how much VM space a new boost::thread uses on 32-bit systems?
101 2015-03-26 17:56:03 <cfields> we're broken on 32bit? some reference i can look at?
102 2015-03-26 17:56:07 <sipa> not broken
103 2015-03-26 17:56:20 <sipa> but we're clearly wasting virtual memory
104 2015-03-26 17:56:30 <cfields> oh
105 2015-03-26 17:56:38 <gmaxwell> gavinand1esen: 32bit works. It's right on address space. The main users of address space are threads and general fragmentation. We've improved things in the past several releases by moving off mmap on 32bit and elimiating a few threads that weren't needed. Fragmentation has been improved somewhat, but there are still lots of scattered small heap allocations.
106 2015-03-26 17:57:20 <sipa> gavinand1esen: i'll whip up a simple "scheduler" thread
107 2015-03-26 17:57:30 <gmaxwell> All these improvements also had other benefits, ignoring 32bits commercial use of bitcoin is discouraged by many parties and a frequently cited reason is that it will not run in small VPSes due to RSS.
108 2015-03-26 17:57:34 <morcos> sipa: I wasn't sure of the assumptions that go into the CoinsViewCache's, but I made some changes here: https://github.com/bitcoin/bitcoin/compare/master...morcos:AlterBatchWrite
109 2015-03-26 17:57:53 <morcos> sipa: I didn't want to submit a PR if this is completely the wrong direction
110 2015-03-26 17:57:57 <Luke-Jr> cfields: I think autogen fixes it, which means the problem is Makefile not regenerating stuff when needed
111 2015-03-26 17:58:28 <morcos> sipa: But it seems a bit brittle that they break if an intermediate cache is flushed
112 2015-03-26 17:58:32 <cfields> Luke-Jr: autogen just rebuilds configure.. did you have to reconfigure too?
113 2015-03-26 17:58:51 <Luke-Jr> cfields: make is at least smart enough to rerun configure
114 2015-03-26 17:59:05 <morcos> sipa: Perhaps an alternative would be to make it so thats not easy to do, if we don't want to allow it
115 2015-03-26 17:59:13 <gmaxwell> gavinand1esen: I don't think we should be having a big fight just because I said "please don't spin up a whole new thread just for some inexpensive and low value partitioning check which will run only once per ten minutes" ... there are a dozen other ways to handle it, and other periodic processes it could run along.
116 2015-03-26 17:59:20 <Luke-Jr> cfields: usually make can remake configure as well.. not sure why that didn't work here
117 2015-03-26 17:59:26 <morcos> sipa: This I think would fix the problem in #5863
118 2015-03-26 18:00:07 <gavinand1esen> gmaxwell: sure… and a scheduler thread is a great idea. If your comment was “great work.  We should do a future pull request to schedule these little tasks more efficiently”  I’d be a happy camper
119 2015-03-26 18:01:00 <sipa> morcos: i'll look later; i first really want this checkblockindex working
120 2015-03-26 18:01:11 <sipa> morcos: and i probably want  some input from you guys about it once it works
121 2015-03-26 18:01:27 <gavinand1esen> It feels like we make approximately zero progress because perfect is always enemy of the better around here.......
122 2015-03-26 18:01:30 <gmaxwell> I don't think this is worth taking with the current implementation. Feel free to go include it in BitcoinXT.
123 2015-03-26 18:01:46 <gmaxwell> gavinand1esen: You've been almost completely absentee from the project for months.
124 2015-03-26 18:02:04 <gmaxwell> gavinand1esen: Don't show up here bitching about zero progress over a trivial change with a crappy high overhead implementation.
125 2015-03-26 18:02:38 <morcos> sipa: sure happy to look although i'll be pretty off grid from Fri morning to Monday evening EDT
126 2015-03-26 18:03:18 <gmaxwell> gavinand1esen: I'm happy to figure out how to do it better; I could have just responded on the PR with "NAK what is this crap, haven't you been paying attention at all the work _reducing_ this kind of rubbish in the codebase?"  and now I'm wishing I had, considering your response.
127 2015-03-26 18:04:09 <gavinand1esen> gmaxwell: okey dokey
128 2015-03-26 18:04:45 <gavinand1esen> gmaxwell: you’re right, I didn’t get the memo to avoid boost::threads…
129 2015-03-26 18:04:50 <Luke-Jr> sigh
130 2015-03-26 18:18:40 <Luke-Jr> cfields: anyhow, for some reason autoheader isn't updating the bitcoin-config.h.in file when configure.ac changes :/
131 2015-03-26 18:19:06 <cfields> Luke-Jr: you're sure you're looking at config/bitcoin-config.h ?
132 2015-03-26 18:19:17 <Luke-Jr> cfields: src/config/bitcoin-config.h, yes
133 2015-03-26 18:19:37 <cfields> Luke-Jr: well, it only updates it if something changes
134 2015-03-26 18:19:42 <Luke-Jr> cfields: go to a pre-bigendian commit, autogen, then go to master and make
135 2015-03-26 18:20:00 <Luke-Jr> cfields: configure.ac changes when you cross the bigendian commit
136 2015-03-26 18:20:15 <cfields> Luke-Jr: you have to re-configure to get the new defines picked up
137 2015-03-26 18:20:38 <cfields> or are you saying that's the part it should've figured out?
138 2015-03-26 18:21:22 <Luke-Jr> cfields: whatever should have been done, 'make' should do it ;)
139 2015-03-26 18:23:11 <cfields> Luke-Jr: i agree with that, but in general, i've always found 'make' not smart enough to properly handle the need to re-autogen. Not arguing with you, but that's the current state of autoconf imo
140 2015-03-26 18:23:30 <Jushe> Hello
141 2015-03-26 18:23:36 <Luke-Jr> I've had the opposite experience with make - it always gets configure.ac updates fine in my projects :/
142 2015-03-26 18:24:01 <Luke-Jr> although admittedly I've never looked to see if the autoheader part specifically worked
143 2015-03-26 18:24:14 <Luke-Jr> (but also not noticed any issues)
144 2015-03-26 18:26:27 <Luke-Jr> jgarzik_: ping
145 2015-03-26 18:28:04 <Luke-Jr> jgarzik_: is there a reason bitcoin-tx.cpp:MutateTxSign uses STANDARD_SCRIPT_VERIFY_FLAGS rather than MANDATORY?
146 2015-03-26 18:45:03 <morcos> sipa: is there something not working about checkblockindex now?  other than slowness..  just started trying it out
147 2015-03-26 18:46:22 <sipa> morcos: travis fails
148 2015-03-26 19:20:46 <morcos> sipa: one comment is that in an autoprune world, this won't hold right? assert((pindexFirstMissing != NULL) == (pindex->nChainTx == 0))
149 2015-03-26 22:28:28 <gimme_bottles> Hello, are there pcap files of bitcoin traffic somewhere? I am currently updating the bitcoin wireshark dissector and am looking for a way to test my work.
150 2015-03-26 22:30:54 <lechuga_> u could install the client and sync testnet
151 2015-03-26 22:31:37 <petertodd> also, bitcoin wallet for android lets you set what node it connects to to check SPV
152 2015-03-26 22:31:51 <lechuga_> https://bitcoin.org/en/full-node
153 2015-03-26 22:42:48 <akstunt600> sure plenty, Google bitcoin pcap
154 2015-03-26 22:54:26 <gimme_bottles> my node is syncing right now, but I don't get any reject or notfound messages...
155 2015-03-26 22:55:17 <gimme_bottles> All the bitcoin pcaps I found via Google are too old to contain the new messages, so they don't help much.
156 2015-03-26 23:02:35 <lechuga_> you could also sniff regtest in action w/the bitcoind comparison tool
157 2015-03-26 23:41:53 <familiar_> ThomasV: can I ask a question about cosigner pool?
158 2015-03-26 23:42:07 <ThomasV> sure
159 2015-03-26 23:42:11 <familiar_> Two questions actually. 1) Is it only limited to one server (ecdsa.net) which has support for the protocol?
160 2015-03-26 23:42:20 <familiar_> 2) Will it 'save' a transaction for me if I'm offline ?
161 2015-03-26 23:42:38 <ThomasV> yes and yes
162 2015-03-26 23:42:50 <familiar_> Awesome! So it's an IM system :)
163 2015-03-26 23:43:09 <familiar_> I love this idea btw
164 2015-03-26 23:43:11 <ThomasV> sort of
165 2015-03-26 23:43:28 <familiar_> Is there anything verifying that it's a valid multisig txn ?
166 2015-03-26 23:43:41 <familiar_> since it's encrypted I don't see how that is possible
167 2015-03-26 23:43:49 <ThomasV> no, it can be abused
168 2015-03-26 23:44:06 <familiar_> So. This is what I was thinking
169 2015-03-26 23:44:59 <ThomasV> the server code is trivial, btw
170 2015-03-26 23:46:31 <familiar_> Could i technically create a plugin that puts multisig as per BIP45 into your main ("stanard") wallet?
171 2015-03-26 23:47:04 <familiar_> For me, the fact that you have to create a separate .dat file for multisig, and for each tuple of (X1,X2,X3), is a bit of a hassle
172 2015-03-26 23:47:51 <familiar_> I understand that there are certain security benefits, and it also models the "shared" wallet idea of multisig. But I'm looking for the customer-vendor-arbiter model
173 2015-03-26 23:48:59 <ThomasV> I guess you can create it
174 2015-03-26 23:49:14 <ThomasV> but I would probably not distribute it
175 2015-03-26 23:49:36 <familiar_> Yeah, I can imagine. But you don't see any big issue here that I'm missing right?
176 2015-03-26 23:50:13 <ThomasV> see here why: https://github.com/spesmilo/electrum/blob/master/plugins/README
177 2015-03-26 23:50:20 <familiar_> If I'm deriving the xpubkeys using m/45'/xx then there's no way to go back from the signing keys to my main xpubkey
178 2015-03-26 23:53:13 <ThomasV> so you want cosigners xprv to be derived from the same root?
179 2015-03-26 23:53:43 <ThomasV> why?
180 2015-03-26 23:53:46 <familiar_> Each person shares his M/45'
181 2015-03-26 23:54:05 <ThomasV> oh ok
182 2015-03-26 23:54:06 <familiar_> Then, one person decides to create a transaction. He derives M/45'/(his-index)/0/0 from each of the xpubs
183 2015-03-26 23:54:18 <familiar_> from these pubkeys he creates the redeem scripts, and the 3xx address
184 2015-03-26 23:54:33 <familiar_> everyone else can derive their own privkeys based on the same derivation path
185 2015-03-26 23:54:45 <ThomasV> why is 'his-index' needed?
186 2015-03-26 23:56:25 <familiar_> To prevent race conditions. Since each cosigner is unaware of the activities of the others in real-time
187 2015-03-26 23:57:04 <familiar_> (Not my invention btw- this is what BIP45 describes)
188 2015-03-26 23:57:40 <ThomasV> I don't get that part.. what kind of race conditions?
189 2015-03-26 23:59:31 <familiar_> Imagine that over time X1,X2,X3 are doing multiple transactions with each other. To generate each new 3xx address they need to increment the index, but then they have the problem of keeping this index in sync
190 2015-03-26 23:59:52 <familiar_> If one of them falls off sync or is unaware of one of the txn's - they risk reusing previous addresses