1 2015-05-19 00:02:13 <ajweiss> if travis fails and it appears to be transient/unrelated, do you guys prefer if it is tickled with a whitespace change, or instead should people come here and ask for it to be kicked?
  2 2015-05-19 00:05:35 <belcher> is it right that the plan is for bitcoin core to have its wallet functions seperated?
  3 2015-05-19 00:06:04 <belcher> as in, am i correct in thinking that? not whether its morally right or something
  4 2015-05-19 00:19:45 <Luke-Jr> belcher: yesish.
  5 2015-05-19 00:20:22 <belcher> any ideas for how joinmarket might eventually be added?
  6 2015-05-19 00:20:34 <belcher> wait for the new wallet, which might have a plugin system or something
  7 2015-05-19 00:20:38 <Luke-Jr> ajweiss: neither? just amend the commit with no changes and forcepush?
  8 2015-05-19 00:20:56 <Luke-Jr> belcher: jonasschnelli might be the one to talk to
  9 2015-05-19 00:21:22 <belcher> because he knows a lot about the wallet code?
 10 2015-05-19 00:23:07 <ajweiss> yep, got it.  thanks!
 11 2015-05-19 00:44:43 <jgarzik> ajweiss, agree w/ luke-jr
 12 2015-05-19 00:45:08 <Luke-Jr> belcher: he's writing the new wallet code I guess
 13 2015-05-19 00:45:16 <belcher> ok cool
 14 2015-05-19 00:45:27 <belcher> ill get in touch, i assume he's asleep now
 15 2015-05-19 00:45:30 <belcher> and im leaving too
 16 2015-05-19 00:45:33 <belcher> cheers
 17 2015-05-19 00:45:44 <Luke-Jr> by "yesish", I mean "supposedly that's the goal, but it isn't how jonasschnelli appears to be going about it so far"
 18 2015-05-19 00:46:21 <belcher> how is he going about it?
 19 2015-05-19 00:46:31 <belcher> how does he appear to be going about it?
 20 2015-05-19 00:47:36 <PRab> belcher: https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3AWallet+author%3Ajonasschnelli+
 21 2015-05-19 00:47:51 <belcher> ty
 22 2015-05-19 01:04:14 <phantomcircuit> belcher, just a head sup at various times a number of people have said they were going to rewrite the wallet
 23 2015-05-19 01:04:27 <phantomcircuit> some of that lead to incremental improvements
 24 2015-05-19 01:04:32 <phantomcircuit> but nothing revolutionary yet
 25 2015-05-19 01:04:34 <belcher> hmm
 26 2015-05-19 01:05:29 <belcher> not sure where to go with the joinmarket thing, just stuck to other wallets for now i guess
 27 2015-05-19 01:06:10 <phantomcircuit> also the logdb.cpp he seems to be using is just as broken as the leveldb one is
 28 2015-05-19 01:06:27 <belcher> core doesnt even have deterministic wallets yet, i imagine energies are spent on far higher priorities
 29 2015-05-19 01:06:52 <phantomcircuit> belcher, a recurring theme has been that there are more important things to do today
 30 2015-05-19 01:07:17 <phantomcircuit> belcher, write an spv client that refuses to run unless it can access bitcoind rpc on localhost
 31 2015-05-19 01:07:26 <phantomcircuit> magic you have fullnode security with an spv client
 32 2015-05-19 01:07:30 <belcher> well its true, there are other bitcoin wallets that work, the other core dev issues are also really important
 33 2015-05-19 01:07:33 <phantomcircuit> (or at least something very close)
 34 2015-05-19 01:07:48 <belcher> phantomcircuit yeah thats already kinda done, except the refusing to operate
 35 2015-05-19 01:07:58 <belcher> its a wallet on the command line, with not many features, but a wallet nonetheless
 36 2015-05-19 03:22:38 <SeXploit> yo
 37 2015-05-19 03:22:41 <SeXploit> yo
 38 2015-05-19 06:04:29 <wumpus> belcher phantomcircuit the best way to help the wallet forward at this point is to test @jonasschnelli's open pulls, especially the more experimental ones
 39 2015-05-19 06:05:40 <phantomcircuit> wumpus, i can say without a doubt the logdb thing is wrong
 40 2015-05-19 06:05:44 <phantomcircuit> it needs a counter
 41 2015-05-19 06:10:23 <Luke-Jr> wumpus: I think belcher just wanted to focus on his CoinJoin stuff, more than get involved with the new wallet itself
 42 2015-05-19 06:13:35 <wumpus> Luke-Jr: one step at a time though
 43 2015-05-19 06:14:26 <Luke-Jr> yeah
 44 2015-05-19 06:14:48 <Luke-Jr> (although I still think the logical first step does not involve modifying Bitcoin Core)
 45 2015-05-19 06:15:50 <wumpus> the pipeline for wallet pulls has always been difficult; still need more people to review or test them, and my point is that it helps more to move the current pipeline forward than add more changes (which may otherwise sit there for a long time)
 46 2015-05-19 06:16:57 <moa> asking coders to be testers is a little optimistic :p
 47 2015-05-19 06:16:59 <wumpus> well, coinjoin outside bitcoin core has already been possible for a while, though I don't think any system has been particularly succesful
 48 2015-05-19 06:17:52 <Luke-Jr> it's complicated enough that I'm not apt to use it for every transaction.
 49 2015-05-19 06:18:55 <wumpus> moa: asking coders to be reviewers on the other hand should be natural, if you can write the code you can also review it
 50 2015-05-19 06:20:57 <phantomcircuit> wumpus, tbh i think the bitcoin core wallet should be spun off into a separate binary...
 51 2015-05-19 06:21:16 <wumpus> anyhow, I'm just stating how things are, and how people interested helping things forward could do so
 52 2015-05-19 06:22:50 <wumpus> phantomcircuit: well once someone adds SPV functionality that would be easy.
 53 2015-05-19 06:23:05 <wumpus> phantomcircuit: it's not rally interesting what you think should be done, unless you help doing it
 54 2015-05-19 06:24:48 <phantomcircuit> wumpus, k
 55 2015-05-19 06:24:52 <wumpus> all I want to hear here is "I want to work on A" and "I have done B", not "I want A", this is an open source project not a wish fulfullment service :p
 56 2015-05-19 06:25:15 <phantomcircuit> i've indicated i wanted to do this several times over the years and each time someone else was working on it
 57 2015-05-19 06:25:19 <phantomcircuit> and then nothing happened
 58 2015-05-19 06:25:38 <wumpus> maybe it's time to take initiative instead of wait. Waiting is about the least contructive thing you can do.
 59 2015-05-19 06:26:13 <wumpus> no, no one else is working on it
 60 2015-05-19 06:30:41 <Luke-Jr> phantomcircuit: ideally, there would be a SPV library and a wallet library and a binary to tie them together with a GUI :P
 61 2015-05-19 06:30:42 <wumpus> I don't think anyone ever has worked on it, just voiced plans to do so at some undefined time in the future
 62 2015-05-19 06:32:26 <wumpus> (although headers-first was a necessary step there)
 63 2015-05-19 06:33:35 <wumpus> (and many steps along the way have been made; it should be easier to do than ever before)
 64 2015-05-19 07:00:10 <phantomcircuit> michagogo, i do
 65 2015-05-19 07:00:19 <phantomcircuit> i even use the WoT to validate them
 66 2015-05-19 07:00:54 <michagogo> phantomcircuit: I'm talking about the OS X detatched signature
 67 2015-05-19 07:01:23 <phantomcircuit> os x? nobody checks anything
 68 2015-05-19 07:02:27 <moa> apple's got your back
 69 2015-05-19 07:05:38 <michagogo> ...wtf?
 70 2015-05-19 07:05:43 <michagogo> Terminal is crashing
 71 2015-05-19 07:12:16 <michagogo> ...and now it's telling me there's "an internal error"
 72 2015-05-19 07:14:02 <michagogo> WTF?
 73 2015-05-19 07:14:07 <michagogo> Somehow, I broke something
 74 2015-05-19 07:14:28 <michagogo> I opened a terminal and it didn't export the usual environment variables
 75 2015-05-19 07:14:42 <michagogo> ran `ls ~` and Terminal just crashed...
 76 2015-05-19 07:14:49 <michagogo> ...wtf?
 77 2015-05-19 07:16:29 <michagogo> wait, what
 78 2015-05-19 07:16:40 <michagogo> ls ~ works, as does ls -l
 79 2015-05-19 07:16:43 <michagogo> but ls -a crashes?
 80 2015-05-19 07:18:47 <Luke-Jr> figure out why, get Bitcoin Core to replicate it for the wallet directory, and watch heads roll <.<
 81 2015-05-19 07:29:25 <michagogo> cfields: btw, Chrome doesn't like the ssl cert on bitcoincore.org
 82 2015-05-19 07:29:34 <michagogo> Because of SHA1, I think
 83 2015-05-19 07:31:49 <michagogo> Yeah, https://www.ssllabs.com/ssltest/analyze.html?d=bitcoincore.org says it's the sha1
 84 2015-05-19 07:32:14 <phantomcircuit> michagogo, the push for sha1 seems a bit premature...
 85 2015-05-19 07:44:16 <wumpus> michagogo: I didn't get further than that it contains, apart from some empty directories, only a Bitcoin-Qt.sign
 86 2015-05-19 07:44:35 <michagogo> wumpus: it also has an xml document, I think
 87 2015-05-19 07:44:40 <michagogo> (I just looked)
 88 2015-05-19 07:45:41 <wumpus> no, no xml file. only Apple knows why the .sign file is 121kB, probably it contains a chain of signatures not just one
 89 2015-05-19 07:46:23 <wumpus> oh you're right "CodeResources"
 90 2015-05-19 08:07:19 <cfields> i always verify after signing
 91 2015-05-19 08:07:52 <cfields> you can verify the .app with "codesign -vvv foo.app"
 92 2015-05-19 08:08:46 <cfields> if you're saying "check that the modifications aren't malicious", verifying the .app sig should be pretty good confirmation
 93 2015-05-19 08:10:02 <cfields> wumpus: the file is 121k because it breaks the binaries into small blocks and signs each one
 94 2015-05-19 08:11:47 <cfields> we could shrink it down to a single block-size (codesign --pagesize=0), but i chose to stick with defaults rather than risking that some future OSX update might not like that for some crazy reason
 95 2015-05-19 08:15:12 <cfields> the cert chain is stuffed in there as well obviously. There are OSX tools that can be used to pull the certs back out. But unfortunately, no native tool to rip the sig out into a common format
 96 2015-05-19 08:45:58 <dusty__> Hello, I'm using bitcoind in regtest mode, and giving the command "bitcoin-cli sendtoaddress 2N5eHYCZsKHec4xmhwSkQDesKjhWoBfxWEn 1" after some seconds I get the error "error: {"code":-4,"message":"Transaction too large"}"
 97 2015-05-19 08:46:10 <dusty__> I suppose this is a bug of bitcoind (?)
 98 2015-05-19 08:47:12 <dusty__> if someone thinks that some kind of debug could be useful just tell me what to do, otherwise I'll erase the regtest chain and start with a fresh one
 99 2015-05-19 08:56:10 <dusty__> (using bitcoin core v0.10.1.0-gd8ac901)
