1 2015-02-13 00:01:28 <leakypat> Ahh
2 2015-02-13 00:01:35 <leakypat> The penny just dropped
3 2015-02-13 00:01:47 <leakypat> 8:51 AM <petertodd> phantomcircuit: if I doublespend my payment to you, you can doublespend my doublespend with an even higher fee - say everything to fees - to ensure I still end up paying for my coffee
4 2015-02-13 00:02:26 <ajweiss> petertodd: do these replace-by-fee patches properly handle free transactions?
5 2015-02-13 00:03:02 <petertodd> leakypat: :)
6 2015-02-13 00:03:32 <petertodd> ajweiss: the patches don't break free transactions, but they'll never replace a transaction with a free transaction
7 2015-02-13 00:03:49 <ajweiss> but what about replacing a free transaction by a free transaction?
8 2015-02-13 00:05:06 <petertodd> ajweiss: it'll never do that
9 2015-02-13 00:06:47 <ajweiss> even if txMinFee is zero?
10 2015-02-13 00:09:24 <petertodd> yup
11 2015-02-13 00:09:49 <petertodd> the code doesn't take priority into account at all, and it requires the new tx to pay > fees than old, not >=
12 2015-02-13 00:10:27 <petertodd> this is important as it means every replacement is guaranteed to use up the attackers fees, so in the event of a DoS attempt they'll run out of funds
13 2015-02-13 00:10:47 <leakypat> So if someone double spends me with a replace by fee, I could create a new transaction using the double spent outputs and spend back to myself with an increased fee? I think I am misunderstanding still...
14 2015-02-13 00:11:06 <ajweiss> i see: nDeltaFees = nFees - nConflictingFees .. if (nDeltaFees < txMinFee) { need more fee }
15 2015-02-13 00:11:53 <petertodd> leakypat: read this: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
16 2015-02-13 00:12:25 <petertodd> ajweiss: the code just above is the part that rejects it even if txMinFee == 0
17 2015-02-13 00:12:53 <ajweiss> ahh, got it!
18 2015-02-13 00:14:40 <ajweiss> now, suppose the original transaction is free, and the replacement qualifies as free, but one satoshi is added in fee
19 2015-02-13 00:16:52 <petertodd> ajweiss: that *should* fail, it should be calculating it based on the fee required to relay, not priority, but I may have gotten that logic wrong
20 2015-02-13 00:18:52 <leakypat> So the proposal for replace-by-fee is to pave the way for implementations of the scorched earth method, which is a much better incentivized method of preventing double spends rather than relying on nodes to reject them?
21 2015-02-13 00:20:11 <petertodd> leakypat: more correct would be to say "what we have is broken, lets be honest to users about how bitcoin actually works so they don't keep getting burned"
22 2015-02-13 00:20:26 <petertodd> scorched-earth is an idea that *may* work in *some* situations
23 2015-02-13 00:21:05 <petertodd> equally, fixing the existing zeroconf keeps encouraging people to promote really dangerous ideas that make mining way more centralized and legally risky
24 2015-02-13 00:22:26 <leakypat> By that you mean an unconfirmed transaction is not secure, so why reject a double spend attempt ?
25 2015-02-13 00:22:45 <petertodd> leakypat: yup, against the economic incentives of the people mining
26 2015-02-13 00:24:02 <leakypat> And others are arguing , why make it easier?
27 2015-02-13 00:24:16 <leakypat> (Double spend attempts)
28 2015-02-13 00:26:25 <petertodd> because by making it clear to people how bitcoin actually works you end up with a better ecosystem in the long run
29 2015-02-13 00:26:33 <leakypat> I see
30 2015-02-13 00:26:36 <petertodd> equally, as my replace-by-fee-tools showed, it's already pretty damn easy
31 2015-02-13 00:27:51 <leakypat> How do the tools circumvent the nodes rejecting the ds attempt?
32 2015-02-13 00:29:15 <petertodd> by taking advantage of that fact that not everyone implements exactly the same rules, and because it's impossible for a node to know what is the actual doublespend
33 2015-02-13 00:31:58 <leakypat> So in the protocol 2 transactions are created, one standard, one with a "reserve" input from bob
34 2015-02-13 00:32:32 <leakypat> Bob has a transaction 2 with Alice's signed inputs and can choose to sign off on his own input to adjust the fees
35 2015-02-13 00:33:25 <leakypat> If he does this , tx2 will get priority and the only choice Alice has is to try again with increased fees
36 2015-02-13 00:34:15 <leakypat> So it becomes an arms race
37 2015-02-13 00:34:19 <petertodd> ?
38 2015-02-13 00:34:49 <petertodd> oh right, yeah, which is why after a double-spend, the obvious action is to just send it all to fees
39 2015-02-13 00:35:23 <leakypat> But isn't bob spending his own money on fees then?
40 2015-02-13 00:35:52 <ajweiss> "if i can't have it. NO ONE CAN"
41 2015-02-13 00:36:01 <petertodd> no, he's spending a net zero of his own money
42 2015-02-13 00:36:14 <petertodd> he could *choose too* spend some of his own though
43 2015-02-13 00:37:16 <ajweiss> one potential problem would be that alice pulls out her emp weapon and knocks bob off the network long enough for her doublespend to confirm
44 2015-02-13 00:37:17 <leakypat> Ah, because if the transaction succeeds he gets paid of course
45 2015-02-13 00:37:25 <petertodd> leakypat: yup
46 2015-02-13 00:37:26 <leakypat> I see
47 2015-02-13 00:37:29 <leakypat> Wow
48 2015-02-13 00:37:58 <petertodd> ajweiss: for sure, scorched earth makes the same kind of dodgy assumptions about the network as standard zeroconf does, OTOH, it makes them in a way where everyone is incentivised to help the defender rather than the attacker
49 2015-02-13 00:38:05 <leakypat> This would need implanting at wallet provider level
50 2015-02-13 00:38:12 <leakypat> Implementing
51 2015-02-13 00:38:33 <petertodd> leakypat: which I think is a *good thing* because standard wallets double-spend all the time by accident - better to not be suddely destroying funds when that happens
52 2015-02-13 00:40:29 <ajweiss> i do wonder if it would create weird incentives for miners though
53 2015-02-13 00:40:48 <petertodd> ajweiss: above and beyond their already weird incentives?
54 2015-02-13 00:41:34 <ajweiss> fair
55 2015-02-13 00:42:15 <petertodd> as an example, note how my replace-by-fee patch connects to Bitcoin XT nodes, because rather ironically that they relay double spends in an attempt to improve zeroconf security does the exact opposite
56 2015-02-13 00:42:20 <ajweiss> i guess one nice thing is that it would remove the false security blanket
57 2015-02-13 00:42:32 <petertodd> ajweiss: which *has* lost people tens of thousands of dollars
58 2015-02-13 00:42:44 <dgenr8> the irony goes deeper still
59 2015-02-13 00:43:25 <leakypat> The actual implementation would require Alice and bob to collaborate beforehand to create tx2 ?
60 2015-02-13 00:44:33 <petertodd> leakypat: with SIGHASH_ANYONECANPAY *no*, because bob can add inputs to alices tx without her help
61 2015-02-13 00:44:52 <leakypat> Aha, nice
62 2015-02-13 00:45:13 <petertodd> equally, replace-by-fee actually gets rid of some DoS attacks on ANYONECANPAY transactions
63 2015-02-13 00:46:08 <ajweiss> it would be awesome for things like lighthouse
64 2015-02-13 00:46:31 <ajweiss> to have the real transaction out there in the mempools
65 2015-02-13 00:46:43 <petertodd> ajweiss: right now a lighthouse tx can be delayed by someone adding unprofitable to mine garbage to the inputs
66 2015-02-13 00:47:06 <petertodd> ajweiss: not really feasible unfortunately - mempools simply can't accept stuff that can't be immediately mined without enabling DoS attacks
67 2015-02-13 00:47:32 <leakypat> Ok so the wallet says , Alice has signed these with ANYONECANPAY and bob can accept the unconfirmed transaction with a higher degree of security
68 2015-02-13 00:47:57 <petertodd> yup
69 2015-02-13 00:48:15 <ajweiss> i suppose a fix would be along the same thinking as replace-by-fee though
70 2015-02-13 00:48:34 <Luke-Jr> petertodd: hmm, does RBF compare absolute fee, or fee/kb?
71 2015-02-13 00:48:37 <leakypat> If wallet detects double spend, then it gets one of bobs existing outputs appends it to the transaction from Alice and maxes out the fee
72 2015-02-13 00:48:44 <ajweiss> "allow replacement if its paid for in a reasonable way"
73 2015-02-13 00:48:48 <petertodd> Luke-Jr: both, absolute fee must be higher, and fee/KB must be higher
74 2015-02-13 00:49:07 <petertodd> ajweiss: that's how I came up with the idea actually :)
75 2015-02-13 00:49:11 <ajweiss> fee/KB >=
76 2015-02-13 00:49:22 <leakypat> Bob gets nothing Alice loses , miners get paid
77 2015-02-13 00:55:24 <dgenr8> <petertodd> as my replace-by-fee-tools showed, it's already pretty damn easy <--- it always helps your attack if it runs against your own modified version of the target
78 2015-02-13 00:55:58 <petertodd> leakypat: now, do note that an advanced version could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees
79 2015-02-13 00:56:20 <petertodd> leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend
80 2015-02-13 00:57:30 <petertodd> dgenr8: huh?
81 2015-02-13 00:57:51 <leakypat> Yeah, proof of double spend would ideally be done at the protocol level
82 2015-02-13 00:58:22 <petertodd> leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas...
83 2015-02-13 01:02:13 <dgenr8> ACTION looks at RBF doublespend.py..
84 2015-02-13 01:03:01 <dgenr8> so THAT's where all those "unsuccessful double-spend attempt" messages in successful double-spends come from
85 2015-02-13 01:03:28 <petertodd> dgenr8: yup, lots of people were trying that out
86 2015-02-13 01:03:48 <dgenr8> kinda confusing though
87 2015-02-13 01:04:39 <petertodd> hmm? those were the unseccesful doublespends
88 2015-02-13 01:05:32 <dgenr8> not sure how you would know that at tx creation time. i'll dig up some txid's
89 2015-02-13 01:06:11 <petertodd> I know that because that's how the tool works
90 2015-02-13 01:32:40 <leakypat> petertodd: replace-by-fee , do you see this getting adopted? I would think something like this should happen sooner rather than later
91 2015-02-13 01:33:03 <leakypat> At the rate we are going a lot of infra is getting built on non-confirmations
92 2015-02-13 01:34:50 <leakypat> Long term it makes sense to force this to be dealt with outside of the protocol, but short term wallet/payment processor software isn't equipped to handle
93 2015-02-13 01:45:58 <dgenr8> petertodd: b1bde9f615e67e7d306b5e55f2d65876c844d09c01e21aa3f765d58e0ea6c8ef
94 2015-02-13 01:55:42 <Luke-Jr> leakypat: relay/miner policies is not protocol
95 2015-02-13 01:56:23 <Luke-Jr> leakypat: even without RBF, it's not that hard to double spend
96 2015-02-13 01:57:11 <leakypat> Whatever you call it then, implemented in the client
97 2015-02-13 01:58:07 <Luke-Jr> leakypat: my point is there is no "the client"
98 2015-02-13 01:58:15 <leakypat> I understand it is possible to double spend at the moment, not sure what the differences will be before and after in terms of probability of success, but would be interested to know
99 2015-02-13 01:58:19 <Luke-Jr> leakypat: each node operator chooses what policy he wants to run
100 2015-02-13 02:00:24 <leakypat> Luke-Jr: I get this
101 2015-02-13 02:14:50 <Diablo-D3> https://www.youtube.com/watch?v=EJ_wXOFQV3M
102 2015-02-13 04:00:59 <petertodd> dgenr8: I don't think you're understanding my point re those op_returns... the !@#$ replace-by-feetools/doublespend.py code sends the transaction witht he "unsuccessful double-spend attempt" op-return *first*, waits t seconds, and then sends a transaction *without* that op-return
103 2015-02-13 04:01:49 <petertodd> dgenr8: the purpose of the op-return - along with multisig, blacklisted addresses, etc. - is to try to make the first transaction not get accepted by the subset of miners who block op-return/multisig/etc.
104 2015-02-13 04:02:36 <petertodd> dgenr8: that subset of miners will then accept the second, double-spend transaction. additionally that second transaction pays much higher fees
105 2015-02-13 04:03:53 <petertodd> leakypat: what's interesting about the replace-by-fee patch is it doesn't actually need to get adopted by miners to work with a decent probability - tx relaying is inherently unreliable, so simply re-relaying transactions works reasonably well as a double-spending technique anyway
106 2015-02-13 04:05:12 <petertodd> leakypat: anyway, when I released those tools people immediately started losing a large amount of money due to doublespends, which has caused a decent number of companies to move to better ways of dealing with zeroconf that doesn't involve relying on the bitcoin network itself.
107 2015-02-13 04:12:29 <leakypat> petertodd: so as long as x% of nodes adopted the patch, it would be effective?
108 2015-02-13 04:13:20 <leakypat> I can see where the controversy comes from you are saying : zero means zero!
109 2015-02-13 04:13:41 <leakypat> Where as a lot of people assume: zero means, meh ok, go on then
110 2015-02-13 04:13:49 <petertodd> leakypat: nah, if ~0% of nodes adopt it it's still effective, so long as the one or two nodes that do are themselves connected to a reasonable chunk of the hashing power
111 2015-02-13 04:15:14 <petertodd> between Hearn's Bitcoin XT nodes and replace-by-fee nodes there's maybe a dozen or two at most nodes that relay double-spends on the network, and that's *plenty* enough to make it reasonably effective
112 2015-02-13 04:15:58 <leakypat> What are Hearn's XT nodes?
113 2015-02-13 04:16:54 <petertodd> leakypat: they're his fork of Bitcoin Core, that currently implements his rejected GETUTXO's feature, as well as Andresen/Harding's double-spend relaying patch
114 2015-02-13 04:17:57 <mappum> why was GETUTXOS rejected? that sounded useful
115 2015-02-13 04:18:24 <petertodd> mappum: because it was exploitable in a number of ways
116 2015-02-13 04:18:35 <petertodd> mappum: also had zero privacy
117 2015-02-13 04:18:38 <leakypat> Is that get unspent transaction outputs?
118 2015-02-13 04:18:42 <petertodd> yeah
119 2015-02-13 04:45:10 <leakypat> So Hearn's nodes *do* relay double spends?
120 2015-02-13 05:27:10 <dgenr8> petertodd: right, it just seemed odd to declare it "unsuccessful" at the outset since that's up to the network
121 2015-02-13 05:36:16 <dgenr8> i see, you're talking to blockchain-browsing people will only see the one that is confirmed. I'm too steeped in my own respend tracker, which pairs the two attempts and displays them together
122 2015-02-13 07:00:43 <petertodd> dgenr8: wtf... success or non-success of a double-spend is up to the *sender*
123 2015-02-13 07:01:40 <petertodd> dgenr8: remember, I'm sending two transactions, separated by (default) 15 seconds, if tx #2 is what gets confirmed, that certainly counts as a scucessful double-spend from the point of view of the guy who just gave you a free coffee
124 2015-02-13 07:02:15 <petertodd> dgenr8: you realise how you're arguing *my* point that from the perspective of the network you have no idea what is the double-spend, so you can't design systems that assume there is any consensus on that
125 2015-02-13 08:38:50 <wumpus> oh, the new github-merge.sh script cannot cope with issues assigned to milestones; it naively filters for "title" in the json returned by the github API, and seemingly milestones have a "title" too
126 2015-02-13 08:42:09 <wumpus> ACTION piles yet another hack on top to get the *first* title, we do need to reimplement this in python at some point to make this robust by any definition
127 2015-02-13 08:43:36 <lewellyn> wait. you're parsing json in posix sh?
128 2015-02-13 08:43:42 <lewellyn> egads.
129 2015-02-13 08:44:06 <wumpus> lewellyn: patches welcome
130 2015-02-13 08:44:16 <petertodd> probably has some kind of remote exploit that'd let github own you, if not worse...
131 2015-02-13 08:44:20 <lewellyn> wumpus: link?
132 2015-02-13 08:44:32 <lewellyn> wumpus: is there any complaint about calling a C parser? :P
133 2015-02-13 08:44:40 <lewellyn> or does it have to stay pure script?
134 2015-02-13 08:44:48 <wumpus> lewellyn: it will have to be in python
135 2015-02-13 08:45:14 <wumpus> that's the only scripting language we use in the project, compiling anything for a tool script is not acceptable
136 2015-02-13 08:45:17 <lewellyn> oh. i was thinking of having the json expanded into compound variables and addressing that as an associative array. that's the sanest way to handle json in sh.
137 2015-02-13 08:45:36 <lewellyn> it's possible fairly trivially in pure sh, but the fork is cheaper still.
138 2015-02-13 08:46:04 <lewellyn> ACTION suspects that isn't how it's done now.
139 2015-02-13 08:46:14 <wumpus> doing it in sh is just piling up on more hacks
140 2015-02-13 08:46:39 <lewellyn> not if it's properly written sh rather than by someone who knows just enough to be dangerous.
141 2015-02-13 08:47:06 <lewellyn> (the same can be said for almost any language, of course.)
142 2015-02-13 08:47:14 <wumpus> the problem is that no one knows how to properly write sh, or even how to recognize it
143 2015-02-13 08:47:36 <wumpus> just too many pitfalls
144 2015-02-13 08:47:37 <lewellyn> lots of people can write sh.
145 2015-02-13 08:47:40 <wumpus> as petertodd says
146 2015-02-13 08:48:32 <wumpus> (forget to escape a space somewhere? nice! we can now remove/modify arbitrary files)
147 2015-02-13 08:49:02 <lewellyn> then you're not quoting properly in the first place as a rule. :P
148 2015-02-13 08:49:43 <lewellyn> anyhow, since no link to the current script is forthcoming, i'm going to make a screwdriver and go to bed. i'm on EST today. ugh.
149 2015-02-13 08:49:45 <wumpus> then you have to follow some crazy 100-step plan to make sure you're using the right subset of sh, and it still works in any stupid dialect
150 2015-02-13 08:50:01 <lewellyn> write posix sh and then you'll hit anything worth running.
151 2015-02-13 08:50:04 <wumpus> yeah I'll just do it myself, but thanks
152 2015-02-13 08:50:23 <lewellyn> ACTION looks at the "have to be up in 4 hours" and really wanders off.
153 2015-02-13 09:23:33 <wumpus> there it goes, tagging 0.10.0 final
154 2015-02-13 09:24:56 <wumpus> * [new tag] v0.10.0 -> v0.10.0
155 2015-02-13 09:27:33 <jonasschnelli> *champaign-open*
156 2015-02-13 09:28:13 <gmaxwell> wumpus: when 0.10 settles some can we start prepping for a 0.9 release? there are some bugfixes (fork warning crash, log sanitization) that ought to go in plus BIP66.
157 2015-02-13 09:32:47 <wumpus> gmaxwell: sure
158 2015-02-13 09:39:45 <wumpus> feel free to start backporting things and push them to the 0.9 branch
159 2015-02-13 09:48:14 <Luke-Jr> ah. was not expecting final today, will need to rush with libblkmaker releases âº
160 2015-02-13 09:51:52 <Luke-Jr> hmm, it may be a week though
161 2015-02-13 09:57:56 <wumpus> if you had let me know that yesterday when I was announcing I was going to tag 0.10 final, we could have maybe taken that into account, it's too late now
162 2015-02-13 10:16:02 <Luke-Jr> oh well
163 2015-02-13 10:16:29 <Luke-Jr> no big dal, miners just build from git or wait
164 2015-02-13 10:16:32 <Luke-Jr> deal*
165 2015-02-13 10:20:41 <jonasschnelli> huuuu gitian build 0.10.0 final: "virtual memory exhausted: Cannot allocate memory"
166 2015-02-13 10:20:48 <jonasschnelli> maybe i need to add the -m flag again
167 2015-02-13 10:21:00 <jonasschnelli> s/flag/arg
168 2015-02-13 10:21:00 <Luke-Jr> ;)
169 2015-02-13 10:23:36 <jonasschnelli> why there is a different "binutils" "binutils_2.22-6ubuntu1.1_amd64.deb" between 0.10.0rc4 and 0.10.0final?
170 2015-02-13 10:23:54 <jonasschnelli> rc4: 0a2baebf0e2b329f7a5dc9979172544e41d2d912d376fec0479f64d589c15422 binutils_2.22-6ubuntu1.1_amd64.deb
171 2015-02-13 10:24:08 <jonasschnelli> final: fbcd95e17de18f3f138e46894648e7c453a9eccb47c1fb32bc17af57e16fac54 binutils_2.22-6ubuntu1.2_amd64.deb
172 2015-02-13 10:25:03 <jonasschnelli> i thought "bitcoin-0.10.0-osx-unsigned.dmg" (and others, expect the tars) should have the same hash then in rc4
173 2015-02-13 10:25:14 <jonasschnelli> s/expect/except
174 2015-02-13 10:25:41 <wumpus> jonasschnelli: remember the build embeds the commit hash
175 2015-02-13 10:26:01 <jonasschnelli> wumpus, ah. Clear.
176 2015-02-13 10:26:03 <wumpus> so ideally when you compare the binaries the only change you should find is that
177 2015-02-13 10:26:25 <jonasschnelli> compare osx asserts: https://builds.jonasschnelli.ch/releasebuilds/v0.10.0rc4/bitcoin-osx-0.10-build.assert against https://builds.jonasschnelli.ch/releasebuilds/v0.10.0/bitcoin-osx-0.10-build.assert
178 2015-02-13 10:28:36 <jonasschnelli> rc4 -> final: there are dep changes, binutils_2.22-6ubuntu1.1_amd64.deb, libgssapi-krb5-2_1.10+dfsg~beta1-2ubuntu0.5_amd64.deb, libk5crypto3_1.10+dfsg~beta1-2ubuntu0.6_amd64.deb, etc.
179 2015-02-13 10:28:43 <wumpus> the version of binutils reported doesn't in any way depend on the version of bitcoin core, it just reports what your vm has installed
180 2015-02-13 10:29:02 <jonasschnelli> okay.... i'll see
181 2015-02-13 10:30:48 <wumpus> in theory the binutils change could result in a difference in the binary and thus changes between builders who built with the upgraded package and the non-upgraded one, but I don't think we've ever seen that. The non-toolchain packages such as libgssapi shouldn't make any difference at all.
182 2015-02-13 10:31:44 <wumpus> a future non-vm gitian builder should thus lock in the tool chain, but doesn't need to lock in the rest of the system
183 2015-02-13 10:32:39 <wumpus> it also wouldn't need to report all that stuff in the assert
184 2015-02-13 10:34:45 <jonasschnelli> waiting for the osx signatures...
185 2015-02-13 10:34:47 <aschildbach> ACTION is building v0.10.0
186 2015-02-13 10:39:49 <jonasschnelli> is bitcoin-0.10.99-win32-setup.exe (the 0.10.99) normal or did i built wrong?
187 2015-02-13 10:40:11 <Luke-Jr> sounds like you used master's yml?
188 2015-02-13 10:40:31 <jonasschnelli> grml...my stupidity... thanks Luke-Jr
189 2015-02-13 10:44:25 <Luke-Jr> almost done w/ my gitian builds (but signing will wait until I am home)
190 2015-02-13 10:45:28 <Luke-Jr> jonasschnelli: you're not out in California by any chance, btw?
191 2015-02-13 10:47:18 <jonasschnelli> Luke-Jr, no. I live/work normaly in Switzerland but will be aways the next two weeks (Thailand, Beach).
192 2015-02-13 10:47:57 <jonasschnelli> s/aways/away for/
193 2015-02-13 10:48:01 <Luke-Jr> ah
194 2015-02-13 10:48:27 <jonasschnelli> never been in USA
195 2015-02-13 10:48:53 <hearn> jonasschnelli: nice!
196 2015-02-13 10:48:56 <hearn> enjoy!
197 2015-02-13 10:49:00 <hearn> ACTION needs to spend some time on a beach
198 2015-02-13 10:49:08 <hearn> jonasschnelli: what's your day job, if you don't mind me asking?
199 2015-02-13 10:49:33 <Luke-Jr> hearn: aren't you out by Switzerland somewhere? maybe you can meet him to sign his PGP key sometime? :p
200 2015-02-13 10:49:41 <jonasschnelli> hearn, thanks. Was a quick decicen, books yesterday, flight tmr. Wife and Kids are happy to escape the -0° temperatures...
201 2015-02-13 10:49:55 <hearn> Luke-Jr: yeah i'm in zurich
202 2015-02-13 10:49:58 <jonasschnelli> hearn, hear lives around the corner...
203 2015-02-13 10:50:31 <jonasschnelli> hearn, my dayjob, aehm... try to improve bitcoin-core. :)
204 2015-02-13 10:51:07 <jonasschnelli> serious: i'm doing some iOS/Android projects for some major swiss brands.
205 2015-02-13 10:51:22 <hearn> cool
206 2015-02-13 10:51:49 <hearn> if you also sometimes work out of coffee shops and cafes then ping me some time :) we should get you me and sipa together when he is back
207 2015-02-13 10:52:15 <jonasschnelli> hearn, yes. That would really be nice!
208 2015-02-13 10:52:44 <jonasschnelli> And Luke-Jr's concerts if i'm a real person or not will be gone.. :)
209 2015-02-13 10:52:57 <hearn> assuming he believes me and sipa are real :)
210 2015-02-13 10:53:03 <hearn> we might all be clever sybils of each other!
211 2015-02-13 10:53:06 <hearn> you never know! :)
212 2015-02-13 10:53:19 <Luke-Jr> jonasschnelli: I'm not concerned, but unsigned PGP keys are hard to recommend for verifying bins
213 2015-02-13 10:53:46 <jonasschnelli> yes. All possible.... but where is the difference between a github entity and a real-world entity? I could be a bad criminal and still do good things for bitcoin-core...
214 2015-02-13 10:53:51 <Luke-Jr> hearn: pretty sure I've talked to you on IRC when sipa is clearly not at a keyboard :P
215 2015-02-13 10:54:51 <jonasschnelli> Luke-Jr, time-delayed/AI bot? :)
216 2015-02-13 10:54:59 <hearn> yeah, my PGP key is itself not signed very much. but i can sign it with my suisseID and put it on my website, which has an EV cert. so that'd root you to reality through me and my swiss company
217 2015-02-13 10:55:44 <jonasschnelli> ACTION needs to apply for the susseID finally
218 2015-02-13 10:55:48 <Luke-Jr> I've also met hearn in person a few times
219 2015-02-13 10:56:23 <hearn> jonasschnelli: it's not that useful. i mean, it's sort of useful for signing PDFs and things. OS X Yosemite broke things really badly though, it took them months to fix things and it's still kind of flaky compared to what it used to be like :(
220 2015-02-13 10:56:30 <hearn> that's apple's fault i guess rather than suisseids though
221 2015-02-13 10:57:49 <jonasschnelli> Didn't dive in there yet. But apple always breaks backward comp. >shame<
222 2015-02-13 10:58:08 <jonasschnelli> damit: again: bitcoin-0.10.99-linux32.tar.gz
223 2015-02-13 10:59:34 <Luke-Jr> O.o
224 2015-02-13 11:02:00 <Luke-Jr> my results: http://codepad.org/GSYI437I
225 2015-02-13 11:02:15 <jonasschnelli> hearn, so you no longer work at google? Completely following your own stuff now? Lighthouse vinumeris?
226 2015-02-13 11:02:26 <hearn> yeah
227 2015-02-13 11:02:40 <jonasschnelli> nice
228 2015-02-13 11:03:14 <Luke-Jr> hearn: on that topic, any plans to BIP lighthouse's stuff and/or port to BCCore?
229 2015-02-13 11:04:12 <hearn> getutxo already has a BIP. there are three patches in bitcoin XT and two of them are open on github somewhere for Core, i think
230 2015-02-13 11:04:17 <jonasschnelli> revival of bip64
231 2015-02-13 11:04:45 <Luke-Jr> hearn: this is all Lighthouse is? O.o
232 2015-02-13 11:04:58 <hearn> oh, you mean, like, everything in lighthouse?
233 2015-02-13 11:05:06 <Luke-Jr> yes
234 2015-02-13 11:05:10 <hearn> the project and pledge file formats are extensions of BIP70. i could BIP those, if someone wanted it enough
235 2015-02-13 11:05:20 <Luke-Jr> particular, if i want to contribute toward a bounty
236 2015-02-13 11:06:18 <aschildbach> ACTION just signed 0.10.0
237 2015-02-13 11:07:24 <hearn> my plan was to wait until the product has reached 1.0 quality (currently it's labelled as beta for a reason). assuming no further protocol changes are queued i can document it all in a BIP at that point, so other wallets could implement pledging functionality
238 2015-02-13 11:07:39 <Luke-Jr> ah, makes sense
239 2015-02-13 11:10:33 <hearn> it's pretty simple
240 2015-02-13 11:10:48 <hearn> well, the protocol is simple. actually implementing it is a pain in the ass :)
241 2015-02-13 11:11:36 <Luke-Jr> âº
242 2015-02-13 11:13:40 <jonasschnelli> ACTION still thinks there should be a reliable (from core team, deterministic built, etc.) wallet to build trust to potential new bitcoin users
243 2015-02-13 11:14:41 <Luke-Jr> "core team" shouldn't be considered any differently from any other team of expert devs
244 2015-02-13 11:15:12 <hearn> jonasschnelli: in theory lighthouse can be deterministically built. afaik nobody has tried to reproduce my builds yet though
245 2015-02-13 11:15:38 <hearn> but sure
246 2015-02-13 11:15:46 <hearn> a better core wallet is a good thing. just .... a lot of work.
247 2015-02-13 11:15:49 <Luke-Jr> anyhow, Bitcoin Core's wallet, while not perfect, is still pretty good
248 2015-02-13 11:16:04 <jonasschnelli> Luke-Jr, "core team" is different than "any other team" in case of a new users tring to "trust in that bitcoin thing"
249 2015-02-13 11:16:53 <jonasschnelli> Luke-Jr, that wallet is okay, but the problems is a missing SPV mode...
250 2015-02-13 11:17:15 <Luke-Jr> jonasschnelli: we can screw up just as easily as any other competent developer, and others can be just as competent and make decent wallets just as well
251 2015-02-13 11:17:30 <Luke-Jr> yes, everyone agrees SPV mode would be nice to have
252 2015-02-13 11:17:37 <jonasschnelli> i still think if more people with a simple understanding of IT, etc. could trust in a wallet which comes out of the kitchen of the "bitcoin makers" (*duck*) would be good
253 2015-02-13 11:18:04 <jonasschnelli> Luke-Jr, course everyone can screw up. It's not about the tech. risks. It's about new users trust.
254 2015-02-13 11:19:13 <wumpus> jonasschnelli: be careful of introducing unnecessary centralization though
255 2015-02-13 11:19:20 <Luke-Jr> jonasschnelli: wallet security is very different from consensus security. an independent wallet devteam could very well be just as or more "trustworthy"
256 2015-02-13 11:19:40 <jonasschnelli> wumpus, hmm...
257 2015-02-13 11:19:47 <wumpus> being the 'only trustworthy team' also puts a lot of pressure on us
258 2015-02-13 11:19:55 <wumpus> I'd rather not go that way
259 2015-02-13 11:20:18 <jonasschnelli> thats also true....
260 2015-02-13 11:20:19 <aschildbach> Is there any possibility to build the OSX version of bitcoin core without that proprietary dependency?
261 2015-02-13 11:20:33 <jonasschnelli> aschildbach, :)
262 2015-02-13 11:20:34 <wumpus> aschildbach: unfortunately, no, unless you get apple to change their license terms
263 2015-02-13 11:20:43 <Luke-Jr> aschildbach: older OSX gitian stuff did, but some update made it necessary :/
264 2015-02-13 11:20:57 <aschildbach> too bad
265 2015-02-13 11:21:02 <Luke-Jr> wumpus: isn't the small part we use actually outside the non-free licensing?
266 2015-02-13 11:21:16 <wumpus> Luke-Jr: huh? we've never been able to build without the OSX SDK, which is non-free
267 2015-02-13 11:21:28 <Luke-Jr> wumpus: only a tiny part of it..
268 2015-02-13 11:21:52 <Luke-Jr> of course, even if we extract and distribute it, we can't guarantee from that alone that it's authentic
269 2015-02-13 11:21:53 <aschildbach> If it's just a small header file, maybe re-implement it?
270 2015-02-13 11:22:02 <wumpus> unless someone goes through a masochistic exercise like the mingw devs did and reimplement everything in a cleanroom fashion, that's just not going to happen
271 2015-02-13 11:22:07 <Luke-Jr> aschildbach: think it's lib stubs, not headers
272 2015-02-13 11:22:10 <wumpus> aschildbach: sure, go ahead
273 2015-02-13 11:22:13 <jonasschnelli> maybe we could register as "bitcoin organization" at during the script the SDK gets downloaded over that account ...
274 2015-02-13 11:22:26 <jonasschnelli> s/at/and
275 2015-02-13 11:22:38 <wumpus> aschildbach: but remember that macosx likes to change everything every release, so what you build one day will likely be useless the next
276 2015-02-13 11:22:40 <Luke-Jr> jonasschnelli: the download is not the issue..
277 2015-02-13 11:22:44 <aschildbach> I'm not really into Macs I must admit...
278 2015-02-13 11:23:12 <Luke-Jr> jonasschnelli: there is no way to use the download without a Mac
279 2015-02-13 11:23:37 <wumpus> well sure that 'needs a mac' extraction issue could feasibly be solved
280 2015-02-13 11:24:14 <aschildbach> Back in the 80ies there were Mac emulators...
281 2015-02-13 11:24:40 <wumpus> but even with that, you can't go without the big download that needs a user login in the first place
282 2015-02-13 11:25:01 <Luke-Jr> aschildbach: lol, totally different platforms
283 2015-02-13 11:25:02 <wumpus> haha, emulating the whole mac would be an interesting but kind of overkill solution :-)
284 2015-02-13 11:25:04 <hearn> you can always just not reproduce the mac build. other people can.
285 2015-02-13 11:25:18 <wumpus> hearn: yes, that's what he's doing
286 2015-02-13 11:25:23 <aschildbach> hearn: Right, that's what I'm doing currently.
287 2015-02-13 11:25:25 <hearn> ok
288 2015-02-13 11:26:27 <wumpus> you don't have to build for all OSes, there is also someone that only builds linux gitian
289 2015-02-13 11:27:42 <jonasschnelli> wumpus: your right with the centralization issue when saying only the reference wallet implementation is secure. I was not thinking this well enough from that side...
290 2015-02-13 11:27:59 <michagogo> 12:31:43 <wumpus> in theory the binutils change could result in a difference in the binary and thus changes between builders who built with the upgraded package and the non-upgraded one, but I don't think we've ever seen that. The non-toolchain packages such as libgssapi shouldn't make any difference at all.
291 2015-02-13 11:28:58 <michagogo> If someone has a lot of time, it'd be interesting to go back and see if all our old versions are still reproducible
292 2015-02-13 11:29:18 <michagogo> (A lot of time and/or a *lot* of machines)
293 2015-02-13 11:30:43 <jonasschnelli> osx: would it be very evil if we would register for a organization account and download the sdk during the dependencies "make"? Okay. Maybe there's the public password problem. Apple may close the account
294 2015-02-13 11:31:51 <hearn> yeah that'd violate their account ToS i think
295 2015-02-13 11:33:22 <Luke-Jr> jonasschnelli: well, every other wallet AFAIK does have serious issues currently - I'm just arguing that is coincidental, and not necessary ;)
296 2015-02-13 11:33:24 <jonasschnelli> aren't we breakin these anyways? (Cross build on Linux?!)
297 2015-02-13 11:33:41 <wumpus> jonasschnelli: I don't think evil is the right name for that, but it's hacky, and right now wouldn't work as you need a mac to extract the SDK from that archive
298 2015-02-13 11:34:12 <wumpus> jonasschnelli: feel free to make a script like that though - we could use it separately, it doesn't have to be part of 'make' at all
299 2015-02-13 11:34:37 <wumpus> (and thus it's also fine if it only works on macs, just automates the process)
300 2015-02-13 11:34:39 <Luke-Jr> jonasschnelli: I don't recall requiring to agree not to use it for cross-compiling.
301 2015-02-13 11:36:06 <Luke-Jr> (had such a term been required of me, I would not have agreed, as I have no other use for it
302 2015-02-13 11:37:55 <wumpus> jonasschnelli: if you'd been truly evil you'd automate the creation of the account too :p
303 2015-02-13 11:39:19 <jonasschnelli> wumpus: :-)
304 2015-02-13 11:40:32 <wumpus> or, bugmenot has a few user/passwords for the site too, could fetch from there
305 2015-02-13 11:40:49 <wumpus> "Other: Seriously Apple? Need a Account for downloading a SDK?" lol @ comment
306 2015-02-13 11:44:20 <jonasschnelli> Totally! I've thought after the passing of Jobs this control freaking nightmare comes to an end. But dosen't look like
307 2015-02-13 12:00:11 <michagogo> Luke-Jr: did you read every part of all the ToSes?
308 2015-02-13 12:12:01 <wumpus> michagogo: I guess that's useful if you can't get to sleep :p
309 2015-02-13 12:14:09 <michagogo> wumpus: the ToS?
310 2015-02-13 12:18:26 <wumpus> yes, reading every part of every ToS, at some point you'd fall asleep right? just a joke, never mind :)
311 2015-02-13 12:19:07 <rnicoll> I think someone once illustrated that you'd never actually get everything done if you read every ToS in detail
312 2015-02-13 12:30:32 <wumpus> a machine-readable format for ToSes would be useful, so you could automatically check if the terms are acceptable
313 2015-02-13 12:32:25 <rnicoll> standardised clauses would be a huge and one would hope simpler leap forward
314 2015-02-13 12:36:38 <jonasschnelli> lol @ automatic ToS check! Such a funny idea. î
315 2015-02-13 12:39:02 <wumpus> although it'd probably end in the same way as e.g. the android permissions system, people will accept anyway because they really want the app, no matter if it contains the 'sacrifice your first-born to us' clause and they're aware of it
316 2015-02-13 12:39:37 <GAit> is there any python bindings for libsecp256k1?
317 2015-02-13 12:41:32 <wumpus> sounds like something that gooogle, or github, could answer better
318 2015-02-13 12:42:36 <GAit> wumpus: of course, i didn't find any on github or google, i thought maybe someone was working on one which was yet to be published and join forces
319 2015-02-13 12:42:40 <rnicoll> if there's none readily available, I suspect not at this point
320 2015-02-13 12:43:58 <wumpus> gmaxwell: I've backported #5770 https://github.com/bitcoin/bitcoin/commit/6b4163b972e58e2a145342b973ed02bb78fc04b9 to 0.9, *every single change* was a conflict, so I hope I got it right
321 2015-02-13 12:44:21 <wumpus> GAit: easiest in that case would probably to wrap it using ctypes
322 2015-02-13 12:44:59 <GAit> wumpus: probably yes
323 2015-02-13 12:45:00 <wumpus> at least that's what I always do if I need to interface with some C library from python and there's no binding (or the binding sucks)
324 2015-02-13 12:45:33 <wumpus> bonus is that it works with pypy too
325 2015-02-13 12:49:11 <GAit> have not used pypy yet but i see they are advancing at a great pace
326 2015-02-13 13:16:21 <michagogo> "Works with pypy"? I thought pypy is a python package manager?
327 2015-02-13 13:16:46 <nkuttler> nope, pypy.org
328 2015-02-13 13:46:25 <michagogo> Hm, why are the os x gitian signer inputs not versioned?
329 2015-02-13 13:57:06 <wumpus> michagogo: because that makes it easier to use them as inputs (which expect a constant name)
330 2015-02-13 13:57:25 <wumpus> gitian doesn't support e.g. wildcards for the inputs
331 2015-02-13 13:57:45 <michagogo> wumpus: isn't it a ruby string?
332 2015-02-13 13:58:04 <michagogo> Why can't we use #{variable} in the input string?
333 2015-02-13 13:58:15 <michagogo> Oh, it's yml. Right.
334 2015-02-13 14:02:05 <wumpus> well there is no reason why except that it's simply not implemented, feel free to make that work. You'd need need to add an argument to gitian-builder to specify which input file(s) to use. Although I think it may be more trouble than it's worth
335 2015-02-13 14:17:00 <michagogo> wumpus: I was thinking we could use an existing version variable
336 2015-02-13 14:17:26 <michagogo> But that doesn't really help with yml
337 2015-02-13 14:18:11 <michagogo> I guess gitian could be changed to search-and-replace certain strings with variables, though
338 2015-02-13 17:47:55 <cfields> gitian builders: osx detached sig: https://bitcoincore.org/cfields/bitcoin-0.10.0/signature.tar.gz
339 2015-02-13 18:00:48 <cfields> michagogo / jonasschnelli ^^. In case that wasn't clear, that's the sig needed for the osx-signer descriptor.
340 2015-02-13 18:01:06 <jonasschnelli> cfields, clear. already loaded...
341 2015-02-13 18:48:06 <embicoin> hello, I am trying to learn some bitcoin code, I found the OPAL_EVAL implementation, where Gavin created an enum called "txntype", now called txnouttype... Well, my question is, how does it work? when you instance a variable of type "txnouttype", called something like whichtype which initial value does it take and how does it modify itself? I am reading the wiki but I don't fully understand...
342 2015-02-13 18:48:07 <embicoin> ...the mechanics
343 2015-02-13 18:48:18 <embicoin> Could somebody enlight me please?
344 2015-02-13 18:50:14 <embicoin> I mean, I understand that whichtype is used in several conditions in the code,, like to check if it is standard or null_data, but my exact question is how does it adopt one or another value?
345 2015-02-13 19:13:39 <embicoin> ok, I reviewed the code that I didn't understand (exactly line 670 at main.cpp, I understood that it always initializes which value 0, but now I see that the function IsStandard takes whichtype by reference, so it is able to modify it...
346 2015-02-13 19:14:16 <embicoin> I was reading old code, when IsStandard did not take whichtype as a parameter, so it could not modify it...
347 2015-02-13 19:14:44 <sipa> yeah, using pass-by-ref for output variables can be confusing
348 2015-02-13 19:15:42 <embicoin> I was looking at pre "Log reason for non-standard transaction rejection " commit code
349 2015-02-13 19:23:01 <embicoin> ohhh fool of me in the same commit that "whichtype" was added to that lines of code, the isStandard function was also modified to accept it by ref, so now I found how messed was my code, where the whichtype was defined but the IsStandard function was not taking it as an argument :S
350 2015-02-13 19:23:15 <sipa> cfields: where is the detached signature thing i need to fetch for 0.10?
351 2015-02-13 19:23:45 <cfields> sipa: https://bitcoincore.org/cfields/bitcoin-0.10.0/signature.tar.gz
352 2015-02-13 19:23:50 <cfields> is that what you meant?
353 2015-02-13 19:24:24 <sipa> i presume so
354 2015-02-13 19:25:32 <embicoin> sorry for insisting in that topic, but whats would be the consequences if more than 1 OP_RETURN was allowed in the IsStandard function?
355 2015-02-13 19:26:06 <embicoin> if muti-op-return was allowed, I mean
356 2015-02-13 19:31:04 <CP_> At devcore Gavin said that non-standard transactions are now supported via P2SH. The developer guide says that the redeem script is checked to see if it is standard, and rejected if it isn't. Is this updated for 0.10? Does anyone know for sure? Thanks
357 2015-02-13 19:31:26 <sipa> CP_: the docs are likely outdated
358 2015-02-13 19:31:42 <sipa> there are still a few constraints on the scripts in p2sh
359 2015-02-13 19:32:14 <sipa> but they're not matched against standard templates anymore
360 2015-02-13 19:32:26 <CP_> Thanks
361 2015-02-13 19:34:31 <sipa> cfields: no match
362 2015-02-13 19:34:50 <sipa> cfields: oh, the unsigned input doesn't match
363 2015-02-13 19:34:56 <cfields> sipa: did you remember to rename the input file?
364 2015-02-13 19:35:21 <cfields> cp build/out/bitcoin-*-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
365 2015-02-13 19:35:50 <sipa> i don't remember anything, but i thought i added that step to my automation script :)
366 2015-02-13 19:36:30 <cfields> double-checking mine
367 2015-02-13 19:36:37 <sipa> yours is correct, mine is wrong
368 2015-02-13 19:36:48 <sipa> i probably used to rc4 unsigned output
369 2015-02-13 19:37:50 <cfields> ok
370 2015-02-13 19:40:54 <grim21> do instructions exist to build for windows? I didn't see anything about it when looking through the docs in the source tree
371 2015-02-13 19:40:55 <sipa> cfields: match
372 2015-02-13 19:41:08 <sipa> grim21: unsupported, though there are a few people who do
373 2015-02-13 19:41:19 <cfields> hooray
374 2015-02-13 19:41:28 <grim21> if it's unsupported, how do official builds end up at bitcoin.org?
375 2015-02-13 19:41:40 <tigereye> hey cory - was nice meeting you in person in Boston
376 2015-02-13 19:41:43 <sipa> grim21: well, building *on* windows is not supported; building *for* windows is done through cross-compilation
377 2015-02-13 19:42:22 <grim21> not very familiar with cross-compilation, so i'll probably just leave that one alone. thanks for the reply!
378 2015-02-13 19:42:40 <sipa> grim21: all releases are built from within a deterministic virtual machine running linux, so the process is repeatable, and everyone can compare the output (which should be byte-for-byte identical)
379 2015-02-13 19:43:02 <harding> CP_: I'll update the P2SH / standard tx bit of the dev docs tomorrow. Thanks for finding that, and sorry about any confusion.
380 2015-02-13 19:43:43 <tigereye> I've run into an error building 0.10 when it gets to libcrypto. "undefined reference to `dlopen` and dlsym, dlclose, dlerror. Any gueses?
381 2015-02-13 19:44:02 <grim21> sipa: yeah, i have just spun up a vmware machine running Debian 6.0.10 that I was going to attempt to cross compile with, but I don't really want to spend the time building when I know that an official release of 0.10 will probably surface sooner rather than later
382 2015-02-13 19:44:33 <cfields> tigereye: hi. help me put a name/face to your nick?
383 2015-02-13 19:44:48 <tigereye> oooh sorry. didn't realize I was logged in as tigereye. I'm Michael Perklin.
384 2015-02-13 19:44:57 <cfields> tigereye: you need -ldl. Shouldn't though. what' your setup?
385 2015-02-13 19:45:10 <sipa> grim21: 0.10 final is being built as we speak
386 2015-02-13 19:45:22 <tigereye> that's what I figured... I'd think that flag would be in the configure script already...
387 2015-02-13 19:45:29 <grim21> sipa: thanks :)
388 2015-02-13 19:45:40 <tigereye> I'm on a Slackware build and have built previous versions without problems. I'll try adding -ldl
389 2015-02-13 19:46:07 <cfields> tigereye: ah, got ya now. nice meeting you as well.
390 2015-02-13 19:46:39 <cfields> tigereye: sounds like your openssl (i assume) isn't adding -ldl to its pkg-config ldflags
391 2015-02-13 19:46:51 <cfields> are you using a system package?
392 2015-02-13 19:47:02 <tigereye> i'll update openssl too just to be safe.
393 2015-02-13 19:47:24 <cfields> you're building >=0.10 ?
394 2015-02-13 19:47:31 <cfields> nm, i see.
395 2015-02-13 19:47:35 <tigereye> the tagged .tar.gz of 0.10
396 2015-02-13 19:48:29 <cfields> ok. careful updating openssl if you're running older versions of bitcoind also.
397 2015-02-13 19:48:40 <tigereye> i'm planning on replacing it
398 2015-02-13 19:48:53 <tigereye> this box is running like 0.8 or something old. it's time to upgrade
399 2015-02-13 19:49:54 <cfields> tigereye: any reason not to use the official binary as opposed to building from source?
400 2015-02-13 19:50:09 <bliljerk101> is there a fork happening?
401 2015-02-13 19:50:22 <tigereye> it's a slackware box. I've always gotten used to building everything on this thing :D I guess I could grab a bin too...
402 2015-02-13 19:52:27 <cfields> tigereye: not trying to detract you from building, just reminding you that the official bin is an option. It's more likely to be safe since the toolchain/deps have been vetted.
403 2015-02-13 19:53:39 <sipa> if you just want a binary for your own use, and not the deterministic version, using the depends/ system directly is probably easiler
404 2015-02-13 19:54:17 <tigereye> us slackware users are nutty tho. We don't need no package distros! :P
405 2015-02-13 19:54:57 <sipa> seems like a good idea for something like bitcoin
406 2015-02-13 20:06:54 <fronti> hallo
407 2015-02-13 20:08:21 <jonasschnelli> hi
408 2015-02-13 20:08:45 <fronti> a question running bitcoind with netonly=tor i noticed on my node that there are in getpeerinfo nodes listed with: "addr" : "[2a01:4f8:210:5046::2]:40394" shouldn't this blocked by onlynet=tor?
409 2015-02-13 20:09:21 <jonasschnelli> fronti, maybe #bitcoin?
410 2015-02-13 20:11:46 <fronti> ok, sorry then i try there :)
411 2015-02-13 20:26:25 <sipa> fronti: onlynet only controls outgoing connections
412 2015-02-13 20:29:50 <fronti> ok, thanks. this is what I miss
413 2015-02-13 21:05:38 <winterflaw> hey, all
414 2015-02-13 21:05:52 <winterflaw> can I ask a question about bitcoin core?
415 2015-02-13 21:08:01 <jonasschnelli> sure
416 2015-02-13 21:08:33 <winterflaw> thanks :-)
417 2015-02-13 21:08:34 <winterflaw> so
418 2015-02-13 21:09:03 <winterflaw> I'm new to all this - I've just issud my first send from bitcoin core; the problem I think is that by default the transaction fee is set to zero
419 2015-02-13 21:09:19 <winterflaw> to the transaction has been unconfirmed now (zero confirms) for about ten hours
420 2015-02-13 21:09:28 <winterflaw> I've configured the client to use now the normal 0.1 mBTC fee
421 2015-02-13 21:09:33 <winterflaw> question is
422 2015-02-13 21:09:41 <winterflaw> when the client retries the transaction
423 2015-02-13 21:10:00 <winterflaw> will it use the currently configured fee, or the fee configured at the time the transaction was created?
424 2015-02-13 21:11:32 <jonasschnelli> the fee which you gave during the creation of the transaction.
425 2015-02-13 21:11:50 <jonasschnelli> the default fee should not be zero
426 2015-02-13 21:12:13 <jonasschnelli> you did probably change the fee over a startup arg or over the config file
427 2015-02-13 21:12:21 <winterflaw> well
428 2015-02-13 21:12:27 <winterflaw> I may be wrong, but *really* think not
429 2015-02-13 21:12:34 <winterflaw> fresh install of the 64 bit client on windows
430 2015-02-13 21:12:57 <winterflaw> it's a GUI, so no fiddling with command line args, etc
431 2015-02-13 21:13:35 <winterflaw> I am of course now I know the purpose of the fee surprised at the idea the default would be zero
432 2015-02-13 21:14:02 <ajweiss> was the "send as free if possible" box checked in coin control?
433 2015-02-13 21:14:24 <winterflaw> I don't know - I don't remember seeng that as an option
434 2015-02-13 21:14:38 <winterflaw> in fact
435 2015-02-13 21:14:41 <winterflaw> it is not an option
436 2015-02-13 21:15:16 <ajweiss> you have have to check some box to "enable advanced coin control features" in order to see it
437 2015-02-13 21:15:19 <ajweiss> ^may
438 2015-02-13 21:15:29 <winterflaw> yes - it is checked
439 2015-02-13 21:16:06 <ajweiss> "send as zero-fee if possible"?
440 2015-02-13 21:16:21 <winterflaw> one second -
441 2015-02-13 21:16:24 <ajweiss> oh wait you're probably on 0.9
442 2015-02-13 21:16:28 <winterflaw> 0.9.3
443 2015-02-13 21:16:31 <ajweiss> ohh
444 2015-02-13 21:16:36 <winterflaw> ooooh?
445 2015-02-13 21:16:43 <ajweiss> yeah i'm not sure how it works there
446 2015-02-13 21:16:48 <winterflaw> ahhh =-)
447 2015-02-13 21:22:18 <winterflaw> thanks for your time guys - have to free up some RAM, browser closing now
448 2015-02-13 22:15:28 <hegemoOn> sorry to ask stupid question, but in bitcoin, signature only occur when spending it right ?
449 2015-02-13 22:16:29 <belcher> #bitcoin might be a better channel, but yes essentially
450 2015-02-13 22:21:10 <hegemoOn> ok
451 2015-02-13 22:21:12 <hegemoOn> thanks
452 2015-02-13 23:48:36 <Azelphur> Just to make sure I'm doing stuff right, if I want to monitor for when a payment lands on an address, I monitor the outputs of the transaction, and add all the values together for the same address to see if it adds up to my total?
453 2015-02-13 23:49:15 <Azelphur> or actually I don't even think I need to do that, can you have multiple outputs to the same address on a single tx?