1 2015-01-19 06:48:41 <earlz> So, to ensure I understand multisig/p2sh.. a traditional multisig transaction can be constructed without access to the private keys of the tx (ie, the participants)
2 2015-01-19 06:49:01 <earlz> And a p2sh transaction, must have access to the private keys (because it must be known what the signature is)
3 2015-01-19 06:50:23 <sipa> ??
4 2015-01-19 06:51:26 <earlz> for a traditional non-p2sh multisig transaction, you don't require signatures at teh time the tx is created..
5 2015-01-19 06:51:51 <earlz> and I think for a p2sh multisig transaction, you require signatures at the time the tx is created, because you must know the hash of the redeem script
6 2015-01-19 06:51:56 <earlz> or am I thinking about this wrong
7 2015-01-19 06:54:57 <sipa> i don't see why p2sh or not should matter
8 2015-01-19 06:55:14 <sipa> you can create the entire transaction without the scriptsigs
9 2015-01-19 06:55:17 <sipa> always
10 2015-01-19 06:57:24 <earlz> Ok, if the hash of the redeem script `pubkey << checksigverify` is X, then the redeem script would be `signature << pubkey << checksigverify` and then the original input transaction would be `op_hash160 << X << equal` right?
11 2015-01-19 06:57:48 <op_mul> has anybody else had problems with 0.10. nodes being glacier slow to sync? on some new hardware I've got 0.9 syncing at tens of thousands of blocks at second at the start, 0.10 is doing maybe 10.
12 2015-01-19 06:57:56 <earlz> (ie, a p2sh for a simple pay-to-publickey)
13 2015-01-19 06:58:35 <op_mul> from the network, loadblock or a bootstrap it doesn't seem to matter. same oddly slow sync even before the checkpoints end.
14 2015-01-19 07:01:50 <earlz> p2sh seems more robust.. why hasn't p2sh replace p2pkh yet?
15 2015-01-19 07:04:23 <op_mul> earlz: webbtc.com is quite good for visualising scripts.
16 2015-01-19 07:04:45 <op_mul> http://webbtc.com/script/7434134e711dfb4ca0c713a6867a03d68ba430a3534dd2b4d1f16ced718f8eda:0
17 2015-01-19 11:43:26 <michagogo> coryfields: so what was the resolution of the font issue (#5671)? Still some issues for 0.10 that'll be fixed in later versions by newer SDK?
18 2015-01-19 11:43:42 <michagogo> May want to add something to the release notes
19 2015-01-19 13:20:41 <gdm85> has somebody added those few notes about breaking features?
20 2015-01-19 14:03:47 <jonasschnelli> gdm85, could you set up nightly builds?
21 2015-01-19 14:04:47 <gdm85> jonasschnelli: yep. I am waiting for one of the spare VPSes to be free, but all the tools and building machine are ready
22 2015-01-19 14:05:30 <jonasschnelli> gdm85, good. Because i just finished the script and it would be good to have 2-3 other builds so people could compare the sigs
23 2015-01-19 14:05:44 <jonasschnelli> gdm85, i will set up a cron job at UTC 00:00
24 2015-01-19 14:06:11 <jonasschnelli> gdm85, if you do the same, it will be very likely that we build the same head
25 2015-01-19 14:06:54 <gdm85> jonasschnelli: agree
26 2015-01-19 14:07:19 <gdm85> jonasschnelli: I was thinking of building every x minutes, starting from 00:00. and they will be indexed by the commit sha1 hash
27 2015-01-19 14:07:31 <gdm85> e.g. if it's already there, won't build again for that commit
28 2015-01-19 14:07:40 <gdm85> jonasschnelli: which script did you finish? for your own automated builds?
29 2015-01-19 14:08:33 <jonasschnelli> gdm85, a head-sha compare and maybe a copy rather then a build would be nice. Will do that soon. But CPU tick at UTC 00:00 is available on my srv.
30 2015-01-19 14:08:43 <jonasschnelli> gdm85, i wrote a custom python script
31 2015-01-19 14:09:01 <jonasschnelli> gdm85, simple: update git, build after release-process.md, copy file, etc.
32 2015-01-19 14:11:39 <gdm85> jonasschnelli: and the filesystem tree hash (e.g. /home/ubuntu)
33 2015-01-19 14:12:39 <jonasschnelli> ?
34 2015-01-19 14:17:12 <jhns> hello
35 2015-01-19 14:17:42 <jhns> the function "Misbehaving()" in net.cpp requires the lock cs_main.
36 2015-01-19 14:17:51 <jhns> but it isn't aquired in ProcessMessage() ?
37 2015-01-19 14:18:24 <jhns> i.e., Misbehaving is called in ProcessMessage, but I don't see where the cs_main lock is aquired
38 2015-01-19 14:18:39 <sipa> good catch
39 2015-01-19 14:19:11 <jhns> thx 8)
40 2015-01-19 14:19:26 <sipa> can you file an issue?
41 2015-01-19 14:19:29 <jhns> yep
42 2015-01-19 14:20:27 <jhns> one further question.. I'm experimenting with the bitcoin client, trying to hold as many connections as possible, so performance is an issue for me. Is there any problem with using a separate lock for the 'State()' function, not the cs_main lock?
43 2015-01-19 14:23:00 <jhns> (https://github.com/bitcoin/bitcoin/issues/5678)
44 2015-01-19 14:23:59 <jhns> sipa: I don't see why one shouldn't use a separate lock for State, i.e. why cs_main is required
45 2015-01-19 14:26:46 <gdm85> jonasschnelli: sorry, I mean: something like midnightmagic needed last time e.g. sha256sum of all files that were used during the build
46 2015-01-19 14:27:07 <gdm85> (the result contains already packages information, so we can skip everything outside /home/ubuntu)
47 2015-01-19 14:28:00 <gdm85> jonasschnelli: with mine I'll go for a from-scratch build every time. only the depends' cache will be kept (although separate for each OS target)
48 2015-01-19 14:28:35 <sipa> jhns: over time those locks should be split up, yes
49 2015-01-19 14:29:06 <jonasschnelli> gdm85, Okay. I'll do a build from the scratch every time (takes around 30min)
50 2015-01-19 14:29:20 <sipa> jhns: but the state should be split up for different types of modules too; we shouldn't handle all message processing in one module
51 2015-01-19 14:29:33 <gdm85> jonasschnelli: you think that otherwise they wouldn't be comparable? actually I'd prefer if you do it as you said, so we catch differences :)
52 2015-01-19 14:29:56 <jhns> sipa: okay, but so there shouldn't be a problem with changing this to a separate lock for my purposes
53 2015-01-19 14:30:05 <jhns> to increase performance
54 2015-01-19 14:32:10 <jhns> (I thought it has a reason why it has to be cs_main)
55 2015-01-19 14:53:37 <Utal> hi, i want to contribute to bitcoin....i have been working on tor projects lately....can anyone help
56 2015-01-19 14:55:18 <earlz> Utal: find an issue that looks interesting and dig in? ;)
57 2015-01-19 15:02:49 <Utal> earlz: hi...thanks for answering...i have been working on a project where i need to know about the bitcoin encription process .....can u send me some link which can help me in this....
58 2015-01-19 15:03:15 <wumpus> Utal: what are your skills?
59 2015-01-19 15:04:18 <Utal> js python php java c++ c
60 2015-01-19 15:05:33 <wumpus> ok, that's good, then you can help here. in bitcoin core we use c++ for the main code, and python for the test code and tools
61 2015-01-19 15:06:19 <wumpus> any specific part that interest you? e.g. network code, gui code, wallet?
62 2015-01-19 15:06:49 <Utal> wallet and network....
63 2015-01-19 15:06:56 <Luke-Jr> so something that occurred to me over the weekend re CLTV: has anyone looked at if there may be an incenive problem due to UTXO usage patterns? I don't think there is, but maybe someone has given it more thought
64 2015-01-19 15:10:01 <Utal> wumpus: wallet and network....
65 2015-01-19 15:11:29 <jonasschnelli> Utal you could look at HDWallet/Bip32 implementation? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
66 2015-01-19 15:12:57 <sipa> Utal: also, bitcoin does not use any encryption (except locally to password-proteft wallets)
67 2015-01-19 15:13:12 <Luke-Jr> I don't think there is because: 1) people can already make permanent UTXOs, 2) people can just wait to redeem temporary UTXOs now
68 2015-01-19 15:16:10 <wumpus> Utal: ok, if you need ideas, lots of issues concerning those e.g. https://github.com/bitcoin/bitcoin/labels/P2P https://github.com/bitcoin/bitcoin/labels/Wallet
69 2015-01-19 15:19:49 <earlz> Is there a reason to not do all transactions as P2SH?
70 2015-01-19 15:20:11 <earlz> or are there any transactions that can not be done as P2SH?
71 2015-01-19 15:20:39 <wumpus> you can do all transactions as P2SH
72 2015-01-19 15:22:28 <earlz> where exactly does the redeem script go? wouldn't that go in scriptSig?
73 2015-01-19 15:22:38 <wumpus> it's just that P2PKH existed before that, and most people are still using that
74 2015-01-19 15:22:40 <earlz> P2SH is so hard to understand ugh
75 2015-01-19 15:24:27 <jonasschnelli> wumpus, nice PoC (http libenvent) good idea to not use boost::asio. I could support this by writing some test
76 2015-01-19 15:24:29 <wumpus> yes, the P2SH script is an extra argument in the scriptSig
77 2015-01-19 15:24:57 <earlz> but I thought the scriptsig shoudl only contain data pushes
78 2015-01-19 15:25:02 <Luke-Jr> there is no sign-message for p2sh
79 2015-01-19 15:25:17 <Luke-Jr> and probably shouldn't be due to key reuse
80 2015-01-19 15:25:20 <wumpus> jonasschnelli: thanks. Yes, it needs build system support (so that the travis tests work), and needs to be checked on windows/macosx
81 2015-01-19 15:25:37 <wumpus> earlz: the script inside a data push
82 2015-01-19 15:25:55 <wumpus> jonasschnelli: but some stress testing of the RPC server would also help a lot
83 2015-01-19 15:25:56 <Luke-Jr> earlz: BIP16 (which is live) uses only data pushes
84 2015-01-19 15:26:06 <Luke-Jr> earlz: and scriptSig doesn't *have* to be only pushes
85 2015-01-19 15:26:07 <earlz> mm.. so you encode the script to bytes and push that?
86 2015-01-19 15:26:26 <earlz> well, I know only data pushes are standard at least
87 2015-01-19 15:26:30 <jonasschnelli> wumpus, Yes. i thought about stress testing it with some thread-monkey-tests
88 2015-01-19 15:26:35 <wumpus> jonasschnelli: e.g., to find cases where the current one fails and this one continues to work, a simple one is just 'open four connections' :P
89 2015-01-19 15:26:48 <wumpus> right
90 2015-01-19 15:26:56 <jonasschnelli> wumpus, and the other-way-round. :)
91 2015-01-19 15:26:58 <Luke-Jr> earlz: if you were looking at BIP17 (which uses non-push in scriptSig), just ignore it; BIP 17 is not happening
92 2015-01-19 15:27:08 <wumpus> jonasschnelli: well hopefully there is no the other way around
93 2015-01-19 15:27:32 <wumpus> jonasschnelli: (except SSL, which is possible to support but I haven't bothered for now)
94 2015-01-19 15:27:42 <earlz> I'm not looking at anything currently
95 2015-01-19 15:27:46 <jonasschnelli> wumpus, yes. i think it's sane to switch the rpc server implementation when there are enough tests
96 2015-01-19 15:27:59 <sipa> bip16 _requires_ the scriptsig to be push only
97 2015-01-19 15:28:30 <earlz> how does the redeem script actually get run, if it's just a data push?
98 2015-01-19 15:28:37 <Luke-Jr> earlz: well, looking at specs is really something you should do before asking questions ;)
99 2015-01-19 15:28:38 <wumpus> earlz: magic(TM)
100 2015-01-19 15:28:40 <jonasschnelli> wumpus, i'm also not sure if ssl is widely used... mostly i assume its localhost<->localhost. But even then it's useful. But no main-prio IMO
101 2015-01-19 15:29:08 <wumpus> jonasschnelli: I don't think it's used a lot, and adds attack surface
102 2015-01-19 15:29:29 <earlz> I've looked at them, I feel like I understand the gist of it, but not how it all actually works as for what gets executed and how it's intepreted
103 2015-01-19 15:29:32 <wumpus> jonasschnelli: also without RPC SSL support, we can remove the OpenSSL dependency completely after ECDSA uses secp256k1
104 2015-01-19 15:29:57 <Luke-Jr> does libevent's HTTP not support SSL internally?
105 2015-01-19 15:29:57 <sipa> let's drop ssl support in core, and provide a wrapper tool (stunnel?) that also adds support for rpc method filtering etc
106 2015-01-19 15:30:02 <wumpus> jonasschnelli: there's something to be said for dropping it
107 2015-01-19 15:30:09 <sipa> i meam, stunnel based
108 2015-01-19 15:30:15 <wumpus> Luke-Jr: oh sure, as said above, it is possible to use libevent with openssl
109 2015-01-19 15:30:30 <wumpus> Luke-Jr: it's just A) extra work B) extra testing C) extra attack surface
110 2015-01-19 15:30:32 <helo> yeah, tunneling would be easy for anyone to do if they needed a secure connection
111 2015-01-19 15:30:41 <wumpus> stunnel sounds good to me
112 2015-01-19 15:30:51 <earlz> I don't know of anyone that uses the RPC SSL support at least.. I personally would rather do a generic SSH tunnel or some such
113 2015-01-19 15:38:19 <Dekker3D> Hey all.
114 2015-01-19 15:39:16 <wumpus> hey
115 2015-01-19 15:42:38 <Dekker3D> I'd like to ask if any of you know some elegant methods of handling the cryptocurrency stuff on Android.
116 2015-01-19 15:42:38 <Dekker3D> I've been developing a game for Android, and it includes altcoin integration. The only wallet currently available for this altcoin is a simple fork/clone of the standard Bitcoin Android wallet from some time ago.
117 2015-01-19 15:42:39 <Dekker3D> Like retrieving a cash-out address from a separate wallet app
118 2015-01-19 15:42:41 <Dekker3D> Or telling the wallet app about a deposit address.
119 2015-01-19 15:42:42 <Dekker3D> My current idea is to simply use the clipboard.
120 2015-01-19 15:42:59 <Dekker3D> Which is not very elegant, since Android doesn't use the clipboard much.
121 2015-01-19 15:43:38 <Dekker3D> Does anyone here have a better idea for interacting with a wallet like that?
122 2015-01-19 15:44:48 <wumpus> I don't think bitcoin wallets on android have any common protocol for interacting with other applications
123 2015-01-19 15:45:54 <sipa> yeah, best talk to people implementing those wallets
124 2015-01-19 15:46:16 <Dekker3D> That's a pity.
125 2015-01-19 15:46:57 <Luke-Jr> aschildbach: ^
126 2015-01-19 15:46:59 <Dekker3D> A common protocol for this kind of thing might be useful. Some wallet-related actions on Android are pretty clumsy right now.
127 2015-01-19 15:47:23 <Luke-Jr> Dekker3D: wait, you're not the guy behind that Android game that spams the network?
128 2015-01-19 15:47:29 <Dekker3D> Hah, no.
129 2015-01-19 15:47:36 <Luke-Jr> I forget the name, just heard about it in Miami..
130 2015-01-19 15:47:39 <Dekker3D> That's iPhone.
131 2015-01-19 15:47:43 <Luke-Jr> ah
132 2015-01-19 15:47:54 <Dekker3D> I would try playing it, but I don't have an iPhone.
133 2015-01-19 15:48:15 <Dekker3D> At worst I'll be spamming the GCoin network.
134 2015-01-19 15:48:28 <Dekker3D> And as there's 3 different GCoin networks out there, I don't think anyone will really notice :P
135 2015-01-19 15:48:30 <Luke-Jr> Dekker3D: well, if you're not interested in Bitcoin, then it's kinda off-topic here.. ;)
136 2015-01-19 15:49:02 <Dekker3D> Luke-Jr, the devs behind GCoin are.. competence-challenged and busy. And they hardly altered the wallet.
137 2015-01-19 15:49:03 <wumpus> if it's not related to bitcoin it's completely off-topic here
138 2015-01-19 15:49:12 <Dekker3D> So I figured I could get some useful answers here.
139 2015-01-19 15:49:18 <Luke-Jr> Dekker3D: that's not our problem
140 2015-01-19 15:49:28 <Luke-Jr> Dekker3D: if you want competence and answers here, then use Bitcoin ;)
141 2015-01-19 15:49:32 <Dekker3D> Just saying the same wallet used to be for Bitcoin too.
142 2015-01-19 15:49:37 <Dekker3D> Anyway, thanks for the info.
143 2015-01-19 15:51:56 <Dekker3D> Luke-Jr, that game you mentioned is called Sarutobi or something, I think.
144 2015-01-19 15:52:13 <Luke-Jr> thanks
145 2015-01-19 15:57:31 <earlz> I really wish there was a place where competent altcoin devs hung out heh
146 2015-01-19 15:58:31 <justanotheruser> earlz: if they were competent they probably would be working on a system that works
147 2015-01-19 15:58:38 <justanotheruser> and is useful
148 2015-01-19 15:58:53 <justanotheruser> and there are only 2-3 altcoins that have that
149 2015-01-19 15:59:17 <earlz> eh, can't try experimental technology with bitcoin though, see checklocktimeverify and the different difficulty adjustment algorithsm
150 2015-01-19 16:00:02 <earlz> but yea, most altcoins are shitty copy-paste-search-replace (btw, I review altcoins https://github.com/Earlz/coinreviews ;) )
151 2015-01-19 16:00:21 <Luke-Jr> earlz: ##altcoin-dev exists
152 2015-01-19 16:01:05 <Luke-Jr> earlz: and yes, you can try experimental tech with Bitcoin just fine
153 2015-01-19 16:01:11 <earlz> I think I joined that a while back and it was pretty much dead..
154 2015-01-19 16:01:13 <Luke-Jr> testnet works
155 2015-01-19 16:01:23 <Luke-Jr> ##altcoin-dev has grown over the past few months
156 2015-01-19 16:01:32 <earlz> well, still can't try new opcodes and such on testnet
157 2015-01-19 16:01:47 <Luke-Jr> it's just a hardfork
158 2015-01-19 16:01:47 <Luke-Jr> sure you can
159 2015-01-19 16:03:31 <earlz> there's also the matter of hardforks are more complicated, much less if you want ot do something more radical like changing block/tx formats or something.. like you couldn't test PoS on testnet, at least not as easily as just forking bitcoin outright
160 2015-01-19 16:03:47 <earlz> I just wish more altcoin devs moved off of the ancient 0.8 and 0.7 code bases
161 2015-01-19 16:04:02 <Luke-Jr> they're only complicated when you want to deploy to the mainnet
162 2015-01-19 16:04:11 <Luke-Jr> with testnet, you can just change it and go
163 2015-01-19 16:05:16 <earlz> you have to encase everything with if(testnet) and such at least, which isn't trivial for data structures
164 2015-01-19 16:05:50 <earlz> eh either way
165 2015-01-19 16:05:55 <earlz> off-topic
166 2015-01-19 16:06:11 <Luke-Jr> no, you just tell people not to run the code on mainnet :P
167 2015-01-19 16:07:15 <earlz> well yea, but at that point what's the difference between it being bitcoin and an altcoin? ;)
168 2015-01-19 16:08:08 <Luke-Jr> nobody is trying to pretend it's anything more than a test :P
169 2015-01-19 16:08:42 <Luke-Jr> earlz: eg, see https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/ddc09d3d5423aec6104e4976ef1e17c4608cc6a2
170 2015-01-19 16:09:19 <earlz> Also, some things aren't easily tested without scale.. but I guess that's the whole philisophical argument of eventually everything condenses to bitcoin, or everything condenses to bitcoin adn a few altcoins for specialized purposes
171 2015-01-19 16:09:34 <Luke-Jr> earlz: well, that's what sidechains will help out with
172 2015-01-19 16:09:52 <earlz> yea, counterparty and such?
173 2015-01-19 16:10:29 <earlz> what about completely radical stuff like NXT and Ethereum? Although I disagree that either are a significant improvement.. they do serve some applications better
174 2015-01-19 16:10:30 <Luke-Jr> eh?
175 2015-01-19 16:10:44 <Luke-Jr> radical stuff like NXT and Ethereum can be done as sidechains
176 2015-01-19 16:10:55 <wumpus> let's not have that discussion here
177 2015-01-19 16:11:02 <earlz> yea, my thoughts as well
178 2015-01-19 16:11:09 <Luke-Jr> earlz: check out http://www.blockstream.com/sidechains.pdf ;)
179 2015-01-19 16:11:12 <earlz> re: wumpus
180 2015-01-19 16:12:03 <wumpus> altcoins being off topic in this channel is not about 'bitcoin is better', just that this channel is about bitcoin development and nothing else
181 2015-01-19 16:12:15 <jgarzik> +1
182 2015-01-19 16:12:38 <Luke-Jr> yeah, i guess we've gone into -wizards material now âº
183 2015-01-19 16:13:08 <earlz> lol yea, I was aware of -wizards
184 2015-01-19 16:13:56 <earlz> either way, part of the big problem with getting a decent community of altcoin-devs, besides most devs being copy-paste-search-replace types is anyone that knows their stuff usually feels like they're competing in the never-ending altcoin arms race to try to get more market cap than the other lol
185 2015-01-19 16:14:36 <earlz> hence why a disturbing recent trend has been to keep things closed source
186 2015-01-19 16:15:12 <Luke-Jr> earlz: let's continue these topics in #bitcoin-wizards and ##altcoin-dev respectively
187 2015-01-19 16:16:08 <earlz> yep, just pointing out a possible reason
188 2015-01-19 16:16:59 <Dekker3D> Do I.. want to know what #bitcoin-wizards is all about?
189 2015-01-19 16:17:22 <Dekker3D> Is this "wizards" as in "folks who know their shit" or "wizards" as in "30 year old 4chan virgins"?
190 2015-01-19 16:18:05 <Luke-Jr> Dekker3D: it's more or less theoretical future improvements to Bitcoin that aren't related to developmetn of Bitcoin today
191 2015-01-19 16:18:15 <Dekker3D> Ah.
192 2015-01-19 16:18:30 <Dekker3D> So, -dev is practise and -wizards is theory
193 2015-01-19 16:18:52 <Luke-Jr> well, theory applicable to today's Bitcoin is -dev too
194 2015-01-19 16:20:17 <earlz> -dev == next release. -wizards is years away stuff, or non-trivial hard/soft forks
195 2015-01-19 16:20:54 <Dekker3D> Cool.
196 2015-01-19 16:21:18 <wumpus> talk about what belongs in what channel.. belongs in #bitcoin I suppose :p
197 2015-01-19 16:22:03 <earlz> lol
198 2015-01-19 16:22:07 <earlz> #bitcoin-meta
199 2015-01-19 16:22:26 <earlz> talk about what goes on in meta goes in #bitcoin-meta-meta ;)
200 2015-01-19 16:22:43 <Dekker3D> Wow.
201 2015-01-19 16:22:49 <Dekker3D> The rules are like porn to you two, aren't they?
202 2015-01-19 16:23:10 <Utal> hey focks can u explain me how this minig stuff works...
203 2015-01-19 16:23:22 <wumpus> not really, but focus is very important
204 2015-01-19 16:23:24 <teward> Utal: #bitcoin-mining might be a better location for that discussion
205 2015-01-19 16:23:29 <Luke-Jr> Utal: #bitcoin-mining unless you mean very technical info
206 2015-01-19 16:23:53 <Luke-Jr> (in which case, the wiki has some good material to read first)
207 2015-01-19 16:26:14 <Utal> no no i just want the concept... i was just going through the docomenation and clearing my basics...i am actually pretty new in bitcoin
208 2015-01-19 16:28:06 <Utal> luke-Jr : thats what i am going though
209 2015-01-19 16:28:46 <ThomasV> hello, is there an effort to send/receive bip70 requests using email aliases?
210 2015-01-19 16:29:10 <earlz> email aliases?
211 2015-01-19 16:29:12 <ThomasV> hearn: maybe you know ^
212 2015-01-19 16:29:42 <ThomasV> the idea is, you trust your email server to sign requests for you
213 2015-01-19 16:32:37 <wumpus> that was one of initial ideas for bip70, you can attach them as invoices to mails. Although you still need signing, I don't think a mail server normally does any signing
214 2015-01-19 16:33:26 <hearn> hello
215 2015-01-19 16:33:33 <hearn> ThomasV: email aliases?
216 2015-01-19 16:33:58 <hearn> ThomasV: i.e. you attach a payment request as a file and the DKIM signature is extracted+used to show identity in the wallet?
217 2015-01-19 16:34:07 <ThomasV> hearn: sort of, yes. but for sending requests, not coins
218 2015-01-19 16:34:34 <hearn> it could be done but would require tight integration between wallet and email inbox of the recipient,
219 2015-01-19 16:34:45 <hearn> it seems easier to just get a free S/MIME cert and use that for signing in the standard way
220 2015-01-19 16:34:56 <hearn> wallets can automate the whole thing behind the scenes
221 2015-01-19 16:35:21 <ThomasV> are you aware of any wallet working on that?
222 2015-01-19 16:36:02 <ThomasV> my reasoning is that it could create a user experience without bitcoin addresses
223 2015-01-19 16:36:23 <hearn> andreas schildbach added support for signing with email certificates to his wallet, yes. but you have to get the cert installed using your web browser e.g. here https://www.comodo.com/home/email-security/free-email-certificate.php
224 2015-01-19 16:36:25 <jgarzik> ThomasV, ...which is a great long term goal. Addresses suck for average users.
225 2015-01-19 16:36:33 <Luke-Jr> ThomasV: yeah, it'd be a good thing to add
226 2015-01-19 16:36:37 <hearn> so you go through the flow with your mobile browser. then you can sign payment requests with your email addy.
227 2015-01-19 16:36:41 <Luke-Jr> ThomasV: although email is kinda hard to secure
228 2015-01-19 16:36:43 <hearn> the work was on a branch
229 2015-01-19 16:36:51 <hearn> i do not believe it shipped in the main product, though i forget why
230 2015-01-19 16:37:48 <ThomasV> ok, I will talk to him
231 2015-01-19 16:38:02 <hearn> signing with email cert's is not that hard to add on most operating systems
232 2015-01-19 16:38:20 <hearn> having a pure native UI flow for getting one is a bit harder. native browsers like chrome/safari/internet explorer have it all built in and do a pretty nice experience
233 2015-01-19 16:38:27 <hearn> so it's also not hugely motivating to duplicate all that ...
234 2015-01-19 16:38:37 <ThomasV> hehe
235 2015-01-19 16:38:51 <Luke-Jr> hearn: is this "email cert" thing more widely used than PGP keys or something? I've never seen them in the wild
236 2015-01-19 16:39:44 <Luke-Jr> seems like it'd make more sense to sign with PGP keys, since that's already in used by like 20-30% of technically informed people
237 2015-01-19 16:39:47 <hearn> much more widely used, but mostly within the context of managed networks
238 2015-01-19 16:40:00 <Luke-Jr> in use*
239 2015-01-19 16:40:02 <hearn> pgp is more popular for ad-hoc use by individuals, though for no real good reason - i've found s/mime a LOT easier to use
240 2015-01-19 16:40:12 <hearn> partly because it's already integrated into things and can deal with attachments and html mail automatically
241 2015-01-19 16:40:17 <Luke-Jr> S/MIME needs a paid cert, right?
242 2015-01-19 16:40:26 <hearn> nah there are CA's that give them away for free
243 2015-01-19 16:40:26 <Luke-Jr> and no WoT?
244 2015-01-19 16:40:40 <hearn> the link i just posted, for example, says "free-email-certificate.php" in the url :p
245 2015-01-19 16:41:22 <Luke-Jr> ACTION wonders what integrates S/MIME and not PGP
246 2015-01-19 16:41:30 <Luke-Jr> ^ is that basically just Microsoft products?
247 2015-01-19 16:41:51 <wumpus> thunderbird+enigmail can do both at least
248 2015-01-19 16:41:56 <hearn> yeah no WoT. i think WoT is dying. no new crypto systems that i'm seeing developed rely on it. i post to messaging@moderncrypto.org which is a good place to see new messaging apps being developed and they all use either direct key exchange bitcoin style, or using github/twitter/etc as a CA, or some other more exotic mechanism
249 2015-01-19 16:42:24 <hearn> S/MIME is supported by microsoft's mail clients yes, thunderbird, apple mail, not sure about kmail/evolution/etc. but most mail clients developed in the 1990's or early 2000s do support it
250 2015-01-19 16:42:39 <hearn> like i said it's used a lot in corporate deployments because you can automatically issue everyone with a certificate
251 2015-01-19 16:42:43 <Luke-Jr> KMail does PGP just as well as S/MIME at least
252 2015-01-19 16:43:03 <wumpus> I've never used it though, as I already have a GPG key I just use that
253 2015-01-19 16:43:29 <hearn> there's a set of extensions you can install for Mail.app to make it do PGP but the usability is pretty awful
254 2015-01-19 16:43:49 <hearn> also a lot of people use PGP in inline mode, which beyond breaking formatting and stuff also has weird UI security issues
255 2015-01-19 16:43:59 <hearn> S/MIME doesn't let you accidentally screw up in such ways
256 2015-01-19 16:44:38 <hearn> also it's actually more decentralised than the WoT in some ways. you attach your public key and certificate to the email with S/MIME, so key servers don't get to view who is talking to who via key lookups
257 2015-01-19 16:44:42 <Luke-Jr> anyhow, it'd be nice if both were supported for payment reqs if possible
258 2015-01-19 16:44:50 <hearn> once you got your cert the CA's are not involved anymore (unless you do revocation checks)
259 2015-01-19 16:45:09 <Luke-Jr> hearn: more private, not more decentralised..
260 2015-01-19 16:45:27 <hearn> well PGP is pretty different. like, it's not clear what you would show in the UI as the identity, if presented with a PGP key
261 2015-01-19 16:45:31 <hearn> it can self assert any email address it likes
262 2015-01-19 16:45:52 <Luke-Jr> there's lots of good examples for that IMO
263 2015-01-19 16:46:05 <hearn> that address isn't meaningful unless you can find a WoT path to the destination. then your wallet ends up needing quite a bit of integration with PGP
264 2015-01-19 16:46:14 <gavinandresen> Speaking of free certs⦠has anybody looked at the EFFâs proposed protocol for getting certs? https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
265 2015-01-19 16:46:21 <hearn> this is ACME?
266 2015-01-19 16:46:36 <wumpus> well, the mail program should already do the GPG verification
267 2015-01-19 16:47:08 <gavinandresen> hearn: yes: https://github.com/letsencrypt/acme-spec
268 2015-01-19 16:47:14 <hearn> gavinandresen: i didn't review the protocol. i was kind of surprised at how convoluted their initial set of scripts and things were
269 2015-01-19 16:47:20 <hearn> in theory it's a very simple problem to solve
270 2015-01-19 16:47:43 <hearn> it sounds like ACME is only caring about domain name certificates though
271 2015-01-19 16:47:57 <gavinandresen> ooh! they have eleven contributors.....
272 2015-01-19 16:48:28 <hearn> an ACME-equivalent for email addresses should be trivial, just an HTTP POST of a CSR to some well known URL on the ca website .... then a GET with the magic url they emailed to you to check inbox access. what you get back is the certificate.
273 2015-01-19 16:48:40 <hearn> barely even needs a spec, really
274 2015-01-19 16:49:59 <hearn> Luke-Jr: i guess you could build a wallet that understands how to read PGP keys, navigate the WoT and render it in a meaningful way in the user interface if you wanted to
275 2015-01-19 16:50:24 <Luke-Jr> hearn: what wumpus said - let the user's email client handle that?
276 2015-01-19 16:50:45 <hearn> Luke-Jr: the thing with using S/MIME certs is that it's not many lines of code. most platforms already have libraries that know how to read them. and the UI rendering is binary - it's either a valid email address, or it's untrusted in which case you don't display it. but you don't have intermediate states.
277 2015-01-19 16:50:58 <hearn> ah ok well sometimes payment requests are being transmitted via bluetooth, nfc, web etc .... not via email
278 2015-01-19 16:51:05 <hearn> email as identity is divorced from email as transport
279 2015-01-19 16:51:08 <Luke-Jr> right, but the topic was email :p;
280 2015-01-19 16:51:56 <hearn> in that case i guess bip70 already works today. the wallet can just make an unsigned payment request and give it to you as a file to attach to a pgp signed/encrypted message
281 2015-01-19 16:52:04 <jgarzik> sure, but we don't want to lock ourselves into email-primary solutions
282 2015-01-19 16:52:10 <jgarzik> email-as-identity is a much larger scope
283 2015-01-19 16:52:24 <jgarzik> agree RE divorced
284 2015-01-19 16:52:40 <Luke-Jr> hearn: the sending is where the UI would be improved IMO - opening an attachment your email client says is good is one thing, but manually making the attachment can be harder
285 2015-01-19 16:53:06 <jgarzik> someone@somewhere is a familiar and sensible UI, even if that is not email-deliverable it works great for identity.
286 2015-01-19 16:53:28 <hearn> Luke-Jr: how do you mean manually making the attachment?
287 2015-01-19 16:53:48 <Luke-Jr> hearn: it's not user-friendly to have it save a file, then go to the email program, manually attach it, etc
288 2015-01-19 16:53:50 <hearn> i think on most OS's you can ask the platform to open a mailto: link and sometimes there are ways to ask for an attachment as part of that
289 2015-01-19 16:53:57 <hearn> on android you can use intents.
290 2015-01-19 16:54:05 <Luke-Jr> oh, ok. that could work
291 2015-01-19 16:54:07 <hearn> i think .....iirc it's a bit convoluted
292 2015-01-19 16:54:14 <Luke-Jr> I thought you meant the user had to do it all âº
293 2015-01-19 16:54:48 <hearn> well currently they would. a wallet that knows how to ask email clients to make an attachment is not implausible. but i think the way we'll want to go longer term is having a little p2p network of nodes that store and serve (via http) payment requests that were uploaded by wallets.
294 2015-01-19 16:54:56 <hearn> because that way you can get the Payment message back as well
295 2015-01-19 16:55:11 <hearn> with the message, the refund address, random nonce for ecdh payments etc.
296 2015-01-19 16:57:36 <ThomasV> email attachments are trivial to deploy
297 2015-01-19 16:57:43 <hearn> yes, for sure
298 2015-01-19 16:57:56 <ThomasV> and ca, be sent even to a non-bitcoiner
299 2015-01-19 16:58:01 <ThomasV> *can*
300 2015-01-19 16:58:58 <hearn> well they wouldn't be able to open it
301 2015-01-19 16:59:06 <hearn> seems the mailto: url scheme RFC doesn't specify any way to attach files
302 2015-01-19 16:59:19 <ThomasV> no, but they would have a reason to create a bitcoin wallet :)
303 2015-01-19 16:59:23 <hearn> some mail clients like evolution add custom extensions to support it, but others (e.g. gmail) don't
304 2015-01-19 16:59:36 <hearn> so i guess it's very dependent on your OS and mail client whether a wallet can open an email with a pre-attached file
305 2015-01-19 17:06:44 <hearn> anyway
306 2015-01-19 17:06:55 <hearn> at the moment the biggest problem with the payment protocol is not enough wallets support it
307 2015-01-19 17:06:59 <hearn> ACTION glares at multibit
308 2015-01-19 17:07:28 <hearn> there was a reddit thread a day or two back with someone who was implementing a bitcoin merchant complaining that bip70 solved lots of problems but some wallets didn't properly support it
309 2015-01-19 17:07:58 <hearn> once more wallets are showing the identities and TREZOR is using them too, there will be way more incentive to get set up for signing. until then, not so much
310 2015-01-19 17:08:07 <ThomasV> we will release Electrum soon
311 2015-01-19 17:08:18 <hearn> with bip70 support?
312 2015-01-19 17:08:22 <ThomasV> yes
313 2015-01-19 17:08:34 <hearn> yay!
314 2015-01-19 17:08:37 <hearn> ACTION rejoices
315 2015-01-19 17:08:53 <jgarzik> I wish there was a chain with PGP public keys and associated email addresses
316 2015-01-19 17:08:55 <ThomasV> although maybe not 'proper' support
317 2015-01-19 17:08:59 <Luke-Jr> Bitcoin Core doesn't support it yet :x
318 2015-01-19 17:09:04 <Luke-Jr> at least not for email
319 2015-01-19 17:09:11 <jgarzik> decentralized PGP keyservers & WoT registry
320 2015-01-19 17:09:13 <Luke-Jr> (I think?)
321 2015-01-19 17:09:18 <hearn> ThomasV: what is proper support in your books?
322 2015-01-19 17:09:25 <jgarzik> then we can go foo@bar -> payment in a secure loop.
323 2015-01-19 17:09:43 <hearn> Luke-Jr: not sure. i think it should do actually. i have an s/mime signed payment request somewhere, if i could dig it up i could try
324 2015-01-19 17:09:52 <hearn> if it doesn't, then it should be just a one or two line fix to make it compatible, iirc
325 2015-01-19 17:09:56 <ThomasV> hearn: we just tried to follow the bip..
326 2015-01-19 17:10:02 <Luke-Jr> hearn: hmm, I wonder how it'd get to it?
327 2015-01-19 17:10:20 <hearn> Luke-Jr: Core knows how to open .paymentrequest files, right?
328 2015-01-19 17:10:30 <hearn> you could just open an attachment in Core and it should work
329 2015-01-19 17:10:38 <Luke-Jr> I guess I've never tried, but I didn't notice code for it - possible I just missed that
330 2015-01-19 17:10:39 <ThomasV> hearn: bip70 support in Electrum was initially written by mr_burdell
331 2015-01-19 17:10:42 <hearn> ThomasV: that's better than some implementors :)
332 2015-01-19 17:10:51 <hearn> ThomasV: if you follow the bip, it should be ok i guess
333 2015-01-19 17:11:12 <hearn> Luke-Jr: it has support for file associations on some platforms at least. maybe not linux, uncertain.
334 2015-01-19 17:11:27 <jgarzik> _Receiving_ payments is not something people have put much thought or energy into yet. Need a good solution for payouts that protects privacy (no addr reuse) and can be provably linked to some sort of identity token/certificate/key
335 2015-01-19 17:12:03 <jgarzik> Today payouts are "send PGP-signed bitcoin address, I reuse that address to pay you"
336 2015-01-19 17:12:08 <hearn> jgarzik: bip70 server as i proposed above can solve those problems. with ecdh extension, no addr reuse either. BUT (and this is a huge but) ..... so far nobody figured out how to combine ECDH addresses and convenient backups
337 2015-01-19 17:12:33 <ThomasV> heh
338 2015-01-19 17:12:35 <Luke-Jr> hearn: with an offline recipient?
339 2015-01-19 17:13:10 <hearn> Luke-Jr: bip70 server can accept payments for requests it didn't serve. but if you're offline, not sure how you will pay anyway ...
340 2015-01-19 17:13:23 <hearn> i.e. you can combine email attachments with an always online payment dropbox thing
341 2015-01-19 17:14:12 <mr_burdell> I've had clients that want to reuse addresses because they get worried about new addresses being incorrect
342 2015-01-19 17:14:14 <hearn> the main reason to want a little server is, you can just fire up your wallet, and it downloads all your payment data so you don't even need the block chain at that point except to see confirmations
343 2015-01-19 17:14:20 <mr_burdell> they like to test by sending a small amount first
344 2015-01-19 17:14:26 <mr_burdell> then send a larger amount to the same address
345 2015-01-19 17:14:43 <hearn> if nodes build a txid->merkle branch index, then at this point we can junk bloom filtering entirely
346 2015-01-19 17:15:23 <hearn> bip70 payment request contains [a] CA cert giving an identity string assertion [b] base outputs that can be combined via ECDH with random nonces [c] key to encrypt the Payment response under, [d] http addr of an always-on dropbox service
347 2015-01-19 17:16:01 <hearn> wallet then uploads an encrypted Payment message containing the tx data, broadcasts the tx data to the p2p network and is now done
348 2015-01-19 17:16:23 <hearn> receiving wallet starts, downloads all encrypted Payment messages in one go from the dropbox server. then it asks the p2p network to show the merkle branches
349 2015-01-19 17:16:34 <hearn> all it needs are the headers
350 2015-01-19 17:16:42 <Luke-Jr> mr_burdell: sign/verify message is more reliable for testing, than sending a payment
351 2015-01-19 17:16:59 <hearn> this scales better than Bloom filtering for the payments where it can be required, and should be much faster.
352 2015-01-19 17:16:59 <Luke-Jr> just because your wallet shows the payment as received does NOT mean it successfully worked cryptographically
353 2015-01-19 17:17:20 <Luke-Jr> mr_burdell: note this testing is often builtin to wallets when they display a new address
354 2015-01-19 17:17:23 <mr_burdell> Luke-Jr: I agree, although that can be inconvenient with offline wallets
355 2015-01-19 17:17:38 <hearn> effectively tx data moves around entirely outside the p2p network except for getting to miners. all the p2p network does is put txns into blocks, and give clients cryptographic proofs that this happened.
356 2015-01-19 17:17:55 <Luke-Jr> mr_burdell: you can do the testing only on the system with the private key - so it's no more work for an offline wallet
357 2015-01-19 17:18:08 <mr_burdell> I'm just reporting what the clients like to do... they've learned that this is how to verify an address is correct
358 2015-01-19 17:18:22 <Luke-Jr> mr_burdell: they should be educated ;)
359 2015-01-19 17:18:52 <ThomasV> you don't educate users. you just provie them with the right tool
360 2015-01-19 17:19:34 <Luke-Jr> ThomasV: in this case, you educate. the right tool is already builtin
361 2015-01-19 17:19:37 <mr_burdell> when you start dealing with millions of dollars, people get worried about new technology... it's hard to convince them of a new process when the old one works fine for them
362 2015-01-19 17:20:31 <hearn> yes, this was an unexpected problem with the HD rollout too
363 2015-01-19 17:20:37 <hearn> people got alarmed and upset that their address kept changing
364 2015-01-19 17:20:37 <Luke-Jr> mr_burdell: the "old process" was never what you described.
365 2015-01-19 17:20:56 <mr_burdell> their old process is
366 2015-01-19 17:21:02 <hearn> i don't think we anticipated that during the design phase. the cultural knowledge about address reuse being bad had never reached a lot of these users
367 2015-01-19 17:21:22 <sipa> wellbthat's the reason for getting rid of it in the first place
368 2015-01-19 17:21:39 <ThomasV> +1
369 2015-01-19 17:21:50 <sipa> if people understood why address reuse was bad, they wouldn't ask for it
370 2015-01-19 17:22:17 <mr_burdell> for what it's worth, I'm all for educating the users... but I'm not in a position to do that directly.
371 2015-01-19 17:22:23 <hearn> partly it was because andreas doesn't really believe in in-app tutorials :)
372 2015-01-19 17:22:32 <hearn> the android wallet could have explained the change, but didn't.
373 2015-01-19 17:22:34 <sipa> it needs some coordinated effort i guess
374 2015-01-19 17:22:40 <hearn> just one day there was an update and the address was different
375 2015-01-19 17:22:44 <sipa> multiple sites/apps changing behaviour
376 2015-01-19 17:23:22 <hearn> mr_burdell: wallet apps can educate users with their UI, i think
377 2015-01-19 17:23:29 <hearn> mr_burdell: so if you work on a wallet, then you can educate your users that way
378 2015-01-19 17:23:36 <Luke-Jr> mr_burdell: so if "it's hard to convince them of a new process when the old one works fine for them", we should make the old one stop working fine? :P
379 2015-01-19 17:23:48 <mr_burdell> I'm talking about from a merchant perspective
380 2015-01-19 17:23:51 <jgarzik> IMO people don't _ask_ for address reuse. It is simply the path of least resistance given our current infrastructure. Miner pools do it, for example. There is no good alternative that also works for paying to, e.g. cold storage or a user that is simply offline.
381 2015-01-19 17:24:10 <jgarzik> Given current limitations, people do it because it isn't workable any other way, for payouts. And that sucks.
382 2015-01-19 17:24:57 <jgarzik> Seems like you could at a minimum provide an agreed upon extended public key & derivation protocol
383 2015-01-19 17:25:19 <sipa> jgarzik: agree, but the notion of "address" (and its reuse) is the result of how the process got adopted
384 2015-01-19 17:25:23 <hearn> once more wallets support BIP 70, we can start to investigate better integration and simple payreq hosting servers, etc. if all software that currently accepts an address accepted a bitcoin URI, with bip72 support as well, then it'd be a lot easier for mining pools etc to do it right
385 2015-01-19 17:25:29 <jgarzik> sipa, agree :(
386 2015-01-19 17:25:30 <sipa> jgarzik: i don't see how ext pubkey derivation helps
387 2015-01-19 17:25:44 <sipa> publishing your extpub key is just as bad as reusing an address
388 2015-01-19 17:25:47 <sipa> for privacy
389 2015-01-19 17:25:55 <hearn> they just replace one string with another and it's all transparent. behind the scenes the wallet app fetches the PaymentRequest, which can either be dynamically generated by the payreq server, or (better) using ECDH
390 2015-01-19 17:25:57 <jgarzik> sipa, it is kept private between two parties presumably
391 2015-01-19 17:26:02 <Luke-Jr> sipa: you can give an extpub key to each person
392 2015-01-19 17:26:05 <jgarzik> sipa, this is separate from identity, conversation-wise
393 2015-01-19 17:26:26 <Luke-Jr> s/extpub key/reusable payment request/ for multisig
394 2015-01-19 17:26:32 <jgarzik> identity would require some additional layer that provides "payment stream" negotiation
395 2015-01-19 17:26:42 <sipa> meh
396 2015-01-19 17:26:50 <sipa> payment protocol is so much simpler
397 2015-01-19 17:27:08 <jgarzik> fundamentally you need to represent an _ongoing payment relationship_
398 2015-01-19 17:27:12 <jgarzik> payouts, subscriptions
399 2015-01-19 17:27:30 <jgarzik> BIP70 is designed around a one-time interaction
400 2015-01-19 17:27:45 <sipa> using extpub meams client & server state
401 2015-01-19 17:27:46 <kanzure> will watchonly additions work while doing an initial sync?
402 2015-01-19 17:27:56 <sipa> kanzure: should
403 2015-01-19 17:27:57 <hearn> BIP70 can be extended to support the ECDH trick. it's conceptually like giving an xpubkey to someone, but where the counter can be any 256-bit number instead of a 32 bit integer
404 2015-01-19 17:28:01 <kanzure> sipa: kthx
405 2015-01-19 17:28:02 <hearn> so it's unenumerable
406 2015-01-19 17:28:07 <Luke-Jr> kanzure: it's just an encrypted wallet without the priv keys basically
407 2015-01-19 17:28:18 <hearn> and therefore, gives reusable payment requests with good privacy
408 2015-01-19 17:28:31 <jgarzik> yep
409 2015-01-19 17:28:32 <hearn> the big downside is if you lose the nonces, you lose the money. therefore we end up back at "back up after every received payment" which is unworkable
410 2015-01-19 17:28:38 <jgarzik> yep :(
411 2015-01-19 17:29:07 <Luke-Jr> well, that's why stealth addresses use OP_RETURN
412 2015-01-19 17:29:14 <kanzure> Luke-Jr: my concern is something like "no, you must always perform a reindex after the initial sync because watchonlys can maybe not be added over rpc whlie bitcoind is busy doing initial sync", but sipa says it's okay so i'm good :)
413 2015-01-19 17:29:16 <jgarzik> no, back up sets of payment relationships
414 2015-01-19 17:29:21 <ThomasV> it's better to lose your privacy than your bitcoins
415 2015-01-19 17:29:27 <hearn> the simpler approach, for now, is to raise the trust level in the payreq server slightly, so it's allowed to sign on your behalf. the server then iterates the BIP32 chain and puts the address into a served payment request output
416 2015-01-19 17:29:40 <hearn> Luke-Jr: yes that just makes the block chain your personal backup server.
417 2015-01-19 17:29:40 <sipa> hearn: in many settings, losing information about who paid is worse than losing the money
418 2015-01-19 17:30:18 <hearn> yeah
419 2015-01-19 17:30:22 <hearn> they're both bad :)
420 2015-01-19 17:30:45 <kanzure> Luke-Jr: watchonlys are persisted to the wallet?
421 2015-01-19 17:30:48 <hearn> wallets need a robust (file based) backup system. currently the best you can get is "write down the wallet words"
422 2015-01-19 17:31:00 <jgarzik> have a wallet-private derivation-scheme generator
423 2015-01-19 17:31:00 <Luke-Jr> kanzure: watchonly *is* the wallet..
424 2015-01-19 17:31:08 <jgarzik> then you know the nonces that wallet will generate
425 2015-01-19 17:31:18 <jgarzik> a master-master seed
426 2015-01-19 17:31:18 <Luke-Jr> kanzure: it only works sanely for entire wallets, not individual addresses
427 2015-01-19 17:31:21 <kanzure> Luke-Jr: huh, that is cool. i thought it was just some in-memory-only stuff. lost when doing reboots etc.
428 2015-01-19 17:31:28 <kanzure> Luke-Jr: oh what do you mean?
429 2015-01-19 17:31:31 <jgarzik> one backup
430 2015-01-19 17:31:43 <hearn> jgarzik: nonces are generated by the sender, not the receiver
431 2015-01-19 17:31:44 <Luke-Jr> kanzure: you need to importaddress all the addresses in an entire wallet you want to watch
432 2015-01-19 17:31:51 <hearn> so that trick doesn't work unfortunately
433 2015-01-19 17:32:02 <kanzure> Luke-Jr: right. do i need to importaddress again after rebooting bitcoind for instance?
434 2015-01-19 17:32:10 <Luke-Jr> no
435 2015-01-19 17:32:12 <kanzure> awesome
436 2015-01-19 17:32:15 <jgarzik> hearn, sure it does
437 2015-01-19 17:32:22 <jgarzik> hearn, if the receiver tells the sender how to generate
438 2015-01-19 17:32:43 <sipa> that's why you send it in payment message
439 2015-01-19 17:32:47 <sipa> ideally encrypted
440 2015-01-19 17:32:51 <jgarzik> nod
441 2015-01-19 17:32:56 <kanzure> Luke-Jr: thank you
442 2015-01-19 17:33:00 <hearn> the difference between ECDH with big random nonce, and BIP32 with an index, is that the latter is enumerable
443 2015-01-19 17:33:42 <hearn> imagine a server that vends PaymentRequests on the behalf of a person. it can either present an xpubkey and say "please use index i", or it can say "generate the random number yourself and send it to me"
444 2015-01-19 17:33:47 <hearn> if it does the first, you run into two problems
445 2015-01-19 17:33:48 <kanzure> your nonce might be enumerable through some other system, and this has caused me great distress (regarding which one i should prefer)
446 2015-01-19 17:34:09 <hearn> one is an attacker can just repeatedly fetch payment requests over and over again to push "i" really high and then the users wallet has to scan giant keyspaces to try and find transactions
447 2015-01-19 17:34:11 <jgarzik> hearn, yes we understand. take the first case and make it enumerable only if you know the generator secret.
448 2015-01-19 17:34:36 <hearn> if you only iterate i when a payment is received, then you lose privacy again. anyone can fetch a payment request to find out what the next address a real payer will use
449 2015-01-19 17:34:44 <kanzure> presumably you would share that generator under certain circumstances
450 2015-01-19 17:34:48 <jgarzik> establish a shared secret protocol for enumeration IOW
451 2015-01-19 17:34:51 <hearn> ecdh solves those problems but the sender *must* pick the value independently.
452 2015-01-19 17:35:12 <hearn> if it follows instructions from the receiver, you get the second problem again - anyone can request the instructions, not fulfil them, and just wait to spot the next payment
453 2015-01-19 17:35:51 <hearn> that implies the random values the senders pick are purely random to the receiver, and thus, the receiver must store them. or..... spend the money back to themselves using a private hd chain
454 2015-01-19 17:35:57 <sipa> doesn't actually need ecdh, the pay-to-contract scheme is enough
455 2015-01-19 17:36:05 <hearn> yes
456 2015-01-19 17:36:18 <hearn> i should call it point addition or something. ecdh is so easy to type though :)
457 2015-01-19 17:36:24 <sipa> right
458 2015-01-19 17:36:29 <hearn> ecpa :)
459 2015-01-19 17:36:49 <Luke-Jr> just call it 'sipa'. only slightly confusing.
460 2015-01-19 17:36:59 <hearn> super innovative point addition
461 2015-01-19 17:37:04 <hearn> know we finally know what sipa means!
462 2015-01-19 17:37:13 <hearn> suddenly libsecp256k1 makes sense
463 2015-01-19 17:37:19 <akstunt600> +1
464 2015-01-19 17:37:32 <sipa> :D
465 2015-01-19 17:37:41 <akstunt600> ^.^
466 2015-01-19 17:37:41 <jgarzik> lol
467 2015-01-19 17:40:33 <Luke-Jr> ACTION debates whether to try to IBD on his USB Armory :p
468 2015-01-19 17:46:43 <op_mul> just to update my comment about a slow 0.10 sync before; the source was of course hardware failure. all brand new kit and I never thought I'd actually get a DOA hard drive.
469 2015-01-19 17:48:02 <Luke-Jr> ACTION wonders if it's reasonably possible to ship static ARM bins
470 2015-01-19 17:48:22 <op_mul> I think at this point we just need to assume memtest86 is inferior to bitcoind.
471 2015-01-19 17:49:42 <wumpus> obviously; memtest86 only tests memory, bitcoind tests cpu, i/o and memory :)
472 2015-01-19 17:50:29 <hearn> if anyone is looking for work, instrumenting bloom filtering performance would be super useful right now
473 2015-01-19 17:51:08 <hearn> seems our recent organic growth might be causing slow nodes and random hotspotting. bloom filtering perf on the network seems wildly variable, more than can be explained by hardware differences.
474 2015-01-19 17:51:32 <op_mul> how are you benchmarking it?
475 2015-01-19 17:51:40 <hearn> bitcoinj logs blocks/second during chain download
476 2015-01-19 17:51:42 <op_mul> and have you found my nodes yet? :3
477 2015-01-19 17:51:45 <hearn> so this is based on observations from the client side
478 2015-01-19 17:52:14 <wumpus> difference in i/o speed, likely
479 2015-01-19 17:52:36 <hearn> the difference can be 10x
480 2015-01-19 17:52:47 <hearn> so i think it's more likely to be whether other clients are sucking down the chain simultaneously
481 2015-01-19 17:52:53 <op_mul> there's people running nodes on rasberry pi, so that's not surprising.
482 2015-01-19 17:53:01 <hearn> ugh, really?
483 2015-01-19 17:53:08 <Apocalyptic> yes
484 2015-01-19 17:53:25 <hearn> i think we need to do some experiments to see how performance changes as more clients download the chain simultaneously
485 2015-01-19 17:53:33 <wumpus> 'bloom filtering' is mostly reading blocks from disk, then throwing away almost all the data, I doubt the filter itself is a substantial part of the time
486 2015-01-19 17:53:39 <hearn> i.e. on an unloaded machine does going from 1->2 spv clients halve performance? or worse?
487 2015-01-19 17:53:52 <hearn> yeah i doubt it too but i have no data.
488 2015-01-19 17:53:59 <op_mul> it's probably possible to do that pretty easily.
489 2015-01-19 17:54:02 <wumpus> harddisks cope very badly with multiple reading streams
490 2015-01-19 17:54:08 <wumpus> so that sounds likely
491 2015-01-19 17:54:14 <hearn> yes
492 2015-01-19 17:54:39 <hearn> with data we can optimise
493 2015-01-19 17:54:39 <op_mul> hearn: easiest optimisation I can see is just to have a spvlie=0 option in bitcoin.conf. returns blank filtered blocks to save CPU time.
494 2015-01-19 17:54:52 <wumpus> if only the bloom filter didn't have so many randomized components, it'd have been possible to pre-compute and cache more, instead of requiring a linear scan over blocks every time
495 2015-01-19 17:55:13 <hearn> well it'd require an index of (recent parts of) the chain
496 2015-01-19 17:55:19 <hearn> and i think sipa has rude things to say about that :)
497 2015-01-19 17:55:44 <wumpus> commit-to-bloom-filter? :P
498 2015-01-19 17:55:46 <hearn> if slowness is seek time dominated, i strongly suspect we can simply overlap reading and transmission
499 2015-01-19 17:56:39 <hearn> for example doing loading+filtering in multiple threads would let the kernel re-organise and optimise seeks. additionally whilst one thread is seeking, another can be making progress on the cpu.
500 2015-01-19 17:56:48 <hearn> currently the whole thing is serial so whilst it's seeking, it's just sitting there doing nothing.
501 2015-01-19 17:56:55 <op_mul> I don't agree that my nodes should be wasting their CPU time with SPV nodes anyway.
502 2015-01-19 17:56:59 <hearn> however, with no data, it's pretty pointless to speculate
503 2015-01-19 17:57:13 <hearn> op_mul: -listen=0 is your friend.
504 2015-01-19 17:57:18 <wumpus> doesn't sound like something to optimize more for
505 2015-01-19 17:58:07 <wumpus> right now it's like a dos attack on i/o bandwidth, adding threads and such makes it even more effective
506 2015-01-19 17:58:52 <appleapple_jg> strongly I/O storage dependent. If you have no seek time, life is pretty good. If you have seek time, life is horrible under any sort of load.
507 2015-01-19 17:58:58 <hearn> *shrug* it's easy to reduce io bandwidth usage by having less privacy and more disk space usage, just have a traditional script->tx index
508 2015-01-19 17:59:10 <hearn> if the io bandwidth is there waiting to be used though, might as well use it to make better privacy possible (even if at the moment we don't really exploit that)
509 2015-01-19 17:59:27 <hearn> bloom filtering is mostly streaming bandwidth anyway, which is cheap even with hard disks.
510 2015-01-19 17:59:28 <appleapple_jg> I would be surprised if you max out bandwidth on an SSD
511 2015-01-19 17:59:33 <hearn> assuming blocks are laid out semi-sequentially on disk
512 2015-01-19 17:59:36 <op_mul> hearn: I want to listen but I don't want to waste IO and CPU time on SPV clients. I think that's quite a valid state of mind given that SPV nodes take up a socket and give nothing back.
513 2015-01-19 17:59:37 <appleapple_jg> network bandwidth will go first
514 2015-01-19 18:00:08 <hearn> op_mul: erm, spv clients represent users. you know, the economy that gives your coins value. but ok then, just unset NODE_NETWORK.
515 2015-01-19 18:00:09 <wumpus> op_mul: I suppose you could kick anyone that sets a bloom filter
516 2015-01-19 18:00:19 <op_mul> appleapple_jg: enough SPV clients and you'll be thrashing your disk.
517 2015-01-19 18:00:57 <wumpus> op_mul: or easier: disconnect clients that don't report NODE_NETWORK
518 2015-01-19 18:01:07 <op_mul> wumpus: serving false negative blocks is funnier though.
519 2015-01-19 18:01:23 <wumpus> op_mul: nah, I don't like sabotage
520 2015-01-19 18:01:26 <appleapple_jg> op_mul, as I said, it's a question of storage hardware whether or not that's true.
521 2015-01-19 18:01:44 <appleapple_jg> op_mul, storage is trending towards non-rotational at PCI bus speeds
522 2015-01-19 18:02:03 <appleapple_jg> op_mul, you will max out WAN bandwidth long before disk bandwidth, regardless of seeking
523 2015-01-19 18:02:08 <wumpus> appleapple_jg: given enough clients, you'll max out the disk bandwidth. That's the idea of bloom filtering even, to max out disk bandwidth before network bandwidth.
524 2015-01-19 18:02:12 <hearn> sabotage is really dumb. you're just sabotaging yourself, in the end. users you could have traded with just won't accept bitcoin.
525 2015-01-19 18:02:24 <appleapple_jg> wumpus, not at RAM speeds
526 2015-01-19 18:02:35 <wumpus> appleapple_jg: even at RAM speeds. what if the filter is almost empty?
527 2015-01-19 18:02:48 <wumpus> appleapple_jg: you'd be scanning the chain without sending any data to the network
528 2015-01-19 18:03:30 <op_mul> appleapple_jg: I think it'll be a while until that's standard. until then I don't have any nodes running with an interface that's slower than the disk.
529 2015-01-19 18:03:37 <appleapple_jg> Yes I am quite aware. PCI Express 3 and 4 are quite fast.
530 2015-01-19 18:04:08 <wumpus> why would you store the blockchain in RAM though? RAM is still much more expensive than disk, or even ssd.
531 2015-01-19 18:04:10 <appleapple_jg> Scanning the chain with a null filter has always been an attack.
532 2015-01-19 18:04:47 <appleapple_jg> wumpus, <sigh> To rephrase the above, normal storage will operate at RAM bandwidth rates
533 2015-01-19 18:05:10 <wumpus> a node only stores the chain for serving it to other nodes, the only reason for storing block chain on super-fast storage would be altruism
534 2015-01-19 18:05:15 <op_mul> hearn: I don't think that's "sabotage", it's just people making dumb assumptions about what nodes in the network are supposed to do. if you're going to trust your peers not to mess with filters, you might as well just ditch the block chain too.
535 2015-01-19 18:05:31 <appleapple_jg> wumpus, thus you mentally model SSD & future storage with zero seek times and operating at local bus speeds and local bus bandwidth.
536 2015-01-19 18:05:52 <hearn> op_mul: bitcoin has _never_ worked with entirely malicious peers. it hasn't worked that way since day one, nor does it work that way now. most obviously, there are lots of DoS attacks possible.
537 2015-01-19 18:05:54 <appleapple_jg> That sort of storage has been in the field for a few years now, and it's trickling down out of enterprise.
538 2015-01-19 18:06:07 <wumpus> appleapple_jg: there will always been a compromise between size of the store and the speed and cost
539 2015-01-19 18:06:20 <hearn> op_mul: so you can rationalise it to yourself as "punishing dumbness" all you like, but back here in engineering reality, all you're doing is exploiting realities imperfections and hitting yourself in the face at the same time
540 2015-01-19 18:06:28 <hearn> not smart
541 2015-01-19 18:06:49 <kanzure> hearn: why would the existence of denial of service attacks change whether or not you should defend against malicious peers? please.
542 2015-01-19 18:07:00 <op_mul> hearn: bitcoin functions with the assumption that at least one of it's peers isn't malicious. if people are writing SPV clients that blindly trust a single peer, well.
543 2015-01-19 18:07:26 <akstunt600> there is always room for parallelization in storage its saffe to say it will continue to scale linearly as it has historically
544 2015-01-19 18:07:30 <hearn> eh? who said anything about "should"? sure, bitcoin clients "should" be able to detect nodes that lie to spv clients. in practice they don't. doing so is very complicated and requires chain forks and other things. so we compromise.
545 2015-01-19 18:07:59 <hearn> bitcoin should do lots of things it doesn't
546 2015-01-19 18:08:11 <hearn> obviously .... otherwise we could just go home and wrap up this channel right now. bitcoin would be done :)
547 2015-01-19 18:08:14 <kanzure> well it certainly shouldn't arbitrarily increase vulnerable attack surface area.
548 2015-01-19 18:12:42 <op_mul> hearn: I don't like basing systems of security and privacy on the assumption that nodes will behave and look the other way. in the scheme of things returning results for unfilled filters is fairly inert.
549 2015-01-19 18:14:01 <hearn> op_mul: when you write your wallet, you can write it to avoid that assumption. for people writing spv wallets, blocking lies like "this tx exists/has been confirmed when it hasn't" is a good start, and blocking the much more pointless and less profitable lie "this transaction hasn't confirmed when it has" can be a future upgrade.
550 2015-01-19 18:14:33 <hearn> bearing in mind that actually making consumer wallets is a lot of work. you have to prioritise ruthlessly.
551 2015-01-19 18:14:38 <kanzure> how is that pointless? that's an excellent lie.
552 2015-01-19 18:14:41 <wumpus> op_mul: but to avoid nodes lying about empty blocks, you'd have to ask multiple nodes for the same, and that'd put even more load on the network
553 2015-01-19 18:14:52 <kanzure> (if you can trick someone into spending another transaction unrelated to the original inputs, you win some more bitcoin)
554 2015-01-19 18:16:30 <akstunt600> Yeah but then that ends to shared whitelists very quickcly, yeah they already exist.. but i mean
555 2015-01-19 18:16:38 <akstunt600> with*
556 2015-01-19 18:16:40 <hearn> kanzure: the only rule you need to avoid that attack is "don't make the same payment twice if the first is slow to confirm" which is so obvious that in practice nobody seems to have any issues like that.
557 2015-01-19 18:17:39 <kanzure> ahhh so you do have a floor on obvious!
558 2015-01-19 18:17:49 <kanzure> (the other week you were arguing the opposite)
559 2015-01-19 18:17:57 <akstunt600> What about some quick and dirty weight system?
560 2015-01-19 18:18:04 <akstunt600> for bad TXs
561 2015-01-19 18:18:23 <akstunt600> oh nm
562 2015-01-19 18:18:48 <Luke-Jr> akstunt600: it doesn't - you only need ONE whitelisted peer; other peers being "bad" then no longer matter
563 2015-01-19 18:18:49 <hearn> i don't remember that, but bluntly i think you just try and parse whatever i type in the most annoying and adversarial way possible kanzure. i grow tired of this. go write your own wallet.
564 2015-01-19 18:19:11 <Luke-Jr> whitelisted/good
565 2015-01-19 18:19:12 <kanzure> of course i should intrepret all of you in the most adversarial way possible
566 2015-01-19 18:19:22 <shamoon> can i stuff arbitrary data into OP_RETURN?
567 2015-01-19 18:19:40 <Luke-Jr> shamoon: can you? yes; should you? not in most cases
568 2015-01-19 18:19:55 <Luke-Jr> shamoon: does it make sense to? usually not
569 2015-01-19 18:20:04 <shamoon> what about storing immutable information
570 2015-01-19 18:20:08 <shamoon> for things like smart contracts?
571 2015-01-19 18:20:14 <Luke-Jr> shamoon: just use pay-to-contract?
572 2015-01-19 18:20:29 <shamoon> what's pay-to-contract?
573 2015-01-19 18:20:59 <Luke-Jr> shamoon: https://github.com/Blockstream/contracthashtool
574 2015-01-19 18:21:09 <shamoon> thanks Luke-Jr!
575 2015-01-19 18:21:22 <shamoon> what, if any, valid reason is there to put stuff into OP_RETURN?
576 2015-01-19 18:22:00 <hearn> shamoon: the BIP for this extension has some discussion of that i think
577 2015-01-19 18:22:09 <kanzure> hearn: (for the record it was http://gnusha.org/bitcoin-wizards/2015-01-09.log around "draw the line")
578 2015-01-19 18:22:17 <hearn> shamoon: it's intended to let you commit to a value, probably a hash of some data stored elsewhere
579 2015-01-19 18:22:47 <shamoon> so if i have my own service and i want to store data, i can put the hash into OP_RETURN
580 2015-01-19 18:22:48 <Luke-Jr> hearn: pay-to-contract makes it unnecessary for that even
581 2015-01-19 18:23:00 <Luke-Jr> shamoon: the blockchain does not store data
582 2015-01-19 18:23:21 <Luke-Jr> it establishes consensus for the UTXO set
583 2015-01-19 18:24:37 <Luke-Jr> hearn: OP_RETURN has no BIP; it's not standard, just passes IsStandard
584 2015-01-19 18:24:45 <hearn> oh i thought there was a bip for it
585 2015-01-19 18:25:15 <shamoon> then Luke-Jr, what is the point of OP_RETURN?
586 2015-01-19 18:25:56 <Luke-Jr> shamoon: 1) in case it's needed (no known use case AFAIK - maybe Counterparty?); 2) to give spammers a less-harmful way to spam
587 2015-01-19 18:26:33 <shamoon> how can i construct a transaction with a specific OP_RETURN?
588 2015-01-19 18:26:47 <Luke-Jr> shamoon: for what purpose?
589 2015-01-19 18:27:03 <Luke-Jr> https://en.bitcoin.it/wiki/Protocol_specification#tx explains the tx format
590 2015-01-19 18:27:05 <shamoon> along the lines of what hearn has mentioned
591 2015-01-19 18:27:37 <Luke-Jr> shamoon: to commit to data, it's better to use pay-to-contract; more private (looks like a normal tx to everyone else) and smaller
592 2015-01-19 18:27:47 <shamoon> this is using blockstream
593 2015-01-19 18:27:50 <shamoon> right?
594 2015-01-19 18:27:54 <op_mul> hearn: I've not tried making a consumer wallet, no, so I can't pass judgement on that.
595 2015-01-19 18:28:06 <op_mul> blockstream is a company, not a product.
596 2015-01-19 18:28:27 <hearn> you work for blockstream? doing what?
597 2015-01-19 18:29:17 <op_mul> er me? no.
598 2015-01-19 18:29:39 <Luke-Jr> no, it's just on Blockstream's github
599 2015-01-19 18:31:53 <Luke-Jr> <Luke-Jr> no, it's just on Blockstream's github
600 2015-01-19 18:31:54 <Luke-Jr> <Luke-Jr> (also, Blockstream is a company, not a "thing to use")
601 2015-01-19 18:31:58 <Luke-Jr> ACTION kicks freenode
602 2015-01-19 18:33:06 <hearn> oh, ok
603 2015-01-19 18:33:07 <hearn> i was confused
604 2015-01-19 18:33:21 <hearn> sorry, i didn't spot shamoon's comment
605 2015-01-19 18:46:56 <petertodd> shamoon: re pay-to-contract, it creates significant coin loss risks: https://bitcointalk.org/index.php?topic=915828.msg10208312#msg10208312
606 2015-01-19 18:47:07 <shamoon> so - that's not good
607 2015-01-19 18:47:52 <petertodd> shamoon: yup, good way to lose money, either on the sender or receiver end
608 2015-01-19 18:48:04 <shamoon> so you're in FAVOR of OP_RETURN, petertodd?
609 2015-01-19 18:48:52 <petertodd> shamoon: well, it's a risk-vs-cost tradeoff of course in this case - sure you can save a small % of your tx fees, but screwing up even once will wipe out thousands of transactions worth of fees in many cases, heck, tens of thousands
610 2015-01-19 18:49:09 <Luke-Jr> shamoon: petertodd's "coin loss risks" aren't actually significant - and they don't exist if you keep a copy of the contract
611 2015-01-19 18:49:12 <petertodd> shamoon: in most cases rational businesses will use protocols without that risk
612 2015-01-19 18:49:40 <Luke-Jr> petertodd: don't FUD
613 2015-01-19 18:50:31 <Luke-Jr> shamoon: look at petertodd's "risks", and use OP_RETURN if they're a problem for you - but most likely they aren't.
614 2015-01-19 18:50:55 <Luke-Jr> shamoon: it basically comes down to "you need to make backups" which is always true anyway
615 2015-01-19 18:51:07 <Luke-Jr> almost always* if you prefer
616 2015-01-19 18:51:08 <shamoon> i'll have to read more about these
617 2015-01-19 18:51:15 <petertodd> shamoon: yes, if you "keep a copy of the contract" you're fine, if the contract is created on demand in the protocol you need to create an immediate backup or you're fucked if anything goes wrong
618 2015-01-19 18:51:53 <petertodd> shamoon: so basically in many cases you'll have to have multiple servers running that auto-sync each other on demand; for the consumer side of things it's a really ugly problem
619 2015-01-19 18:52:02 <Luke-Jr> petertodd: s/immediate/sometime before the transaction is sent/
620 2015-01-19 18:52:13 <petertodd> shamoon: and be warned, the opposition to OP-RETURN is wonderfully and hilariously dogmatic :)
621 2015-01-19 18:52:32 <Luke-Jr> petertodd: and if you don't backup the contract, you also don't backup the very relevant metadata you need to know what it was for
622 2015-01-19 18:52:54 <Luke-Jr> petertodd: if it was dogmatic, IsStandard wouldn't even accept OP_RETURN
623 2015-01-19 18:53:55 <petertodd> Luke-Jr: look, I've got better things to do than argue this... obviously for many, many, businesses losing the contract isn't a disaster - human trust is plenty good enough to recover and figure out what to do with the money. Losing the money OTOH isn't something that can be fixed - it's a direct loss.
624 2015-01-19 18:55:07 <Luke-Jr> petertodd: more importantly: did you look into whether CLTV affects incentives re UTXO usage?
625 2015-01-19 18:55:35 <petertodd> Luke-Jr: that is so far down the list of important things...
626 2015-01-19 18:56:18 <Luke-Jr> perhaps, "more" is a relative term ;)
627 2015-01-19 19:18:35 <Luke-Jr> hmm, actually, should 5680 have been for cfields's trivial branch?
628 2015-01-19 19:26:34 <jonasschnelli> for anyone who's interested: started (this night) UTC 00:00 nightly signed gitian builds (https://builds.jonasschnelli.ch/nightlybuilds/)
629 2015-01-19 19:27:42 <jonasschnelli> different per pull-request builds are also coming. There, the question is more, how to trigger a pull request gitian build (ideas are welcome).
630 2015-01-19 19:28:45 <Luke-Jr> jonasschnelli: GitHub will send an email if you watch the project
631 2015-01-19 19:28:50 <Luke-Jr> although not for re-pushes :/
632 2015-01-19 19:28:59 <Luke-Jr> jonasschnelli: maybe just nightly do a git fetch for all PRs?
633 2015-01-19 19:29:14 <jonasschnelli> Luke-Jr, hmm.. not ideal. because...
634 2015-01-19 19:29:29 <jonasschnelli> Luke-Jr, pull requests could include ugly stuff which i don't like to build
635 2015-01-19 19:29:42 <Luke-Jr> indeed, that's another matter though :p
636 2015-01-19 19:30:23 <jonasschnelli> Luke-Jr, i started a znc module which could allow irc users to trigger a build... could be like "/msg bitcoinbuilder #5600"
637 2015-01-19 19:30:40 <jonasschnelli> there i could check the senders nick at least
638 2015-01-19 19:30:48 <Luke-Jr> interesting idea
639 2015-01-19 19:32:44 <wumpus> jonasschnelli: nice
640 2015-01-19 19:32:49 <ruukasu> is relayfee the tx fee? and if so, what is paytxfee?
641 2015-01-19 19:37:25 <gavinandresen> ruukasu: relayfee is the minimum fee-per-kb for your node to consider a transaction âfee-payingâ versus âfreeâ. It does not affect how much fee you pay. paytxfee doesâ set it to say âI want to always pay this much fee-per-kilobyte for my transactionsâ
642 2015-01-19 19:37:30 <jgarzik> "ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema."
643 2015-01-19 19:37:31 <jgarzik> sigh
644 2015-01-19 19:37:38 <jgarzik> Why can't XML just die in a fire?
645 2015-01-19 19:39:33 <op_mul> jgarzik: so many code execution bugs in XML libraries. run away run away.
646 2015-01-19 19:39:34 <ruukasu> gavinandresen: my paytxfee is 0.00000000 yet I always pay a 0.00001 fee when I sendtoaddress
647 2015-01-19 19:40:15 <gavinandresen> ruukasu: zero paytxfee means âlet the code decide a reasonable amount to pay"
648 2015-01-19 19:41:48 <ruukasu> ah. is there any rpc request I can do to get what that will be?
649 2015-01-19 19:42:02 <Luke-Jr> ACTION ponders writing up a FAQ-read-before-posting for the dev ML
650 2015-01-19 19:42:22 <ruukasu> or uh
651 2015-01-19 19:42:41 <Luke-Jr> ruukasu: (not talking about you there)
652 2015-01-19 19:42:43 <jonasschnelli> ruukasu: no, but there is a pull request for a new command "fundrawtransaction"
653 2015-01-19 19:44:09 <jgarzik> Luke-Jr, I'm all for FAQs
654 2015-01-19 19:45:04 <ruukasu> so is there no way to find out the tx fee before sending other than to do everything manually, set the tx fee myself, and probably screw something up majorly?
655 2015-01-19 19:46:33 <op_mul> ruukasu: in any case you usually don't want to be making zero fee transactions.
656 2015-01-19 19:47:03 <ruukasu> op_mul: not planning on it, I just want to find out what the fee is before sending
657 2015-01-19 19:48:22 <op_mul> as far as I know there's no interface for it, but one could make a half send to address transaction which is unsigned, so you can know the fee and then pass it to signrawtransaction.
658 2015-01-19 19:48:45 <op_mul> so like sendtoaddress, but spits out an unsigned transaction.
659 2015-01-19 19:48:59 <op_mul> ACTION shrugs
660 2015-01-19 19:50:03 <op_mul> or a signed one that you can send (or not) depending on if you like the fee.
661 2015-01-19 19:51:19 <ruukasu> is it generally safe to assume that a "normal" transaction with one or a few inputs, a receiver, and a change address, would pay a fee equal to relayfee?
662 2015-01-19 19:52:16 <op_mul> depends a bit on how dusty your wallet is, how old your outputs are, how the knapsack solver is feeling today.
663 2015-01-19 19:53:44 <ruukasu> I know it's generally considered a horrible idea to create transactions yourself, but since sendtoaddress seems pretty useless, is there a guide to creating transactions which, if followed exactly, would be safe?
664 2015-01-19 19:54:17 <op_mul> ACTION twitches
665 2015-01-19 19:54:53 <op_mul> probably not.
666 2015-01-19 19:59:22 <ruukasu> ;-;
667 2015-01-19 19:59:33 <jtimon> https://github.com/bitcoin/bitcoin/pull/5681
668 2015-01-19 19:59:51 <Luke-Jr> ruukasu: uh, sendtoaddress/sendmany aren't useless
669 2015-01-19 20:00:01 <Luke-Jr> you shouldn't need to create your own transactions
670 2015-01-19 20:00:33 <ruukasu> Luke-Jr: how could I predict the fee a tx will pay without creating a transaction manually?
671 2015-01-19 20:00:44 <Luke-Jr> ruukasu: you can't. and probably don't need to.
672 2015-01-19 20:01:06 <ruukasu> sendtoaddress is nice if you've got 5btc and want to send someone 0.1 and don't care if the fee ends up being 4.9
673 2015-01-19 20:01:10 <Luke-Jr> see topic "tell us what you're trying to do, not how you're trying to do it"
674 2015-01-19 20:01:29 <Luke-Jr> bitcoind will fail before it will use a totally unreasonable fee
675 2015-01-19 20:02:53 <ruukasu> I mean, that was an exageration. but if your balance is 1.00001 and you want to send someone 1, and you blindly assume the fee will end up being 0.00001, but it ends up being 0.00002
676 2015-01-19 20:03:04 <ruukasu> it seems like there should be a way to know what you're paying before you pay it
677 2015-01-19 20:03:28 <ruukasu> (I'm making a python wallet which interfaces with bitcoind)
678 2015-01-19 20:04:01 <Luke-Jr> ruukasu: I have an old PR that lets you set an upper limit at least
679 2015-01-19 20:04:18 <ruukasu> pr?
680 2015-01-19 20:04:23 <ruukasu> ah
681 2015-01-19 20:04:25 <Luke-Jr> I think last time this came up, gavinandresen mentioned an alternative/newer way to do the same - but I don't recall what it was
682 2015-01-19 20:06:26 <gavinandresen> ruukasu: does your python wallet store/manage the private keys itself? or is it just an interface to the bitcoind wallet/keys ?
683 2015-01-19 20:06:57 <ruukasu> gavinandresen: just an interface to bitcoind
684 2015-01-19 20:08:09 <gavinandresen> ruukasu: Mmm. Then no, no way to tell in advance how much fee will be paid, unless you use the raw transactions API to get list of unspent transaction outputs, build the transaction yourself, see how bit it is without signatures, add enough extra bytes for signatures....
685 2015-01-19 20:08:26 <gavinandresen> ⦠use the 0.10 estimatefee RPC call to estimate fees for that number of bytes....
686 2015-01-19 20:09:21 <gavinandresen> But if youâre doing all that work, youâre probably better off taking over management of the private keys yourself and not use the bitcoind wallet at all
687 2015-01-19 20:11:10 <ruukasu> the goal is for it to interface with bitcoind, since bitcoin-qt seemingly can't
688 2015-01-19 20:19:26 <michagogo> ruukasu: erm