100 2015-05-19 08:56:56 <michagogo> dusty__: pastebin the output of listunspent?
101 2015-05-19 08:57:26 <michagogo> I wonder if it may be because you have too much dust and not enough other stuff
102 2015-05-19 08:57:57 <michagogo> (in other words, it can't reach 1 BTC without using too many inputs, to the point where the tx gets too big)
103 2015-05-19 09:05:24 <michagogo> GAH
104 2015-05-19 09:07:27 <michagogo> I just lost two hours because I used `tar xf` on that signature.tar.gz in /tmp
105 2015-05-19 09:08:06 <michagogo> It clobbered the permissions on /tmp, setting it to 501:staff, rwxr-xr-x
106 2015-05-19 09:17:01 <wumpus> it tries to combine too many inputs, resulting in a transaction that is too large - the usual reason is that you have lots of small dust in your wallet
107 2015-05-19 09:17:56 <wumpus> what might help is sending a few smaller transactions to yourself first, e.g. consolutate inputs
108 2015-05-19 09:25:59 <michagogo> cfields: ...is that because of something about the way you do it? Or is it just like that for all tarballs?
109 2015-05-19 09:26:14 <michagogo> I don't think I've ever had this happen before
110 2015-05-19 09:28:09 <cfields> michagogo: something similar happened with our linux tarball a while back, iirc because of the way we use 'find' to create the tarballs with deterministic ordering
111 2015-05-19 09:28:23 <cfields> as a result, '.' slipped in there. Sounds like the same thing's happening here
112 2015-05-19 09:29:20 <cfields> sorry 'bout that. I'll have a look tomorrow, probably just need to change it the same way we changed the first one
113 2015-05-19 09:30:43 <cfields> (though, i would've thought it would only happen if you used 'tar -p' or so)
114 2015-05-19 09:31:02 <wumpus> don't extract other people's tar files as root ;)
115 2015-05-19 09:32:44 <wumpus> apart from '.', they can contain absolute paths as well, although fortunately *that* is disabled by default at least in GNU tar
116 2015-05-19 09:34:10 <wumpus> (but I'm not sure if something like ./.../../../../../passwd would work, I'd hope not)
117 2015-05-19 09:45:31 <michagogo> cfields: no, just `tar xf`
118 2015-05-19 09:59:31 <wumpus> who would like to write something about autoprune for the 0.11 release notes? e.g. like https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.10.0.md#notable-changes
119 2015-05-19 10:00:38 <fanquake> wumpus I'll build 0.9.5rc1 tonight, so we've got some sigs
120 2015-05-19 10:02:03 <wumpus> fanquake: I'm building it too, surprisingly I still have all the dependencies
121 2015-05-19 10:03:39 <fanquake> wumpus hopefully I've still got them all laying around
122 2015-05-19 10:05:15 <dusty__> michagogo: my unspent list is indeed very long, but I can spend 10btc just fine, the problem is trying to spend just 1
123 2015-05-19 10:06:21 <dusty__> wumpus: if bitcoind is the backend for another program it's very difficult to automatize the process you describe
124 2015-05-19 10:07:03 <dusty__> shouldn't bitcoind make this process on his own?
125 2015-05-19 10:07:08 <wumpus> dusty__: it is difficult to automate *full stop*, i've had to 'defragment' my wallet at least once due to committip
126 2015-05-19 10:07:55 <wumpus> possibly, no one implemented that yet though
127 2015-05-19 10:08:16 <moa> ./bitcoind -defrag
128 2015-05-19 10:08:18 <wumpus> it could just as well be an external script, a 'wallet defragmenter' hehe
129 2015-05-19 10:08:33 <moa> nup doesn't compute
130 2015-05-19 10:08:42 <wumpus> also reduces your UTXO footprint
131 2015-05-19 10:09:27 <dusty__> if a defrag command is available then bitcoind should just call it when building a too long tx
132 2015-05-19 10:09:32 <wumpus> (on the other hand it can reduce privacy, by linking outputs that were not linked before - it's not entirely straightforward)
133 2015-05-19 10:09:41 <dusty__> the problem is I can't rely on bitcoind for my payments
134 2015-05-19 10:11:12 <wumpus> you could help testing https://github.com/bitcoin/bitcoin/pull/4906, it purports improving output selection
135 2015-05-19 11:02:49 <gribble> The operation succeeded.
136 2015-05-19 11:02:49 <jonasschnelli> ;;later tell thebluematt again some nativ comparison tool travis failures: https://travis-ci.org/bitcoin/bitcoin/jobs/63138170 thanks for looking at this
137 2015-05-19 11:03:21 <jonasschnelli> ;;later tell cdecker http://bitcoinstats.com is offline again. :)
138 2015-05-19 11:03:22 <gribble> The operation succeeded.
139 2015-05-19 11:24:28 <jonasschnelli> hah: https://github.com/bitcoin/bitcoin/commit/e2e7f9513fc77a4659da0e2bfb8634c1ade3a1bb#commitcomment-11259351 ... i try to fix this becuase one of my changes introduced the warning
140 2015-05-19 11:25:02 <wumpus> I say do not bother, if diapolo can't be bothered to do his part
141 2015-05-19 11:25:15 <wumpus> there are more important issues
142 2015-05-19 11:25:23 <jonasschnelli> cfields said this should be a runtime check. But IMO we don't have any runtime checks for the platform.
143 2015-05-19 11:25:41 <jonasschnelli> wumpus: right. It's just a warning. Maybe later someone could do a warning-fixing pr like luke did
144 2015-05-19 11:26:42 <wumpus> well yes I think the idea would be to have one set if #ifdefs in one place to determine an Enum Platform, then pass that on for runtime checking in the various places that have platform dependent functionality
145 2015-05-19 11:27:36 <wumpus> (this could then also easily be overidden, for e.g. testing, and makes sure as much code as possible is compiled for all platforms - not all of course, eg the .mm files for Mac or truly Windows specific code)
146 2015-05-19 11:28:13 <jonasschnelli> wumpus: okay. But this would mean the binary includes code which is probably unused on one or more platforms
147 2015-05-19 11:28:31 <wumpus> jonasschnelli: yes
148 2015-05-19 11:28:49 <wumpus> (but only very little - these are little tweaks for different platforms)
149 2015-05-19 11:29:18 <jonasschnelli> right.
150 2015-05-19 11:31:39 <michagogo> I'm also building 0.9.5rc1
151 2015-05-19 11:31:52 <michagogo> It's taking a very long time, though, because of the lxc changes
152 2015-05-19 11:32:32 <michagogo> He changed it to use debootstrap directly for make-base-vm --lxc, but apparently that only pulls from the precise archive for some reason
153 2015-05-19 11:32:43 <michagogo> (and not from precise-{updates,security})
154 2015-05-19 11:33:11 <michagogo> So when it runs an upgrade, it needs to upgrade ~130 packages IIRC
155 2015-05-19 11:33:11 <wumpus> let's hope 0.9.5 can be the last release ever on that branch
156 2015-05-19 11:33:14 <michagogo> each and every time
157 2015-05-19 11:34:09 <wumpus> it took a long time here too (and had to do it multiple times because I was no longer used to the 0.9 way of things)
158 2015-05-19 11:34:51 <michagogo> wumpus: did you recreate your base VMs?
159 2015-05-19 11:34:55 <michagogo> Wait, no, you use KVM
160 2015-05-19 11:35:04 <michagogo> So it's just the build itself for you
161 2015-05-19 11:35:20 <wumpus> doing releases became so much more streamlined with 0.10 thanks to cfields :-)
162 2015-05-19 11:35:33 <wumpus> yes
163 2015-05-19 11:35:48 <michagogo> I still have all the deps
164 2015-05-19 11:35:58 <michagogo> It's just that the pre-build is taking a very long time
165 2015-05-19 11:37:25 <jonasschnelli> Is there a reason why the GUI uses Qt5.2.1? https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk#L2 Would like to bump this to 5.4.x (maybe after 0.11).
166 2015-05-19 12:28:44 <jeremias> btw, is there planned feature that wouldn't add unnnecessary transactions to wallet
167 2015-05-19 12:28:51 <jeremias> spent etc
168 2015-05-19 12:29:19 <jonasschnelli> jeremias define unnecessary transactions
169 2015-05-19 12:29:29 <jeremias> I set -zapwallettx, and now it takes ages to rescan, and I would guess 99% of those transactions are already spent
170 2015-05-19 12:29:47 <jeremias> jonasschnelli: already spent outputs
171 2015-05-19 12:32:58 <jonasschnelli> jeremias: cozz once wrote something into this direction: https://github.com/bitcoin/bitcoin/pull/5389
172 2015-05-19 12:33:27 <harding> wumpus: thanks for creating the 0.10.2 branch on bitcoin.org (and sorry I didn't get to it in time).  It passed all of the tests, and I made sure the preview looked good.  Would you like me to merge it now?
173 2015-05-19 12:34:26 <jonasschnelli> jeremias: but are you trying to achieve? Better performance while using your wallet?
174 2015-05-19 12:34:35 <jonasschnelli> s/but/what
175 2015-05-19 12:43:05 <laurentmt> Hi there !
176 2015-05-19 12:43:06 <laurentmt> Hi there !
177 2015-05-19 12:43:16 <laurentmt> sorry if it has been reported before
178 2015-05-19 12:43:38 <laurentmt> it seems that the logging of the channel on bitcoinstats is broken since friday
179 2015-05-19 12:43:49 <laurentmt> and I feel like an orphan ;)
180 2015-05-19 12:44:21 <jonasschnelli> laurentmt: cdecker is informed (by email) he will fix it asap.
181 2015-05-19 12:44:39 <jeremias> jonasschnelli: faster rescan when transactions are zapped
182 2015-05-19 12:44:41 <cdecker> Yeah sorry about that
183 2015-05-19 12:44:42 <cdecker> Yeah sorry about that
184 2015-05-19 12:44:47 <jeremias> however the problem is ofc quite minor, I can live with it
185 2015-05-19 12:45:13 <cdecker> One of the two bots is indeed lagging behind and I'm only monitoring the other, quite pointless actually :p
186 2015-05-19 12:45:14 <laurentmt> no problem. I wasn't sure if it has been noticed.
187 2015-05-19 12:45:32 <jonasschnelli> jeremias: why do you zap your wallet tx? (no offense. I just try to understand some things better while working on a new wallet implementation)
188 2015-05-19 12:45:33 <laurentmt> Actually I have to thank you for the service provided ! :)
189 2015-05-19 12:45:52 <cdecker> laurentmt: thanks, I'll merge the logs later today
190 2015-05-19 12:46:16 <jonasschnelli> cdecker: yes. Thanks for running bitcoinstats.com. Really appreciate my early morning log reading. :)
191 2015-05-19 12:46:29 <wumpus> harding: thanks for checking; yes I thought I'd save you some work by giving it a try myself. I think it still needs the magnet link, I did not know where to get that one
192 2015-05-19 12:47:22 <jeremias> jonasschnelli: well, it was justa safety measure... I don't know if it did make any sense to do
193 2015-05-19 12:47:25 <jeremias> *made
194 2015-05-19 12:47:26 <jeremias> *made
195 2015-05-19 12:47:48 <jeremias> I got a bug, where two transactions were sent from the same bitcoind which both used same input
196 2015-05-19 12:48:07 <jeremias> so I didn't want that to happen again
197 2015-05-19 12:48:12 <jeremias> and then I zapped the transactions
198 2015-05-19 12:48:13 <jeremias> and then I zapped the transactions
199 2015-05-19 12:48:52 <jeremias> but I wouldn't have done that, if I knew how long it would take after that...
200 2015-05-19 12:49:01 <jonasschnelli> jeremias: right. There it makes sense. And because bitcoin-core is a full-node you need to rescan through the whole blockchain which probably takes some hours.
201 2015-05-19 12:50:23 <jonasschnelli> jeremias: the main problem is, that a rescan always starts at the genesis block
202 2015-05-19 12:50:35 <jeremias> yeah, I know
203 2015-05-19 12:50:46 <jeremias> I'm quite used to rescans, they are still a lot quicker
204 2015-05-19 12:51:02 <jeremias> take less than hour or so on our hardware
205 2015-05-19 12:51:12 <jonasschnelli> it should be configurable that a -rescan starts a little bit earlier then your oldest key
206 2015-05-19 12:52:08 <harding> wumpus: the instructions for getting the magnet link should be in the 0.10.2.md file you created (download the torrent file and use transmission-show -m <torrent>).  I'll do that now and merge, and afterwards I'll try to make that part of the instructions clearer.  Thanks again!
207 2015-05-19 12:52:27 <jonasschnelli> but not all keys must have a creation timestamp, therefore – if a such feature would exists – it should only be used with caution.
208 2015-05-19 12:52:52 <jeremias> jonasschnelli: in this case it wouldn't help
209 2015-05-19 12:53:04 <jeremias> I'm quite sure that it is the transactions that cause the slowness
210 2015-05-19 12:53:14 <jeremias> and they are all in the latest blocks
211 2015-05-19 12:53:31 <jeremias> so even if I would skip the first 300k blocks, it would still take almost same time
212 2015-05-19 12:53:32 <jeremias> so even if I would skip the first 300k blocks, it would still take almost same time
213 2015-05-19 12:54:33 <jonasschnelli> jeremias: are you sure? IIRC a -rescan will check every blocks txs against all your available keys (IS_MINE check).
214 2015-05-19 12:55:24 <jonasschnelli> AddToWalletIfInvolvingMe(tx, &block, fUpdate), around L1084 in wallet.cpp
215 2015-05-19 12:55:25 <jonasschnelli> AddToWalletIfInvolvingMe(tx, &block, fUpdate), around L1084 in wallet.cpp
216 2015-05-19 12:56:22 <jeremias> yeap
217 2015-05-19 12:56:37 <jeremias> well, we have quite a lot of transactions & key in that wallet
218 2015-05-19 12:56:38 <jeremias> well, we have quite a lot of transactions & key in that wallet
219 2015-05-19 12:57:42 <jeremias> I'm watching debug.log, and it is full of AddToWallet commands
220 2015-05-19 12:57:43 <jeremias> I'm watching debug.log, and it is full of AddToWallet commands
221 2015-05-19 14:14:48 <cfields> jonasschnelli / wumpus: i'm 99% sure that Qt has something like OS::IsWin(), OS::IsOSX, etc
222 2015-05-19 14:14:57 <cfields> that's what i meant by "those should be runtime checks"
223 2015-05-19 14:15:11 <jonasschnelli> cfields: right. This could make sense!
224 2015-05-19 14:15:15 <cfields> (i completely made up those func names ofc, but there's something like that)
225 2015-05-19 14:15:25 <jonasschnelli> but i think it's up to Diablo-D3 now. :)
226 2015-05-19 14:15:48 <cfields> yea, no worries.
227 2015-05-19 14:15:59 <jonasschnelli> cfields: still strugle with the "Bitcoin-Qt" to "Bitcoin Core" renaming. genisoimage's -V parameter (volid) is not whitespace compatible
228 2015-05-19 14:16:40 <cfields> jonasschnelli: ah, that's why you didn't change it
229 2015-05-19 14:16:46 <cfields> odd, it didn't give me any trouble
230 2015-05-19 14:17:17 <jonasschnelli> i was building over gitian where i got the reported error
231 2015-05-19 14:17:24 <kanzure> what's with the wumpus email with no content?
232 2015-05-19 14:17:28 <wumpus> the resulting error is also strange
233 2015-05-19 14:17:36 <wumpus> huh?
234 2015-05-19 14:17:38 <cfields> but no problem. If there's a reason you didn't change it, that's fine
235 2015-05-19 14:17:48 <cfields> it just looked like an oversight
236 2015-05-19 14:17:56 <jonasschnelli> wumpus: yes, your mailiglist email was pretty empty. :)
237 2015-05-19 14:18:08 <kanzure> your release announcement email was quite.. empty.
238 2015-05-19 14:18:22 <jonasschnelli> cfields: i like to change it and i will find a way (probably). :)
239 2015-05-19 14:18:45 <wumpus> ok, yes it was meant to be an announcement mail
240 2015-05-19 14:19:03 <kanzure> maybe just include end-of-message-plzkthx next time
241 2015-05-19 14:19:06 <kinlo> the message was clear :p
242 2015-05-19 14:19:15 <kanzure> if the subject was the only intended content
243 2015-05-19 14:19:17 <cfields> heh, sourceforge has gone 100% advertisement...
244 2015-05-19 14:19:23 <cfields> it was only a matter of time :)
245 2015-05-19 14:19:53 <jonasschnelli> ;)
246 2015-05-19 14:20:55 <wumpus> hahahaha cfields
247 2015-05-19 14:21:16 <wumpus> they take just the subject fields to make people interested, then the rest is advertisement
248 2015-05-19 14:21:41 <cfields> next step: countdown timers to adware
249 2015-05-19 14:21:43 <kinlo> perhaps another mailinglistprovider with less advertising would be cool :)
250 2015-05-19 14:22:01 <jonasschnelli> cfields: how do i use the current dir in Makefile.am?
251 2015-05-19 14:22:11 <jonasschnelli> cp -rf $(top_srcdir)/contrib/macdeploy/genisoimagerc ./.genisoimagerc    <--- does not work
252 2015-05-19 14:22:38 <cfields> jonasschnelli: probably $(builddir) or so
253 2015-05-19 14:22:47 <jonasschnelli> let me try
254 2015-05-19 14:23:41 <cfields> jonasschnelli: it's really not a big deal, though
255 2015-05-19 14:24:46 <jonasschnelli> cfields: i'll try for another hour or so,.. than i stop messing around with that thing.
256 2015-05-19 14:25:38 <cfields> jonasschnelli: imo don't even lose the hour. I really only suggested it because it looked like an oversight
257 2015-05-19 14:26:15 <jonasschnelli> cfields: Now i already started... :) but you probably right, it's not worth doing this.
258 2015-05-19 14:26:21 <cfields> (i completely made up those func names ofc, but there's something like that)
259 2015-05-19 14:26:21 <cfields> jonasschnelli / wumpus: i'm 99% sure that Qt has something like OS::IsWin(), OS::IsOSX, etc
260 2015-05-19 14:26:21 <cfields> that's what i meant by "those should be runtime checks"
261 2015-05-19 14:26:21 <jonasschnelli> but i think it's up to Diablo-D3 now. :)
262 2015-05-19 14:26:21 <jonasschnelli> cfields: right. This could make sense!
263 2015-05-19 14:26:22 <cfields> jonasschnelli: ah, that's why you didn't change it
264 2015-05-19 14:26:22 <cfields> yea, no worries.
265 2015-05-19 14:26:22 <jonasschnelli> cfields: still strugle with the "Bitcoin-Qt" to "Bitcoin Core" renaming. genisoimage's -V parameter (volid) is not whitespace compatible
266 2015-05-19 14:26:23 <cfields> but no problem. If there's a reason you didn't change it, that's fine
267 2015-05-19 14:26:23 <cfields> it just looked like an oversight
268 2015-05-19 14:26:23 <cfields> odd, it didn't give me any trouble
269 2015-05-19 14:26:23 <jonasschnelli> i was building over gitian where i got the reported error
270 2015-05-19 14:26:23 <jonasschnelli> wumpus: yes, your mailiglist email was pretty empty. :)
271 2015-05-19 14:26:23 <kanzure> what's with the wumpus email with no content?
272 2015-05-19 14:26:23 <wumpus> huh?
273 2015-05-19 14:26:23 <wumpus> the resulting error is also strange
274 2015-05-19 14:26:24 <jonasschnelli> cfields: i like to change it and i will find a way (probably). :)
275 2015-05-19 14:26:24 <kanzure> your release announcement email was quite.. empty.
276 2015-05-19 14:26:25 <wumpus> ok, yes it was meant to be an announcement mail
277 2015-05-19 14:26:26 <cfields> heh, sourceforge has gone 100% advertisement...
278 2015-05-19 14:26:26 <cfields> it was only a matter of time :)
279 2015-05-19 14:26:26 <jonasschnelli> ;)
280 2015-05-19 14:26:26 <kanzure> if the subject was the only intended content
281 2015-05-19 14:26:26 <kanzure> maybe just include end-of-message-plzkthx next time
282 2015-05-19 14:26:26 <kinlo> the message was clear :p
283 2015-05-19 14:26:27 <wumpus> hahahaha cfields
284 2015-05-19 14:26:27 <wumpus> they take just the subject fields to make people interested, then the rest is advertisement
285 2015-05-19 14:26:28 <cfields> next step: countdown timers to adware
286 2015-05-19 14:26:28 <kinlo> perhaps another mailinglistprovider with less advertising would be cool :)
287 2015-05-19 14:26:29 <jonasschnelli> cfields: how do i use the current dir in Makefile.am?
288 2015-05-19 14:26:30 <jonasschnelli> cp -rf $(top_srcdir)/contrib/macdeploy/genisoimagerc ./.genisoimagerc    <--- does not work
289 2015-05-19 14:29:18 <cfields> jonasschnelli: probably $(builddir) or so
290 2015-05-19 14:29:19 <jonasschnelli> let me try
291 2015-05-19 14:29:20 <cfields> jonasschnelli: it's really not a big deal, though
292 2015-05-19 14:29:21 <cfields> jonasschnelli: imo don't even lose the hour. I really only suggested it because it looked like an oversight
293 2015-05-19 14:29:21 <jonasschnelli> cfields: i'll try for another hour or so,.. than i stop messing around with that thing.
294 2015-05-19 14:29:22 <jonasschnelli> cfields: Now i already started... :) but you probably right, it's not worth doing this.
295 2015-05-19 14:46:09 <mr_burdell> I'm testing this PR: https://github.com/bitcoin/bitcoin/pull/6103, it looks like block notifications are not sent during sync.  Is that the expected behavior?
296 2015-05-19 14:46:35 <mr_burdell> I haven't fully synced yet, so I don't know if block notifications are completely broken or just not during sync
297 2015-05-19 14:46:35 <wumpus> that's normal; there are way too many notifications otherwise
298 2015-05-19 14:46:38 <michagogo> wumpus: hm, weird
299 2015-05-19 14:46:45 <mr_burdell> tx notifications are working though
300 2015-05-19 14:47:00 <michagogo> commit title*
301 2015-05-19 14:47:00 <michagogo> I have a script that's supposed to pull the latest commit name and PR with that name
302 2015-05-19 14:47:01 <michagogo> commit title*
303 2015-05-19 14:47:01 <michagogo> I have a script that's supposed to pull the latest commit name and PR with that name
304 2015-05-19 14:47:23 <wumpus> so many notifications that firing off the notifications (for every block) would slow the synchronization to a crawl
305 2015-05-19 14:47:24 <wumpus> so many notifications that firing off the notifications (for every block) would slow the synchronization to a crawl
306 2015-05-19 14:47:39 <mr_burdell> right... maybe tx notifications should be turned off during sync too then
307 2015-05-19 14:47:58 <wumpus> not if it's about *your* transactions
308 2015-05-19 14:48:07 <mr_burdell> this is for all transactions
309 2015-05-19 14:48:08 <mr_burdell> this is for all transactions
310 2015-05-19 14:48:20 <wumpus> so you get a notification for every transaction in the blockchain? wow
311 2015-05-19 14:48:37 <wumpus> I don't think it's supposed to work like that :)
312 2015-05-19 14:48:40 <mr_burdell> I guess the idea would be to not turn on the zmq notifications until it's synced
313 2015-05-19 14:51:21 <jonasschnelli> mr_burdell: you can enable/disable zmq with startup arguments.
314 2015-05-19 14:51:38 <jonasschnelli> so restart your bitcoind when it's synced with the zmq args
315 2015-05-19 14:52:53 <mr_burdell> right, ok
316 2015-05-19 14:52:54 <mr_burdell> right, ok
317 2015-05-19 14:53:04 <mr_burdell> I was just expecting block notifications too
318 2015-05-19 14:53:58 <ajweiss> you mean before entering sync'd/steady state?
319 2015-05-19 14:53:59 <ajweiss> you mean before entering sync'd/steady state?
320 2015-05-19 14:56:11 <mr_burdell> yeah, since the tx notifications were being sent
321 2015-05-19 14:57:48 <mr_burdell> ok, it's synced now and both tx and blks are working
322 2015-05-19 14:58:32 <ajweiss> actually, looking at the source, it seems like you would get all of them
323 2015-05-19 14:58:50 <ajweiss> maybe zmq is dropping them because of full buffers or something?
324 2015-05-19 14:59:39 <jonasschnelli> mr_burdell: don't forget to add your tests feedback to https://github.com/bitcoin/bitcoin/pull/6103 (ACK/NACK, etc)
325 2015-05-19 14:59:40 <jonasschnelli> mr_burdell: don't forget to add your tests feedback to https://github.com/bitcoin/bitcoin/pull/6103 (ACK/NACK, etc)
326 2015-05-19 15:28:20 <mr_burdell> ajweiss: it's surrounded by this: if (!fInitialDownload) {
327 2015-05-19 15:28:32 <mr_burdell> which I assume means it doesn't send the block notifications during the sync
328 2015-05-19 15:28:33 <mr_burdell> which I assume means it doesn't send the block notifications during the sync
329 2015-05-19 15:31:09 <ajweiss> aye, yes.
330 2015-05-19 15:34:21 <ajweiss> it's conceivable that maybe an rpc that asks it to walk the whole chain and publish all the blocks over zmq might make sense
331 2015-05-19 15:35:23 <ajweiss> so if you were to hang something off of it, you could "sync" after bitcoind has finished syncing
332 2015-05-19 15:36:19 <ajweiss> or maybe something that takes a hash and starts from there
333 2015-05-19 15:36:56 <jonasschnelli> ajweiss: hmm... would be another state. Hmm.. why not just restart bitcoind after the sync is done? Or do you expect that there are zmq users who have to enable zmq during a sync?
334 2015-05-19 15:37:27 <ajweiss> so imagine you're building a block browser or something
335 2015-05-19 15:37:34 <ajweiss> and you're getting blocks over zmq
336 2015-05-19 15:37:43 <ajweiss> it'd be nice to be able to "sync" from bitcoind
337 2015-05-19 15:38:15 <ajweiss> now imagine if things go down, and perhaps they're down longer than IsInitialBlockDownload() (~24h)...  it'd be nice to be able to say "catch me up from here"
338 2015-05-19 15:39:23 <jonasschnelli> okay. This could be a usecase. But i think building a block browser you better of with REST and zmq only for getting a hint that there are a new block (then load it over REST)
339 2015-05-19 15:39:57 <ajweiss> hmm... true.
340 2015-05-19 15:41:20 <jonasschnelli> I think at the moment zmq could be used as a notification channel. But pushing through higher amount of blocks (not headers) makes not much sense IMO.
341 2015-05-19 15:41:48 <ajweiss> the pull as implemented now does support pushing full blocks over
342 2015-05-19 15:42:01 <ajweiss> whether or not that should stay is a good question though
343 2015-05-19 15:43:03 <jonasschnelli> ajweiss: at leat there is -zmqformat=hash|network
344 2015-05-19 15:43:26 <ajweiss> true
345 2015-05-19 15:43:28 <jonasschnelli> where you could avoid tell bitcoind to only send you hashes
346 2015-05-19 15:43:33 <mr_burdell> the way I intend to use it is more of a hint... and I check the prevblock to make sure I didn't miss anything
347 2015-05-19 15:44:46 <jonasschnelli> mr_burdell: i think this makes sense. There are better options of "loading data" from bitcoind to your app (RPC/REST).
348 2015-05-19 15:45:57 <mr_burdell> i'll verify that I don't miss any transactions by looking at the transactions included in each block
349 2015-05-19 15:46:14 <mr_burdell> so I think it's good as implemented
350 2015-05-19 15:47:22 <jonasschnelli> I mean you can load everything over RPC/REST but you actually don't have a notification channel when a new block arrives. This could be solved by zmq.
351 2015-05-19 15:48:27 <ajweiss> that makes sense
352 2015-05-19 15:48:34 <mr_burdell> right, it's better than blocknotify
353 2015-05-19 15:48:46 <mr_burdell> and provides live updates of new tx
354 2015-05-19 15:52:22 <temujin> why is zmq better than blocknotify?
355 2015-05-19 15:54:33 <mr_burdell> doesn't blocknotify start a new process?
356 2015-05-19 16:04:37 <wumpus> zmq is low-overhead, launching a process for every notification has a high overhead
357 2015-05-19 16:18:11 <petertodd> wumpus: I'm syncing a fresh 0.9.5rc1 node from scratch, been going since yesterday with no issues, though it's just up to block 309489 on a digital ocean ssd vps - does that sound abnormal or normal re: speed? everything else checks out with no issues
358 2015-05-19 16:18:56 <petertodd> testnet synced up fine
359 2015-05-19 16:20:08 <petertodd> (also, gettxoutsetinfo on testnet matched my v0.10.1 node perfectly)
360 2015-05-19 16:29:45 <kanzure> regtest consensus forking issue https://bitcointalk.org/index.php?topic=1065504
361 2015-05-19 16:35:50 <warren> kanzure: known, some alt coins implemented their own workaround
362 2015-05-19 16:38:53 <lechuga_> is anyone aware of any open impls of the lightning network in progress?
363 2015-05-19 16:45:25 <lechuga_> i guess better put, if any1 is planning to work on an open lightning impl id be interested in contributing cycles
364 2015-05-19 16:52:00 <petertodd> lechuga_: I've got a potential funding source to do hub-and-spoke, the predessesor to lightning, though I'll likely do something even more basic than that
365 2015-05-19 16:52:43 <petertodd> lechuga_: lightning is likely to get implemented after hub-and-spoke/payment channels as 2fa
366 2015-05-19 16:58:20 <lechuga_> petertodd: nice
367 2015-05-19 16:59:17 <lechuga_> well if you find yourself needing assistance
368 2015-05-19 17:22:21 <wumpus> petertodd: 0.9 is expected to be a lot slower in sync than 0.10+
369 2015-05-19 17:23:59 <stonecoldpat> im sure someone has asked before, but is there a reason why sighash_multiple does not exist? (sign "some" of the outputs)
370 2015-05-19 17:53:20 <warren> wumpus: was 0.10 sync improved when syncing from a single peer?
371 2015-05-19 18:36:24 <jonasschnelli> warren: 0.10 sync speed check: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.10.0.md#faster-synchronization
372 2015-05-19 18:55:34 <cfields> wumpus: i've made some local changes that have caused some boost_test weirdness. Is ~TestingSetup() intended to be called to teardown each use of BOOST_FIXTURE_TEST_SUITE ?
373 2015-05-19 18:56:33 <cfields> (i ask because iirc you looked into that recently wrt run-order)
374 2015-05-19 18:59:11 <cfields> jonasschnelli: very nice work on the wallet detachment work. Haven't had a chance to look over yet, but I'm a big fan of the concept :)
375 2015-05-19 19:00:25 <jonasschnelli> cfields: thanks!
376 2015-05-19 19:02:28 <jonasschnelli> cfields: i hope i can soon provide a full working Bip32/Multiwallet PR which basically is a 2nd wallet implementation (detached over signaling)
377 2015-05-19 19:02:53 <cfields> wumpus: more specifically, BasicTestingSetup's dtor isn't virtual, so ~TestingSetup() isn't called. But i'm not understanding how it works without those teardowns
378 2015-05-19 19:03:03 <cfields> jonasschnelli: woohoo!
379 2015-05-19 20:23:10 <temujin> i was reading https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki and wondering if nTxid is enough to protect against malleability that others can inflict upon your own transactions
380 2015-05-19 20:24:07 <temujin> it's true that you can change OPcodes around and malleate a transaction of your own, but others can't malleate your transactions if you are indexing by nTxid right?
381 2015-05-19 20:32:56 <Luke-Jr> temujin: what do you consider "nTxid"? it does not appear in the BIP nor have any obvious definition
382 2015-05-19 20:46:16 <warren> jonasschnelli: cool, will your code have public derivation, allowing watch-only wallets to getnewaddress without any privkeys?
383 2015-05-19 20:47:32 <Luke-Jr> warren: hm! I wonder why Trezor didn't use that to solve the sidechannel attack
384 2015-05-19 20:47:35 <temujin> Luke-Jr: it's mentioned here, bunch of github gists and repos linked in this thread (by maaku) https://bitcointalk.org/index.php?topic=471352.0
385 2015-05-19 20:48:54 <warren> Luke-Jr: URL to sidechannel attack?
386 2015-05-19 20:49:11 <Luke-Jr> temujin: yeah, that should work. I prefer the sPK solution myself
387 2015-05-19 20:49:11 <warren> Luke-Jr: there's a major major drawback to public derivation though
388 2015-05-19 20:49:36 <Luke-Jr> warren: http://johoe.mooo.com/trezor-power-analysis/
389 2015-05-19 20:49:46 <Luke-Jr> warren: they "fixed" it by requiring the PIN to generate addresses
390 2015-05-19 20:54:43 <temujin> Luke-Jr: am I correct in assuming that any transaction in the mempool can be malleated by an attacker, or does the attacker need to have the private key used to sign the transaction?
391 2015-05-19 20:54:58 <temujin> (let's assume this transaction has only two outputs, each signed by the same key)
392 2015-05-19 20:55:25 <temujin> "attacker" in this case is someone who is trying to successfully malleate a transaction in the mempool
393 2015-05-19 20:55:27 <Luke-Jr> temujin: I'm not sure what you're asking here. Depending on a fixed txid is not expected to be safe.
394 2015-05-19 20:56:02 <temujin> hmm, let me try to simplfy it to the most basic essence... do i have to be the person holding the keys to signing the outputs of a transaction to malleate it in the mempool?
395 2015-05-19 20:56:12 <Luke-Jr> no
396 2015-05-19 20:56:14 <temujin> or can anyone flip a bit and change the txid?
397 2015-05-19 20:56:26 <Luke-Jr> more likely have to insert data in the signature
398 2015-05-19 20:56:55 <temujin> right, becuase the signature itself can be changed slightly without nullifying its validity as a signature
399 2015-05-19 20:57:39 <temujin> hmm
400 2015-05-19 20:57:47 <temujin> and anyone can change it?
401 2015-05-19 20:58:08 <Luke-Jr> temujin: the sighash trick, is to replace the inpoints with a normalised txid and/or the relevant scriptPubKey, in the data to be signed
402 2015-05-19 21:05:28 <temujin> Luke-Jr: i'm still trying to understand, definitively, whether or not someone without my private key can change the txid of my transaction in the mempool
403 2015-05-19 21:05:35 <temujin> i haven't really pondered about the solutions yet =P
404 2015-05-19 21:06:09 <Luke-Jr> temujin: yes, they can.
405 2015-05-19 21:07:10 <temujin> and that's through flipping some unimportant bits in the signature field?
406 2015-05-19 21:07:55 <Luke-Jr> more likely adding data
407 2015-05-19 21:07:59 <temujin> i see
408 2015-05-19 21:08:09 <Luke-Jr> eg, a leading zero
409 2015-05-19 21:08:57 <temujin> by inpoints, in your previous statement, you mean the references to a previously unspent output in the input of a transaction?
410 2015-05-19 21:09:37 <Luke-Jr> yes
411 2015-05-19 21:09:51 <Luke-Jr> oops, should be outpoints* ☺
412 2015-05-19 21:11:20 <warren> jonasschnelli: the "Faster Synchronization" is slower if you have only one peer, if the client is asking for a tiny quantity of blocks at a time
413 2015-05-19 21:48:13 <jtimon> wumpus cfields Luke-Jr do you think I should put more moveonly-ish stuff (ie IsStandardTx and AreInputsStandard) in #6068 or just leave it at that?
414 2015-05-19 22:12:34 <jtimon> nevermind not before #5669, I don't want to include main from policy, not even temporarilly, that's one of the main points where Luke-Jr and I were in disagreement in the first place
415 2015-05-19 23:03:51 <jtimon> wumpus cfields you will probably be interested in https://github.com/bitcoin/bitcoin/pull/6163
416 2015-05-19 23:12:19 <jtimon> also ping #5669  #6063 #5975 #6061 everyone, these are trivial yet extremely blocking for libconsensus to move forward
417 2015-05-19 23:12:47 <jtimon> s/blocking/important or not
418 2015-05-19 23:14:10 <jtimon> if you have a nack or a nit please do so as soon as possible, with your help a complete libconsensus may be areality by 2019
419 2015-05-19 23:49:26 <KINGG> how do I make money through bit coin?
420 2015-05-19 23:53:34 <Luke-Jr> anyone here understand git-subtree? why doesn't this work, and how do I do it? :/  git subtree pull --prefix=src/secp256k1/ ../secp256k1/ localbranchname
421 2015-05-19 23:57:00 <kadoban> Luke-Jr: What are the repos involved, and is this after you've done a matching 'git subtree add' some time ago?
422 2015-05-19 23:57:13 <Luke-Jr> bitcoin core + libsecp256k1
423 2015-05-19 23:57:25 <Luke-Jr> someone else did the subtree add
424 2015-05-19 23:57:27 <kadoban> (By what repos, I mean are these public in the exact state you have so I could try too?)
425 2015-05-19 23:57:44 <Luke-Jr> not exact, but they shouldn't differ in any relevant way I can imagine
426 2015-05-19 23:58:04 <Luke-Jr> https://github.com/bitcoin/bitcoin.git and https://github.com/bitcoin/secp256k1.git
427 2015-05-19 23:58:14 <kadoban> Okay, let me see if I can figure out. I've used subtree a few times at least. You're getting some error or something?
428 2015-05-19 23:58:32 <Luke-Jr> kadoban: conflicts saying add/add on both sides
429 2015-05-19 23:59:11 <Luke-Jr> someone +b lnr? :P