1 2015-03-11 01:14:04 <fanquake> ;;blocks
2 2015-03-11 01:14:05 <gribble> 347085
3 2015-03-11 03:42:04 <btc_panhandler> ;;blocks
4 2015-03-11 03:42:05 <gribble> 347103
5 2015-03-11 04:02:47 <Raystonn> Hi, where can I find the bug database? I am interested in helping with core development and would like to see the outstanding requests.
6 2015-03-11 04:03:23 <copumpkin> https://github.com/bitcoin/bitcoin/issues
7 2015-03-11 04:03:31 <Raystonn> Thx
8 2015-03-11 06:33:02 <ciemon> ;;blocks
9 2015-03-11 06:33:03 <gribble> 347122
10 2015-03-11 11:41:52 <afk11> Hi all, myself and others a short BIP a few weeks ago on standard p2sh addresses given m and a set of public keys. I mailed the list and posted here a bit about it, but will submit now as a PR for bitcoin/bips
11 2015-03-11 11:59:28 <afk11> https://github.com/bitcoin/bips/pull/146
12 2015-03-11 12:01:21 <wumpus> afk11: looks good to me
13 2015-03-11 12:02:18 <wumpus> afk11: after a number is assigned it needs an entry in the table in README.mediawiki as well
14 2015-03-11 12:08:47 <afk11> wumpus: thanks, i'll be sure to do that. will hopefully get a chance to write a bitcoin core RPC command for this also.. same function as addmultisigaddress, but with sorting, and rejecting if they aren't all compressed.
15 2015-03-11 12:12:04 <sipa> there should at least be some discussion about it first
16 2015-03-11 12:12:36 <wumpus> there has been discussion on the mailing list about it
17 2015-03-11 12:14:16 <jonasschnelli> afk11, i think it's still gmaxwell who does assign a BIP number?
18 2015-03-11 12:15:49 <afk11> sipa: there was discussion at several points on the mailing list. it captures the general idea, and once I had that much and posted on IRC/mailing list, there wasn't a whole lot else discussed
19 2015-03-11 12:16:12 <sipa> oh, apologies; i didn't read the text yet
20 2015-03-11 12:17:43 <jonasschnelli> "discussion" was around 12.02.15 - 23:01 GMT+1 (http://sourceforge.net/p/bitcoin/mailman/message/33408198/)
21 2015-03-11 12:19:20 <afk11> sipa: np - to date there were 3 discussions on the concept of sorting, and the parties have all converged on sorting the binary representation (as opposed to numerically as others initially did it IIRC?)
22 2015-03-11 12:19:30 <sipa> ok
23 2015-03-11 12:19:58 <afk11> jonasschnelli: aye, I have cc'd him on it as per bip0001 :)
24 2015-03-11 12:20:25 <afk11> I almost forgot to submit as a PR, hence the delay.
25 2015-03-11 12:33:04 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5733 needs GUI label (only affects GUI)
26 2015-03-11 12:37:03 <wumpus> jonasschnelli: consensus seems to be that it's based on a misunderstanding, so maybe better to close it
27 2015-03-11 12:37:38 <jonasschnelli> wumpus, yes. 5733 needs closing IMO. It's unclear and i can't see any benefit.
28 2015-03-11 12:38:07 <jonasschnelli> But should have GUI tag even if it's closed
29 2015-03-11 12:38:26 <sipa> perhaps if there is a misunderstanding, it should be clarified? :)
30 2015-03-11 12:38:41 <sipa> (ignore me if this dies not make sense)
31 2015-03-11 12:39:01 <jonasschnelli> sipa, yes. Answer from wtgomi is outstanding... closing should go over him.
32 2015-03-11 12:39:26 <wumpus> the problem is that we're not even sure what really the issue is
33 2015-03-11 12:40:18 <jonasschnelli> yes. i can't see the issue neither the benefit. And he did also some strange PR in past.
34 2015-03-11 12:40:32 <jonasschnelli> (without offense)
35 2015-03-11 12:41:32 <wumpus> agreed, though he also did quite some useful PR in the past, but if you can't convince people that there is an issue then a solution just floats out there :)
36 2015-03-11 12:43:16 <wumpus> at least for a non-GUI change you could "please make a test that fails with the current state of the code and will work after your patch"
37 2015-03-11 12:43:51 <jonasschnelli> agreed
38 2015-03-11 12:58:03 <Chicago> Hello, while the Gitian build of the latest in LXC, I read that I can export LXC_BRIDGE=br0, LXC_GUEST_IP=192.168.0.125 and GITIAN_HOST_IP=192.168.0.7. The container still comes up with its own addresses in the 10/8 subnet and when I tcpdump the traffic on the Gitian host I see it originating from the br0 IP 192.168.0.7. Would someone kindly help me with the last step of the networking to the LXC so they can communicate with my network.
39 2015-03-11 13:00:40 <jonasschnelli> Chicago: did you follow https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md?
40 2015-03-11 13:03:19 <Chicago> jonasschnelli, Yes, I did those instructions are very helpful. There is no problem ssh'ing into the container. The problem is the container cannot reach the external network. So for example, inside the container if I ' ping github.com ', I'll get PING github.com (192.30.252.128) 56(84) bytes of data. which means the nslookup was fine but the packets going out of the container and coming back through my network gateway aren't routing.
41 2015-03-11 13:05:51 <jonasschnelli> Chicago: what's your host computer/OS because I ran into the same on my Mac OSX 10.9 and 10.10
42 2015-03-11 13:06:37 <Chicago> I've been able to reproduce it on OSX Mountain Lion using latest VirtualBox following the directions to the letter.
43 2015-03-11 13:07:19 <Chicago> Then, I went ahead and tried the same configuration without VirtualBox using LXC on my Gentoo Gitian host which also results in the container unable to communicate with the external network.
44 2015-03-11 13:07:19 <midnightmagic> Chicago: If you can ping your *host*, then you should be having gitian use the local host via apt-cacher-ng to update its system. It doesn't need external network access; run apt-cacher-ng on local system, program that into the gitian image setup and you should be done at that point.
45 2015-03-11 13:07:40 <midnightmagic> In fact, it's better if it doesn't have external network access, really.
46 2015-03-11 13:08:03 <Chicago> midnightmagic, I need external network access to go through the Gitian exercises from the pre v0.9 Bitcoin.
47 2015-03-11 13:08:09 <Chicago> Those communicate with the external network.
48 2015-03-11 13:08:14 <jonasschnelli> I also thought deps go over a local aptcacher?
49 2015-03-11 13:08:48 <midnightmagic> they do. he's doing software archaeology looks like.
50 2015-03-11 13:09:35 <Chicago> Basically wanting to grasp the Gitian descriptors working up from the start through the current which are really nice since they obviously build OSX/Win/OSX without external networking.
51 2015-03-11 13:15:06 <midnightmagic> Chicago: In any event, make sure all your gitian containers are removed from the loopback: check with losetup -a ; then you can modify the individual LXC master images manually after they were created and give them network-aware access which knows how to access your host's network segment. Your bridge will need to be configured properly, which it sort-of looks like it is. ifconfig br0 -> should return your host's IP address as
52 2015-03-11 13:15:12 <midnightmagic> the main IP of the bridge.
53 2015-03-11 13:16:34 <midnightmagic> Chicago: finally, you will have to set up the LXC container config to use the bridge as the master interface. Check ./var/lxc-config from the gitian build directory and verify that lxc.network.link is br0 and not virbr0.
54 2015-03-11 13:17:04 <midnightmagic> you'll also see lxc.network.ipv4 as a config setting in there. verify that is the IP you want it to have.
55 2015-03-11 13:18:11 <Chicago> midnightmagic, jonasschnelli, Thanks for the support. Will do as suggested and try again with those changes.
56 2015-03-11 13:18:16 <midnightmagic> examine etc/lxc.config.in if it exists in your gitian tree, as it is the source from which the var/*lxc* file is configured each build.
57 2015-03-11 13:19:25 <midnightmagic> If that still doesn't work, start checking firewall rules. Note: this is all based on Ubuntu host usage, and not Gentoo. I have no idea what they do there. Good luck.
58 2015-03-11 13:20:19 <Chicago> Gentoo wasn't too different from the instructions with the Debian Gitian host -- basically, just needed to pull in python-vm-builder
59 2015-03-11 13:20:40 <treehug88> Hey, I submitted a PR for a minimal centos startup script. Is it more likely to be accepted if the startup script has feature parity with the other startup scripts in https://github.com/bitcoin/bitcoin/tree/master/contrib/init
60 2015-03-11 13:21:53 <treehug88> In particular, the script I submitted works well, but doesn't support a pidfile or a location for the blockchain like /var/lib/bitcoin.
61 2015-03-11 13:33:21 <wumpus> treehug88: I don't think that's a requirement: do we have someone else on CentOS that has tested it?
62 2015-03-11 13:33:37 <treehug88> wumpus: I don't believe so
63 2015-03-11 13:33:50 <wumpus> that would be nice to have before merging
64 2015-03-11 13:34:01 <treehug88> how can I help that to occur wumpus ?
65 2015-03-11 13:34:30 <wumpus> ask someone else using CentOS to test it? maybe here, maybe in #bitcoin, or somewhere else centos users hang out? :)
66 2015-03-11 13:36:05 <treehug88> Hello, all. Anyone want to test a centos startup script for bitcoind? Works well for me but I'm looking to get it accepted into contrib/init/
67 2015-03-11 13:39:54 <jtimon> ./compat/endian.h:109:17: error: expected unqualified-id before '__extension__'
68 2015-03-11 13:39:54 <jtimon> from crypto/ripemd160.cpp:5:
69 2015-03-11 13:39:54 <jtimon> is master broken?
70 2015-03-11 13:40:09 <wumpus> jtimon: re-run ./autogen.sh
71 2015-03-11 13:40:10 <jtimon> or it's just me?
72 2015-03-11 13:40:15 <jtimon> oh, ok, thanks
73 2015-03-11 13:45:03 <blahblahblah> any linux users on?
74 2015-03-11 13:45:40 <blahblahblah> who can telnet to my bitcoind to verify external access?
75 2015-03-11 13:45:59 <dhill> sure
76 2015-03-11 13:46:27 <teward> blahblahblah: sure, if you really want someone to throw traffic at your server. (although telnet isn't exclusively linux :P)
77 2015-03-11 13:48:18 <blahblahblah> yes I know I just don't want to handhold a windows user thru it
78 2015-03-11 13:48:50 <jtimon> cfields mhmm weird https://travis-ci.org/bitcoin/bitcoin/builds/53942833
79 2015-03-11 13:50:29 <jonasschnelli> blahblahblah, why not start your node and exec a RPC call "getpeerinfo" to see if some peers are sending/rcv bytes?
80 2015-03-11 13:50:42 <dhill> or if they are marked inbound :)
81 2015-03-11 13:51:04 <blahblahblah> hmm... never tried that... brb.
82 2015-03-11 13:51:45 <jonasschnelli> blahblahblah, if your config held some reasonable rpc user and password it should work with "bitcoin-cli getpeerinfo"
83 2015-03-11 13:52:42 <blahblahblah> I'm threading port 8333 through 2 firewalls which is why its trickier than normal (but still not that tricky)
84 2015-03-11 13:53:34 <blahblahblah> ok got a lot of data what am I looking for to verify that other bitcoind's can initiate a cnxn
85 2015-03-11 13:54:47 <blahblahblah> inbound = true?
86 2015-03-11 13:55:14 <jtimon> wumpus you recently changed something in the tests related to chainparams, no? https://travis-ci.org/bitcoin/bitcoin/jobs/53942838#L1343
87 2015-03-11 13:56:27 <jonasschnelli> jtimon, wumpus, yes. something is strange there: https://travis-ci.org/bitcoin/bitcoin/builds/53637474
88 2015-03-11 13:57:10 <jtimon> looks like a missing SelectParams() somewhere...
89 2015-03-11 13:59:06 <jonasschnelli> merge of #5852 made travis fail.. maybe sipa should take a look at it
90 2015-03-11 13:59:49 <wumpus> jtimon: yes, a combination of per-test initialization fixture and randomized test order means that tests have to select their own params now
91 2015-03-11 14:00:26 <wumpus> jonasschnelli: where do you see that? travis on master is passing
92 2015-03-11 14:01:06 <jonasschnelli> wumpus, now yes. but shortly merge cdae53e made travis fail for strange reasons: https://travis-ci.org/bitcoin/bitcoin/builds
93 2015-03-11 14:01:23 <jtimon> I would preffer to use Params("main") instead of SelectParams("main") and then Params() when possible...
94 2015-03-11 14:01:28 <jonasschnelli> and i saw the same pattern on a PR from jtimon (https://travis-ci.org/bitcoin/bitcoin/builds/53942833)
95 2015-03-11 14:01:45 <sipa> jtimon: not possible without passing params through to every function pretty much
96 2015-03-11 14:01:58 <sipa> jtimon: not opposed to that, btw, but that's not a small change
97 2015-03-11 14:02:22 <wumpus> jtimon: I agree passing the parameters through is eventually the best solution, but for the short term it'd be better to just select the right set of parameters at the start of the test
98 2015-03-11 14:02:53 <wumpus> in any case as far as I know I already fixed that for the tests that were failing travis
99 2015-03-11 14:03:04 <jtimon> sipa: it's possible in some cases (would be possible in all of them if the params were passed down to all functions but as you say that's not a small change)
100 2015-03-11 14:03:19 <wumpus> new travis runs don't randomize the test order in different ways, so that should be consistent
101 2015-03-11 14:03:54 <jonasschnelli> hmm.. okay. maybe #5696 needs rebase even if there are no merge conflicts (@jtimon)
102 2015-03-11 14:04:24 <wumpus> I'll retrigger travis
103 2015-03-11 14:04:47 <jtimon> well, it seems it's not completely fixed since these PRs are failing (unfortunately I cannot reproduce the failure in my pc)
104 2015-03-11 14:04:49 <zztimber> Iâm interested in asking questions about the raw transaction API, is this the right place? I believe I understand most of the system but I feel Iâm missing a few pieces
105 2015-03-11 14:06:23 <jtimon> jonasschnelli 5696 needed rebase and had merge conflicts but I just missed what caused the conflct (something around minRelayTxFee in main.cpp)
106 2015-03-11 14:06:35 <zztimber> Or is this more for development on bitcoin core itself?
107 2015-03-11 14:06:44 <jonasschnelli> zztimber, go ahead
108 2015-03-11 14:07:00 <wumpus> zztimber: it's fine to ask technical questions about the raw transactions api here
109 2015-03-11 14:07:28 <jtimon> not really sure in this case but when in doubt you can always try #bitcoin first and then come here if you don't get answers
110 2015-03-11 14:09:11 <zztimber> So Iâm trying to build an open source co-signing engine. I would prefer to use Bitcoin Core for this (if possible, seems to be with the recent upgrade to 0.1.0). I understand I need to use the rawtransaction API. I need to listunspent create the raw transaction then sign it and pass it over the the cosigning engine. How do I move the raw transaction to another server to be signed?
111 2015-03-11 14:09:14 <spr4wl_org> hello everyone... testnet mining question: "master" branch doesn't seem to work with mining testet coins. Should I be on 0.9, 0.8 or else? I need a lot to test a project and all gen just stopped lately :(
112 2015-03-11 14:09:39 <kanzure> spr4wl_org: perhaps consider using regtest as a quick fix?
113 2015-03-11 14:11:43 <wumpus> spr4wl_org: what, exactly, doesn't work? does it crash? what error do you get?
114 2015-03-11 14:12:05 <jonasschnelli> zztimber, what do you mean with "how do i move the raw transaction". In case of security?
115 2015-03-11 14:12:38 <spr4wl_org> kanzure: I would like to avoid that :O as I am actually running a faucet too, and don't want to fork my own chain with regtest
116 2015-03-11 14:13:25 <kanzure> spr4wl_org: regtest is separate
117 2015-03-11 14:13:32 <spr4wl_org> wumpus: everything seems to work, however there are no coins generated for many days (20 at least) ... and I am running on an i7, and a Xeon too, doesn't seem normal
118 2015-03-11 14:14:13 <kanzure> zztimber: you would transmit the unsigned transactions in their hex-encoded form.
119 2015-03-11 14:14:21 <jgarzik> zztimber, everything is text. raw transactions are text that is manipulated and updated with the raw transactions API. You are responsible for storing that text, or sending it to another server.
120 2015-03-11 14:14:31 <zztimber> Okay that makes it much easier
121 2015-03-11 14:14:45 <zztimber> I guess its time to start messing around with the concept on the testnet
122 2015-03-11 14:15:54 <wumpus> spr4wl_org: I'd be surprised if CPU mining was still effective, even on the testnet
123 2015-03-11 14:16:16 <sipa> what is testnet's difficulty now?
124 2015-03-11 14:16:16 <spr4wl_org> kanzure: hmm, yep, that's what I don't really want... I have 10+ daemons and everything is generating (LTC, MAx, etc), it is just the latest that doesn't poop any coins out l
125 2015-03-11 14:17:20 <jtimon> spr4wl_org also even with ASIC mining and 99% of the hashrate you could not get a block in 20 days or more, having many lottery tickets doesn't imply having the winning one
126 2015-03-11 14:17:57 <spr4wl_org> wumpus: yep .. I was considering that too ... I have an old BFL, if downgrading to 0.8 doesn't do any good, I might connect it solo-mining :(
127 2015-03-11 14:20:32 <spr4wl_org> jtimon: kind of sucks, doesn't it, I had the impression, that difficulty "1" would cpu mine at least *come* testnet coins, but the net hash rate ther is ridiculously high
128 2015-03-11 14:20:56 <jtimon> so wumpus did you retrigger travis for 5696 ? it seems it's still failing...
129 2015-03-11 14:21:06 <wumpus> jtimon: yes I did
130 2015-03-11 14:21:27 <jtimon> spr4wl_org testnet doesn't have diff 1, does it?
131 2015-03-11 14:22:21 <spr4wl_org> jtimon: "difficulty" : 1.00000000,
132 2015-03-11 14:22:38 <sipa> spr4wl_org: testnet has a special rule that allows difficulty 1 blocks after 20 minutes
133 2015-03-11 14:22:39 <spr4wl_org> jtimon: "networkhashps" : 6544557167867,
134 2015-03-11 14:23:02 <sipa> so the reported difficulty may be 1, even if the actual difficulty is higher
135 2015-03-11 14:23:16 <sipa> and if there are several people mining, they'll likely get the one after 20 min first
136 2015-03-11 14:25:27 <spr4wl_org> sipa: OK ... makes sense... then back to the original question: is this a "version issue" with mining testnet ? I am on "master" and the version is 99900, proto: 70002, wallet 60000
137 2015-03-11 14:26:13 <sipa> spr4wl_org: no
138 2015-03-11 14:26:33 <sipa> the rules of testnet are fixed, if using a difficulty bitcoin core version changes something, that would be a bug
139 2015-03-11 14:27:40 <jtimon> wumpus it seems it failed again, just without log https://travis-ci.org/bitcoin/bitcoin/builds/53942833
140 2015-03-11 14:28:45 <spr4wl_org> sipa: I noticed with some alt coins, that when not running the latest dev version in testnet mode, I got no connections. With BTC it is not the case, but since I upgraded, generation just stopped completely ... that's why I wonder if it is *indeed a bug* others might have seen
141 2015-03-11 14:29:42 <spr4wl_org> sipa: but in the meantime I am downgrading to 0.8 .... then run it
142 2015-03-11 14:30:08 <sipa> spr4wl_org: i don't care about altcoins
143 2015-03-11 14:30:16 <sipa> spr4wl_org: but if 0.8 mines while 0.10 doesn't, let us know
144 2015-03-11 14:32:13 <spr4wl_org> sipa: OK .. thanks .... will try ... btw, when you say 0.10 what "version" does that actually show in "getinfo"
145 2015-03-11 14:33:09 <wumpus> 0.10.0
146 2015-03-11 14:33:13 <sipa> 100000
147 2015-03-11 14:34:35 <spr4wl_org> sipa: and that comes from the branch "master" ? :O I was still on 99900 with that (was 10-15 days ago) ...
148 2015-03-11 14:35:12 <sipa> hmm
149 2015-03-11 14:35:23 <spr4wl_org> sipa: never mind ... see the branch list :O 0.10 is there
150 2015-03-11 14:35:31 <wumpus> best way to get the version is bitcoind --help
151 2015-03-11 14:35:48 <wumpus> (or --version, but that only works on 0.10+)
152 2015-03-11 14:36:01 <sipa> master will give you 109900
153 2015-03-11 14:36:04 <sipa> today
154 2015-03-11 14:37:16 <wumpus> yes, master is *ahead* of 0.10
155 2015-03-11 14:38:26 <spr4wl_org> sipa, wumpus : thanks... will try 0.10 ... and see with that .... 0.10 < 0.9 (mathematically speaking) :O so that's how my brain just locked that number out from the branch list :)
156 2015-03-11 14:38:43 <wumpus> hence has a larger version number (0.10.99 == 0.11 minus epsilon)
157 2015-03-11 14:39:35 <wumpus> versions are tuples, like sections in a book, not floating point numbers. This should be basic stuff :)
158 2015-03-11 14:40:51 <spr4wl_org> wumpus: yes :O agreed .... but in a list of numbers ... well, you see numbers as numbers ... ( I did ) ... thanks anyway :O
159 2015-03-11 14:44:42 <spr4wl_org> wumpus: and yes of course, git cannot checkout 0.1 :) it will only check out 0.10 , yet in my head it is a decimal :)
160 2015-03-11 14:45:22 <sipa> spr4wl_org: you need to update your head
161 2015-03-11 14:45:43 <sipa> i suggest to version HEAD or HEAD~ at least.
162 2015-03-11 14:47:06 <spr4wl_org> sipa: :O pun intended ? :)
163 2015-03-11 14:47:12 <sipa> yes
164 2015-03-11 14:47:15 <Luke-Jr> spr4wl_org: you may need to increase rpcthreads to mine
165 2015-03-11 14:47:16 <wumpus> hehe
166 2015-03-11 14:47:38 <Luke-Jr> I agree it is annoying that git fails to version-sort
167 2015-03-11 14:48:02 <wumpus> Luke-Jr: he's doing CPU mining with the built-in miner, rpcthreads shouldn't matter for that
168 2015-03-11 14:48:09 <Luke-Jr> wumpus: ew, why? :|
169 2015-03-11 14:48:27 <wumpus> Luke-Jr: don't ask me
170 2015-03-11 14:48:35 <Luke-Jr> spr4wl_org: ^
171 2015-03-11 14:49:40 <spr4wl_org> Luke-Jr: indeed .... 0.10, 0.6.3, 0.7.2, 0.8, 0.9 .... I think what only counts is the genproclimit when cpu-mining
172 2015-03-11 14:50:55 <spr4wl_org> Luke-Jr, unless you connect an cgiminer with or without an asic (which I might have to do as I need some volume testnet coins now) :(
173 2015-03-11 14:51:12 <Luke-Jr> spr4wl_org: yeah, BFGMiner can get like 100 better performance on CPUs
174 2015-03-11 14:56:16 <spr4wl_org> Luke-Jr, I have a 25GH BFL on a Raspberry (worth nothing now) and will probably try that if 0.10 doesn't start spitting coins out fast enough :)
175 2015-03-11 15:02:44 <gimme_bottles> Hello, I am currently writing a bitcoin node (for fun and educational reasons) and was wondering if there is some documentation about the changes in the protocol from one version to another. Something like "Version 70001->70002: Added 'relay' flag to version messages".
176 2015-03-11 15:03:14 <sipa> protocol changes usually have associated bios
177 2015-03-11 15:03:16 <sipa> *bips
178 2015-03-11 15:19:51 <gimme_bottles> Thanks sipa, I'll look into the list of BIPs to compile a list of changes
179 2015-03-11 15:20:14 <sipa> gimme_bottles: https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md
180 2015-03-11 15:33:09 <gimme_bottles> sipa: thanks, very helpful
181 2015-03-11 15:38:19 <jonasschnelli> needs GUI and "Low Prio" label: https://github.com/bitcoin/bitcoin/issues/5867
182 2015-03-11 16:01:34 <cfields> jtimon: my branch moves the global param selection out into new objects, then Params() usage is limited to app-specific places
183 2015-03-11 16:01:45 <cfields> that's the easiest start i could think of
184 2015-03-11 16:01:56 <kanzure> jonasschnelli: i may have recently lost the motivation to maintain 5524 (fundrawtransaction-watchonly)
185 2015-03-11 16:02:07 <kanzure> jonasschnelli: i'm willing to rebase and stuff
186 2015-03-11 16:02:48 <kanzure> jonasschnelli: i have been using this in very extensive testing for a few months now and it seems to work reasonably well
187 2015-03-11 16:02:52 <jtimon> "moves the global param selection out into new objects" ? sorry, I don't understand
188 2015-03-11 16:03:32 <kanzure> jonasschnelli: however, i think there are some really weird design issues going on with what fundrawtransaction calls. it seems a little strange that everything is being shoehorned into that CreateTransaction function (sorry, i may be misremembering the exact name).
189 2015-03-11 16:03:43 <jonasschnelli> kanzure: okay. No worries. If the "fundrawtransaction" basic call get merged i can takeover on your 5524
190 2015-03-11 16:03:57 <kanzure> unfortunately i don't have a better suggestion for CreateTransaction
191 2015-03-11 16:04:09 <cfields> jtimon: sorry, into different .h/.cpp. Sec for link
192 2015-03-11 16:04:44 <cfields> jtimon: https://github.com/theuni/bitcoin/commit/b0bc185a24c66213d49726445ecb42bfa8994300
193 2015-03-11 16:04:45 <kanzure> ideally what we should be doing is something like: create empty list of utxos, filter list of utxos, pass list of utxos into coin selection, try to skip transaction creator thing. change output should be option, but json result data should definitely mention change. also, fee estimation should not be mandatory.
194 2015-03-11 16:04:58 <kanzure> *should be optional
195 2015-03-11 16:05:03 <kanzure> *create and filter list of utxos
196 2015-03-11 16:05:15 <kanzure> *mention change amount
197 2015-03-11 16:06:13 <jonasschnelli> kanzure: hmmm... Lost the context a little bit. But will look at it again soon and will try to see it with your design concerns.
198 2015-03-11 16:06:30 <jtimon> cfields I see, but I don't see how that solves anything...
199 2015-03-11 16:06:32 <kanzure> what i did the last few days was imlement my own coin selection algorithm instead, so that i have native support in my project.. i would have preferred to use bitcoind, but hacking coin selection to work with all of my different subsets would have been ugh.
200 2015-03-11 16:06:40 <kanzure> *implement
201 2015-03-11 16:08:05 <cfields> jtimon: with that, we can control which files can use globals and which can't. That means that a lib can use chainparams since it would no longer require the global state
202 2015-03-11 16:08:59 <jtimon> oh, I see
203 2015-03-11 16:38:00 <jtimon> cfields, anyway, are there plans for any other lib besides libconsensus that would consume params? if not, maybe #5812 is enough...
204 2015-03-11 16:39:35 <cfields> jtimon: I'm unsure. My goal atm is to separate state from any file that may be useful outside of bitcoind, and look into lib use-cases once that's accomplished
205 2015-03-11 16:40:23 <cfields> jtimon: either way, I'd like that one to go in asap. I'll give it another review with the latest changes and ACK it.
206 2015-03-11 16:40:25 <jtimon> I see the value in doing that to identify dependencies on the global state though
207 2015-03-11 16:40:28 <cfields> (yours)
208 2015-03-11 16:40:37 <jtimon> cool, thanks
209 2015-03-11 16:41:57 <jtimon> it would be nice to get #5696 in soon too (or better, #5669)
210 2015-03-11 16:46:13 <cfields> jtimon: i'll go through those today for re-acks. IIRC your "don't include main.h" PR is ready to go as well, no?
211 2015-03-11 16:46:39 <sipa> i left a comment on it
212 2015-03-11 16:48:03 <jtimon> cfields yep 5681 is ready as well, in fact that one didn't needed rebase
213 2015-03-11 16:48:16 <jtimon> well, let me process sipa's comment...
214 2015-03-11 16:52:17 <jtimon> anyway, any other suggestions are welcomed, an independent file for that little thing seemed "wronger" to me and since net already had CNodeStats...
215 2015-03-11 16:52:17 <jtimon> sipa answered the comment: "How is net.o is higher level than main.o? main.cpp depends on net and not the other way around..."
216 2015-03-11 16:53:48 <morcos> It's expected to still have spurious travis failures on chainparam.cpp, or is that supposed to be fixed now?
217 2015-03-11 16:54:28 <wumpus> morcos: master is passing, but somehow #5696 fails, looking into why
218 2015-03-11 16:55:15 <morcos> I have another branch failing in my repo, i was about to submit a PR for it (fixes bug in InvalidateBlock) but just wanted to be sure I understood the travis failure
219 2015-03-11 16:55:47 <Luke-Jr> cfields: hey, a lot of people recently seem to be getting the impression the Foundation controls Bitcoin Core development from https://bitcoinfoundation.org/bitcoincore/ ; Gavin mentioned you maintain this, can you perhaps clarify the nature of it somehow? eg, maybe some short description to the right of the "Core Updates" on the top?
220 2015-03-11 16:55:52 <wumpus> to reproduce locally, define e.g. export BOOST_TEST_RANDOM=14 before calling test_bitcoin
221 2015-03-11 16:56:54 <wumpus> 14 generally 1x where the x is the travis build number [1..7]
222 2015-03-11 16:57:15 <cfields> Luke-Jr: yes.
223 2015-03-11 16:57:15 <Luke-Jr> cfields: maybe something like "This blog provides regular updates of Core development, which is in part funded by, but done independently of the Foundation."
224 2015-03-11 16:57:25 <Luke-Jr> thanks
225 2015-03-11 16:58:11 <wumpus> tried various BOOST_TEST_RANDOMs with #5696 locally, no failures :/
226 2015-03-11 16:58:25 <wumpus> ah, woohoo, a failure
227 2015-03-11 16:58:36 <Luke-Jr> wumpus: it was waiting for you to say that :P
228 2015-03-11 16:59:00 <wumpus> Luke-Jr: heh - with "11" it fails, whereas job 1 was succeeding in travis so I didn't try that
229 2015-03-11 17:00:48 <sipa> jtimon: sorry, higher/lower level semantics; net is not supposed to depend on main, so net should also not define main-specific data
230 2015-03-11 17:01:29 <sipa> jtimon: CNOde is the baseline data per node; main's CNodeState is main-specific extensions to it
231 2015-03-11 17:01:34 <cfields> Luke-Jr: fwiw, the site's content isn't my area. I'm just helping out with some back-end work. So no guarantees that it'll be fixed immediately, but I agree that it's misleading so I'll see to it that it's resolved.
232 2015-03-11 17:01:43 <sipa> jtimon: i object to having those in net
233 2015-03-11 17:02:34 <cfields> there are probably enough node structures/functions in main to justify moving them out to a new file?
234 2015-03-11 17:02:51 <sipa> they should be moved out yes
235 2015-03-11 17:03:14 <sipa> wumpus's rewrite of askfor for transaction was a nice example of that
236 2015-03-11 17:03:38 <morcos> wumpus: yeah mine also fails with 11, but not with 12 locally (job 1 passeed, job 2 failed on travis)
237 2015-03-11 17:04:16 <wumpus> jtimon: can you try to cherry-pick https://github.com/laanwj/bitcoin/commit/fcf7a017a6393f8b4f2df1a4e376a8e16cae0909 into #5696?
238 2015-03-11 17:04:23 <wumpus> that should solve the travis failure
239 2015-03-11 17:04:53 <jtimon> I really thought that moving it to net was better than moving it to an independent file...
240 2015-03-11 17:05:04 <jtimon> wumpus sure, thanks
241 2015-03-11 17:05:31 <kanzure> jonasschnelli: btw can you clarify whether the rebase is urgent-today, or urgent-please-this-week, or something else?
242 2015-03-11 17:07:42 <Luke-Jr> cfields: ah, well the content is fine ⺠maybe it should say a real author name instead of "core dev team" though :p
243 2015-03-11 17:07:43 <jonasschnelli> kanzure: only rebase if you have time. It's not urgent. If you don't find the time I can do it (but not before next week).
244 2015-03-11 17:08:01 <kanzure> i have time, just wanted clarity, kthx
245 2015-03-11 17:08:26 <cfields> Luke-Jr: yep, i understand what you mean completely.
246 2015-03-11 17:08:51 <jtimon> wumpus, pushed, thanks again
247 2015-03-11 17:09:00 <sipa> jtimon: i don't understand why it needs to move; it belongs to main
248 2015-03-11 17:09:39 <sipa> in general, message processing should move out of main, and its data structures with it
249 2015-03-11 17:10:01 <morcos> wumpus: that fixed it for me as well. thanks.
250 2015-03-11 17:10:16 <jonasschnelli> sipa: you should stop chatting and get ready for your talk... î
251 2015-03-11 17:10:28 <Luke-Jr> lol
252 2015-03-11 17:10:30 <sipa> jonasschnelli: on my way
253 2015-03-11 17:10:31 <morcos> on another note if I run with BOOST..RANDOM=13, then it writes some lines to $homedir/.bitcoin/debug.log
254 2015-03-11 17:10:39 <morcos> that seems bad
255 2015-03-11 17:10:45 <sipa> jonasschnelli: i couldn't find the right bus stop at albisriederplatz
256 2015-03-11 17:10:48 <cfields> morcos: yikes!
257 2015-03-11 17:11:48 <jonasschnelli> sipa: zurich requires a bicycle. Bus to "schiffsbau" would be more direct?
258 2015-03-11 17:12:46 <kanzure> jonasschnelli: which talk? have link?
259 2015-03-11 17:12:53 <sipa> jonasschnelli: google maps never fails me :)
260 2015-03-11 17:13:03 <kanzure> sipa: if you have livestream link then i can do transcript
261 2015-03-11 17:13:06 <Luke-Jr> once upon a time test_bitcoin wrote to ~/.bitcoin/blocks/blk*.dat âº
262 2015-03-11 17:13:12 <sipa> jonasschnelli: except when i can't find the stop
263 2015-03-11 17:13:25 <sipa> kanzure: i already did the talk before, it's on youtube
264 2015-03-11 17:13:30 <jonasschnelli> î
265 2015-03-11 17:13:41 <kanzure> i am not going to transcribe already-available video. someone else can do that.
266 2015-03-11 17:15:07 <wumpus> jonasschnelli: î U+E056 private use area?
267 2015-03-11 17:15:13 <jtimon> sipa: nothing belongs in main...anyway, the only reason is to avoid including main from qt/peertablemodel.h and include it from qt/peertablemodel.cpp instead, since including main from headers files hides dependencies
268 2015-03-11 17:15:32 <sipa> jtimon: it belongs with message processing
269 2015-03-11 17:15:39 <sipa> jtimon: which is currently in main
270 2015-03-11 17:16:10 <sipa> solve dependencies by actually modularizing, not by hacking around it :)
271 2015-03-11 17:16:13 <jtimon> maybe I can suppress that commit and rename the PR "only include main from one header file" or something like that
272 2015-03-11 17:16:27 <sipa> feel free :)
273 2015-03-11 17:16:56 <sipa> sorry to bitch about this, but you know i care more about actual semantic modularizatiin than which file includes which
274 2015-03-11 17:17:38 <jtimon> this doesn't solve dependencies per se, but including lots of things in main.h and then include main in wallet.h among other headers was very good for hiding dependencies
275 2015-03-11 17:18:01 <sipa> yeah, dependencies need to be made explicit
276 2015-03-11 17:18:48 <sipa> jonasschnelli: i may be a few minutes late; the zurich public transport rarely fails me :(
277 2015-03-11 17:19:18 <jonasschnelli> sipa: m2 *meh*
278 2015-03-11 17:19:28 <sipa> ?
279 2015-03-11 17:19:47 <jonasschnelli> sipa: me too. Sitting in jammed bus.
280 2015-03-11 17:19:56 <jtimon> sipa no worries, it's fine, qt/peertablemodel.h is not included from any place anyway, so it's the less useful commit in the PR
281 2015-03-11 17:31:28 <sipa> jonasschnelli: i'll be there in a few mims
282 2015-03-11 17:50:15 <treehug88> what does 'ut ACK' in a PR mean?
283 2015-03-11 17:51:03 <wumpus> UnTested
284 2015-03-11 17:51:19 <Luke-Jr> we have a doc in git with this stuff I think
285 2015-03-11 17:51:39 <treehug88> what would be the best way to get a startup script (say, for centos' /etc/init.d ) tested?
286 2015-03-11 17:53:39 <treehug88> Luke-Jr: yes here: https://github.com/bitcoin/bitcoin/blob/ccef2b5f264062a33748d08cbde1e740019599d0/doc/developer-notes.md thanks
287 2015-03-11 17:53:48 <Luke-Jr> treehug88: find CentOS users
288 2015-03-11 17:54:05 <treehug88> and just have them comment that it works in the PR?
289 2015-03-11 17:55:12 <treehug88> ( Luke-Jr )
290 2015-03-11 17:55:35 <Luke-Jr> treehug88: "it works" is pretty vague; sayign what they tested is better
291 2015-03-11 17:55:40 <Luke-Jr> eg, start/stop/status/etc
292 2015-03-11 17:55:52 <Luke-Jr> did they try to shutdown, and make sure it did so cleanly?
293 2015-03-11 17:56:05 <Luke-Jr> did they try to see if it started at boot?
294 2015-03-11 17:56:14 <treehug88> cool, I can be one person to test it, I have been using it successfully for start/stop/status/restart
295 2015-03-11 18:04:08 <morcos> wumpus: sigh.. i guess i didn't test enough RANDOM's, my pull #5879 is failing. locally it fails with RANDOM=15
296 2015-03-11 18:13:52 <marioxcc> Does the reference implementation still leaves the database unpruned?. (That is: does it still stores all the transactions ever happened?)
297 2015-03-11 18:15:36 <Luke-Jr> marioxcc: the database is pruned; blockchain storage is not.
298 2015-03-11 18:16:03 <marioxcc> Luke-Jr: Could you please elaborate?.
299 2015-03-11 18:16:16 <Luke-Jr> marioxcc: a database is used for storing the UTXO set. that is pruned.
300 2015-03-11 18:16:31 <Luke-Jr> marioxcc: the blockchain is not a database, but is stored entirely on disk in flat files; it is never pruned currently
301 2015-03-11 18:17:17 <marioxcc> Luke-Jr: I see.
302 2015-03-11 18:17:48 <marioxcc> Luke-Jr: So the case is that all transactions ever happened are still stored in all heavy clients, just not indexed, right?.
303 2015-03-11 18:18:09 <Luke-Jr> marioxcc: yes
304 2015-03-11 18:18:24 <Luke-Jr> except for the few running experimental pruning code
305 2015-03-11 18:18:30 <marioxcc> Luke-Jr: Thanks. Are there plans to change that anytime?.
306 2015-03-11 18:18:34 <Luke-Jr> yes
307 2015-03-11 18:18:37 <marioxcc> Ok.
308 2015-03-11 18:18:48 <Luke-Jr> probably 0.11 will download it all and delete what it can later
309 2015-03-11 18:19:08 <marioxcc> Luke-Jr: Ok, thanks.
310 2015-03-11 19:16:59 <Raystonn> Pruning could also help ensure fungibility, if done right.
311 2015-03-11 19:18:26 <marioxcc> Raystonn: please elaborate
312 2015-03-11 19:20:02 <gmaxwell> Raystonn: that sounds like its a misunderstanding of what pruning actually is, alas. (or maybe a misunderstanding of how bitcoin verification already works?)
313 2015-03-11 19:20:18 <marioxcc> Yes, I agree.
314 2015-03-11 19:20:32 <marioxcc> That's why I asked him to elaborate. Maybe I'm missing something.
315 2015-03-11 19:21:01 <gmaxwell> Bitcoin's verification already onlys consider the set of currently spendable coins; and from that perspective all coins are equal.
316 2015-03-11 19:21:24 <Adlai> Raystonn: pruning reduces the amount of space that is required on disk for verifying new blocks. it doesn't eliminate the data in old blocks stored in other people's nodes.
317 2015-03-11 19:23:42 <Raystonn> If one were to incorporate pruning into the protocol, it could mean eliminating portions of the history of some coins. If I send a coin to MrShady and he sends it back, both transactions could potentially be pruned.
318 2015-03-11 19:24:11 <hearn> the assuming behind pruning is that some people will keep all history forever, no matter what
319 2015-03-11 19:24:13 <hearn> e.g. block explorers
320 2015-03-11 19:24:20 <Raystonn> This is not client-side pruning, but something new.
321 2015-03-11 19:24:28 <belcher> at the very least, economics and data analysers
322 2015-03-11 19:25:59 <gmaxwell> Raystonn: what you're describing requires everyone to forget data in order to have an advantage, but has not mechenism to make them do so.
323 2015-03-11 19:26:07 <Raystonn> Yes, some will keep all history. That is unavoidable. But avoiding retransmission of those shady transactions in the future (whenever a new client syncs) would help.
324 2015-03-11 19:27:42 <gmaxwell> Help how?
325 2015-03-11 19:27:57 <Raystonn> This would be a manipulation of the entire blockchain, pruning as new nodes sync. The new node would never see those transactions.
326 2015-03-11 19:28:05 <gmaxwell> (I'm ignoring for a moment that this breaks the security model and such, just to developed the idea of what it gains at all)
327 2015-03-11 19:28:58 <gmaxwell> Raystonn: no one accidentally learns about a coin's history already; you expressed a fungibility advantage but I don't understand where you think it comes from. Some (many) will remember and publish the connections to anyone who cares to know about them.
328 2015-03-11 19:29:03 <marioxcc> Raystonn: I think that you have a blurry idea. Have you worked the details? E.g: how would new clients verify that the current state of the chain is correct?.
329 2015-03-11 19:29:05 <Raystonn> Which portion of the security model is affected removing those two transactions?
330 2015-03-11 19:29:31 <Raystonn> Yes, it's a blurry idea. I agree.
331 2015-03-11 19:30:00 <Raystonn> It's not something I am working on, but an idea I thought I would pass on.
332 2015-03-11 19:30:56 <marioxcc> marioxcc: Thanks. I can't develop it further, though. I'm not involved with the development of Bitcoin software.
333 2015-03-11 19:31:33 <deepcore> Hey, my bitcoind seems to be stuck at progress=0.999999 for some time is that normal?
334 2015-03-11 19:32:03 <gmaxwell> Raystonn: wrt the security model, the ability for the network and each of its participants to indivigually enforce that the earlier participants didn't write themselves a blank check for a bunch of coins, but instead followed the rules.
335 2015-03-11 19:32:18 <deepcore> 2015-03-11 19:32:11 UpdateTip: new best=00000000000000000b77a08ba7b481321190343c90c7f160f20a02914cbf8bf2 height=347204 log2_work=82.40958 tx=62101674 date=2015-03-11 19:31:27 progress=0.999999 cache=135331
336 2015-03-11 19:32:22 <gmaxwell> deepcore: that doesn't sound 'stuck' ... bitcoin is never done syncing.
337 2015-03-11 19:32:46 <Raystonn> Right now everything in the blockchain lives forever. The question I am raising here: is that really required as long as all final outputs remain the same?
338 2015-03-11 19:32:55 <gmaxwell> There isn't a "done" because there is no single definition of done. There is no one authoritative blockchain.
339 2015-03-11 19:33:00 <marioxcc> What think client would you recommend for GNU/Linux on technical grounds?.
340 2015-03-11 19:33:29 <deepcore> gmaxwell: ah, ok, I thought it should reach "1" once it was done syncinc the historic data
341 2015-03-11 19:33:58 <gmaxwell> Raystonn: It's required pratically but not in a fundimental sense to provide the complete security and autotomy properties of the system.
342 2015-03-11 19:34:14 <gmaxwell> deepcore: no because it always expects that there are more blocks to go. :) (how could it know if there weren't?)
343 2015-03-11 19:34:30 <deepcore> gmaxwell: good point :) thanks
344 2015-03-11 19:34:53 <marioxcc> Does the Bitcoin protocol allows mankind to get rid of the requirement of having to store an unbound amount of useless data?.
345 2015-03-11 19:34:55 <gmaxwell> perhaps we should change the log output to say ~=
346 2015-03-11 19:35:04 <marioxcc> (I.e: all past transactions)
347 2015-03-11 19:35:17 <Raystonn> How would security be harmed pruning a transaction where I sent myself a coin?
348 2015-03-11 19:35:32 <gmaxwell> marioxcc: see section 7 of bitcoin.pdf
349 2015-03-11 19:35:49 <gmaxwell> Raystonn: you're already not required to store the history locally for yourself.
350 2015-03-11 19:36:26 <marioxcc> Raystonn: transactions have other transactions as inputs, if you send yourself a transaction, and then use THAT transaction (Call it T) in a new one (call it T') then full clients need to know T to verify T'.
351 2015-03-11 19:36:31 <marioxcc> gmaxwell: Ok, thanks.
352 2015-03-11 19:37:13 <gmaxwell> marioxcc: thats not quite correct and doesn't reflect how bitcoin core works.
353 2015-03-11 19:37:16 <Raystonn> Yes, but this is not about storage space. This is about ensuring fungibility. I don't want to see coins from source A treated differently than coins from source B. Fungibility.
354 2015-03-11 19:38:10 <Raystonn> Pruning might help avoid source identification.
355 2015-03-11 19:38:11 <gmaxwell> Raystonn: I agree thats _desirable_ but something being desirable doesn't make any particular measure achieve that outcome. Not a single thing you've described brings about that outcome, because parties can and will track additional data.
356 2015-03-11 19:52:26 <treehug88> Luke-Jr: added test data at https://github.com/bitcoin/bitcoin/pull/5847
357 2015-03-11 19:53:46 <Adlai> Raystonn: this whole approach is one of 'hiding data', but the data exists and can be proven using the blockchain. breaking bitcoin's lack of fungibility breaks bitcoin itself.
358 2015-03-11 19:55:00 <Adlai> even if i pruned history, a 'deanonymization service' could exist where i'd pay for a coin's history, along with a few merkle branches that prove that this history is correct
359 2015-03-11 19:59:53 <Giszmo> Hi. Is there any BIP/development around receiving recurring payments to an extended public key? I now request to share a BIP44 account level (m / 44' / 0' / 0') xpub key with my app in order to receive to m / 44' / 0' / 0' / 0 / * but that would result in wallets that shared that account level to use m / 44' / 0' / 0' / 1 / * for change addresses. In my app I don't need to know the account level but only one external chain. In other terms: I
360 2015-03-11 20:04:18 <hearn> Giszmo: there have been proposals and draft BIPs posted to the bitcoin-development list in the past
361 2015-03-11 20:04:25 <hearn> Giszmo: however no implementation traction afaik
362 2015-03-11 20:04:57 <Giszmo> hearn: you remember how these were called? pay to xpub?
363 2015-03-11 20:05:08 <Giszmo> something I could google for?
364 2015-03-11 20:08:42 <hearn> Giszmo: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03838.html
365 2015-03-11 20:09:24 <Giszmo> hearn: thank you
366 2015-03-11 20:18:55 <treehug88> out of curiosity, what is the status of bitcoin-core on fedora? Does it build easily, and is there any chance of it getting packaged as an official fedora RPM?
367 2015-03-11 20:22:09 <Giszmo> hearn: this is a bip 70 extension, not a bip 44 extension. It would not work for the use case I had in mind. Think of allowance, think of recurring payments to any entity that might be *offline*. Currently you would send to the same address over and over again which is bad for privacy or you would require to receive a new address which is bad/delicate for security.
368 2015-03-11 20:22:39 <hearn> there's no meaning to the phrase "bip44 extension". it's not designed to be an extensible thing.
369 2015-03-11 20:22:44 <hearn> you do not need to be online to use bip 70
370 2015-03-11 20:22:48 <hearn> it's just a file format.
371 2015-03-11 20:23:24 <hearn> the idea behind the extension is, it just says "make a payment like this (old way) and if you recognise these new fields, here's how to edit the script to derive a new HD key each time, and btw here is a payment schedule i would like defined under some schema"
372 2015-03-11 20:23:30 <hearn> (actually that's two extensions)
373 2015-03-11 20:29:33 <gmaxwell> Last call on any blockers for assigning a BIP number to this simple spec specifying lexagraphic ordering by default for p2sh multisignature: https://github.com/afk11/bips/blob/b924a75f66580ffa12b6f72b625ec1575d002691/bip-0090.mediawiki
374 2015-03-11 20:30:08 <gmaxwell> (i.e. are there any important applications or optimizations which are broken by using this particular ordering rather than some other one which need to be discussed)
375 2015-03-11 20:37:26 <Giszmo> hearn: as far as I can see, bip70 does not define how to share an xpub key and neither would it address at which level in the hierarchy that xpub key would be located and that was my concern: how do wallets discover payments? How does a bip39 key alone lead to all payments being discovered if such an xpub scheme was used? bip44 explicitly sets the look-ahead at the account level to 1, so it's clearly not meant for receiving payments to new a
376 2015-03-11 20:38:12 <hearn> Giszmo: bip 70 doesn't define how to do those things, but it's designed to be an extensible bucket where you can put any additional data that would be needed as part of a payment relationship. that's why it makes sense to put stuff there.
377 2015-03-11 20:38:29 <hearn> Giszmo: wallets have a lookahead zone of keys that weren't used yet
378 2015-03-11 20:47:22 <Giszmo> hearn: the look ahead 20 for the external addresses, yes but that is within one account. I have the practical need to receive address streams into my app from wallets (as I don't want to code a wallet myself for obvious reasons) and I see this need in a person to person relationship, too. If my brother tells me to send him some coins, I want to be able to send him those without having to reuse addresses or ask him for a new address. So far,
379 2015-03-11 20:54:33 <hearn> Giszmo: you got cut off there
380 2015-03-11 20:54:38 <hearn> Giszmo: last words are "so far, "
381 2015-03-11 20:55:16 <hearn> Giszmo: the idea is your brother would get you a bip70 payment request file in some way. today email works but is a bit clunky. there is work in progress to try and smooth this ux a bit
382 2015-03-11 20:56:05 <Giszmo> So far, bip70 and many other bips assume the recipient has a server running 24/7. I think every recipient deserves the privacy that one time addresses provide. I think I explained well why this should be a standard wallet feature on every phone but if you are not convinced, I'd give you more details in a pm.
383 2015-03-11 20:57:35 <hearn> BIP 70 doesn't assume that actually even though that's normally how it's used.
384 2015-03-11 20:58:37 <hearn> you can get a payment request via non-interactive transports like NFC tags or emails, and the payment_url is optional
385 2015-03-11 20:58:56 <hearn> obviously though - the UX is better if there is a server that can sit around collecting the extra metadata on the payment path. that's why chris is doing Subspace
386 2015-03-11 20:59:06 <hearn> the idea is it's a semi-p2p network of payment protocol servers
387 2015-03-11 21:15:34 <Luke-Jr> hearn: on the topic of incompatible wallet schemes, couldn't wallets importing a new seed simply scan all of the possible ones concurrently until it identifies the one being used?
388 2015-03-11 21:16:03 <hearn> if the seed is also encoding a version number, for example, it just won't be able to parse the result of decoding
389 2015-03-11 21:16:08 <Luke-Jr> eg, build a bloom filter for the first 20 keys of each scheme, then when it finds a match search out which algorithm was used
390 2015-03-11 21:16:19 <hearn> if there is no date, it has to start scanning from the standardisation time of BIP 39 which will obviously get slower and slower as time goes on
391 2015-03-11 21:16:35 <hearn> you could do dynamic switching between BIP32 and BIP44 that way though yes
392 2015-03-11 21:30:08 <gmaxwell> Luke-Jr: so I can intentially derrive a pubkye for you under the wrong scheme, pay a tiny amount to it and make your wallet break if you try to reload from the key?
393 2015-03-11 21:30:46 <Luke-Jr> gmaxwell: as long as you have an earlier tx it should be okay ;)
394 2015-03-11 21:31:06 <Luke-Jr> it's necessary to scan all schemes concurrently though, yes
395 2015-03-11 21:31:22 <Luke-Jr> besides, wouldn't you need my private seed for that? :p
396 2015-03-11 21:34:38 <gmaxwell> Luke-Jr: need to be able to idenfify the structure for watching keys too; no?
397 2015-03-11 21:35:04 <Luke-Jr> watching seed is still private IMO
398 2015-03-11 21:37:20 <gmaxwell> Luke-Jr: thats missing the point; it means in theory someone could break you (assuming you didn't do concurrent checking, as you note) who isn't you; and thats busted. It's also not very scalable as mike notes.
399 2015-03-11 22:32:58 <Luke-Jr> oh, my USB Armory finally sync'd
400 2015-03-11 22:33:25 <Luke-Jr> even with dbcache=5, it had a number of bad_allocs along the way though
401 2015-03-11 22:33:43 <Luke-Jr> wonder if it can survive now just going 1 block at a time
402 2015-03-11 23:29:01 <jonasschnelli> Luke-Jr, do you run a full node on the USB Armory?
403 2015-03-11 23:29:11 <Luke-Jr> yes
404 2015-03-11 23:30:01 <jonasschnelli> impressed that this works... how many days took the catchup?
405 2015-03-11 23:30:08 <Luke-Jr> months*
406 2015-03-11 23:30:16 <sipa> wut?
407 2015-03-11 23:30:21 <jonasschnelli> lol!
408 2015-03-11 23:30:57 <Luke-Jr> if debug.log hadn't truncated, I'd be more precise
409 2015-03-11 23:31:05 <Luke-Jr> I started it before I went to CA last month
410 2015-03-11 23:31:16 <hearn> Luke-Jr: you have a dedication to running full nodes that is impressive :)
411 2015-03-11 23:31:28 <jonasschnelli> ;-)
412 2015-03-11 23:32:18 <sipa> jonasschnelli: very nice meeting you!
413 2015-03-11 23:34:31 <jonasschnelli> sipa: yes. Was really nice and thanks for sharing your thoughts.
414 2015-03-11 23:35:14 <jonasschnelli> Luke-Jr: don't try to run a full node on you coffee AMtel chip!
415 2015-03-11 23:35:30 <jonasschnelli> Coffee Machine