1 2013-11-08 00:00:12 <sipa> forrestv: you mean a merkle path for each of its inputs?
2 2013-11-08 00:00:24 <forrestv> sipa, yes, oops
3 2013-11-08 00:00:32 <sipa> that is no proof of spendability
4 2013-11-08 00:00:51 <sipa> just a proof of spendable-once-upon-a-time
5 2013-11-08 00:00:52 <forrestv> what do you mean?
6 2013-11-08 00:00:59 <sipa> it can be spent already
7 2013-11-08 00:01:06 <sipa> ugh
8 2013-11-08 00:01:07 <TD> sipa: he is talking about a merkle branch for a non-existant utxo tree
9 2013-11-08 00:01:09 <sipa> i need sleep
10 2013-11-08 00:01:21 <TD> ACTION too
11 2013-11-08 00:01:22 <sipa> yes yes, sorry
12 2013-11-08 00:01:28 <TD> night
13 2013-11-08 00:23:26 <sipa> gavinandresen, jgarzik, gmaxwell, wumpus: have you seen this http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/ ?
14 2013-11-08 00:23:51 <sipa> it sounds a bit biased and possibly not that bad... but it does make me want to reconsider moving away from sf entirely
15 2013-11-08 00:24:41 <gavinandresen> https://bitcoincore.org/ could start serving binaries, modulo DoS protection
16 2013-11-08 00:25:35 <gavinandresen> ⦠well, and we need somebody dedicated to making sure it stays secure
17 2013-11-08 00:25:46 <abrkn> whos the "third" guy on letstalkbitcoin all the time? theres the host and the female and one more
18 2013-11-08 00:25:57 <gavinandresen> abrkn: Andreas
19 2013-11-08 00:26:05 <abrkn> gavinandresen: so not you?
20 2013-11-08 00:26:16 <abrkn> gavinandresen: does he have a nick?
21 2013-11-08 00:26:23 <sipa> Goonie?
22 2013-11-08 00:26:27 <gavinandresen> abrkn: heck no, I'm too busy. I think he is aantop
23 2013-11-08 00:27:04 <gavinandresen> Is Goonie here in IRC Andreas on letstalkbitcoin?
24 2013-11-08 00:27:29 <sipa> i've never watched letstalkbitcoin
25 2013-11-08 00:27:38 <sipa> Goonie == Andreas Schildbach
26 2013-11-08 00:27:43 <abrkn> its an audio show, pretty ok, but its very, very, very u.s. centric
27 2013-11-08 00:27:55 <abrkn> its like they dont know anything outside the u.s exists
28 2013-11-08 00:28:00 <ryan-c> I'm trying to build bitcoin from git, it's failing to find Boost::System. I have libboost-all-dev installed on ubuntu 13.10.
29 2013-11-08 00:28:15 <sipa> ryan-c: https://github.com/bitcoin/bitcoin/issues/3219
30 2013-11-08 00:28:31 <ryan-c> sipa: thank you
31 2013-11-08 00:28:40 <sipa> abrkn: then i'm sure it's a different andreas
32 2013-11-08 00:29:23 <ryan-c> Oh, that issue is only 8 hours old
33 2013-11-08 00:29:33 <ryan-c> well i don't feel so bad about my google-fu now.
34 2013-11-08 00:30:35 <abrkn> the whole bitcoin foundation concept confuses me. they keep fronting gavin and saying they're hiring lobbyists in the u.s
35 2013-11-08 00:30:51 <gavinandresen> abrkn: off-topic here
36 2013-11-08 00:30:58 <abrkn> gavinandresen: apologies
37 2013-11-08 00:32:05 <abrkn> from me, that is :)
38 2013-11-08 00:32:28 <sipa> what does "fronting" mean?
39 2013-11-08 00:32:58 <abrkn> sipa: gavin is right, it's the wrong chan. i wanted to know what he thinks, but its not fair to ambush in -dev
40 2013-11-08 00:33:27 <gavinandresen> sipa: "fronting" means "promoting as spokesperson"
41 2013-11-08 00:33:30 <gavinandresen> I think
42 2013-11-08 00:35:11 <ryan-c> ...did gcc just oom trying to build bitcoin?
43 2013-11-08 00:35:24 <abrkn> happens to me every day man :)
44 2013-11-08 00:35:25 <ryan-c> ...yup...
45 2013-11-08 00:35:34 <ryan-c> How is 512MB not enough?
46 2013-11-08 00:35:39 <abrkn> never has
47 2013-11-08 00:35:40 <Evilmax> hi all
48 2013-11-08 00:35:46 <ryan-c> How much do I need?
49 2013-11-08 00:35:52 <abrkn> ryan: ive done well with 2gb swap
50 2013-11-08 00:36:03 <Evilmax> i am using "sendfrom" command in bitcoind
51 2013-11-08 00:36:09 <Evilmax> but it seems not work
52 2013-11-08 00:36:12 <Evilmax> why?
53 2013-11-08 00:36:21 <ryan-c> abrkn: It's a vm, so i can just respawn it with more mem
54 2013-11-08 00:36:45 <abrkn> ryan: give it a shot at 4gb
55 2013-11-08 00:36:46 <ryan-c> Evilmax: Can you elaborate on "seems not work"?
56 2013-11-08 00:36:55 <Evilmax> there is an alternative? i want not use "sendtoaddress" because i am afraid that, in this way, an account can spend all server balance
57 2013-11-08 00:37:01 <ryan-c> abrkn: WTF. Okay.
58 2013-11-08 00:37:09 <Evilmax> ryan-c...it does not send btc
59 2013-11-08 00:37:22 <Evilmax> wait...i will write the error (i use curl)
60 2013-11-08 00:37:36 <ryan-c> Evilmax: You can try locking all the bitcoins you don't want to spend and then do a transaction
61 2013-11-08 00:37:46 <Evilmax> {"result":0.00000000,"error":null,"id":"t0"}
62 2013-11-08 00:38:09 <ryan-c> Evilmax: I suggest you try experimenting on testnet - I'd be happy to send you 100 testnet coins to play with.
63 2013-11-08 00:38:10 <Evilmax> i want that an account of my bitcoind daemon can move his coins but not all coins
64 2013-11-08 00:38:40 <Evilmax> on test net i can charge 100 coins?!
65 2013-11-08 00:38:45 <Evilmax> wow
66 2013-11-08 00:38:50 <abrkn> ryan: im just guessing here from compiling litecoind. i never compiled bitcoind from source
67 2013-11-08 00:39:10 <ryan-c> Evilmax: I can give you testnet coins for free. They're totally worthless for anything other than testing.
68 2013-11-08 00:39:24 <michagogo> cloud|Evilmax: You probably don't want to be using accounts for keeping balances of different users separate
69 2013-11-08 00:39:26 <abrkn> whats confirmation time on testnet like these days?
70 2013-11-08 00:39:26 <Evilmax> ok ryan-c
71 2013-11-08 00:39:27 <Evilmax> pleas
72 2013-11-08 00:39:38 <Evilmax> please...first let me take a look to config file
73 2013-11-08 00:39:51 <ryan-c> Evilmax: You'll need to restart bitcoind in testnet mode.
74 2013-11-08 00:40:16 <Evilmax> maybe it doesn't work because "paytxfee=0.00" in config?
75 2013-11-08 00:40:27 <Evilmax> i have to write paytxfee=0.0005?
76 2013-11-08 00:40:38 <michagogo> cloud|abrkn: 20 minutes minus time since last block
77 2013-11-08 00:40:47 <ryan-c> Evilmax: sendfrom doen't inherently require a fee
78 2013-11-08 00:41:05 <abrkn> michagogo|cloud: not bad :) enormous last time i tried, gave up on it and went straight to real
79 2013-11-08 00:41:05 <gribble> 1701
80 2013-11-08 00:41:05 <michagogo> cloud|;;calc 128709 % 2016
81 2013-11-08 00:41:13 <ryan-c> what are the arguments you're using to sendfrom?
82 2013-11-08 00:41:48 <DonnchaC> Hi, I'm trying to create tx's spending from multisig address in python. I'm pretty sure I am generating my raw transaction correctly but I'm not sure whats going wrong (possibily with signing). When I try broadcast the fully signed tx blockchain.info tells me "Unable To find all tx inputs" - https://gist.github.com/anonymous/ac6b28a729b595d06c53
83 2013-11-08 00:41:55 <Evilmax> i use:
84 2013-11-08 00:41:57 <michagogo> cloud|abrkn: basically, a little while ago someone pointed a very large amount (relatively) of hashpower at the testnet
85 2013-11-08 00:42:09 <michagogo> cloud|so blocks usually don't get found until the 20 minute rule kicks in
86 2013-11-08 00:42:10 <Evilmax> account, destination wallet and amount
87 2013-11-08 00:42:20 <Evilmax> accounte name, dest wallet, amount
88 2013-11-08 00:42:30 <DonnchaC> Anyone see anything obvious wrong with my tx. I have spent far too long trying to figure this out already :)
89 2013-11-08 00:42:30 <ryan-c> how are you sending that?
90 2013-11-08 00:42:39 <Evilmax> by curl command
91 2013-11-08 00:42:41 <Evilmax> wait
92 2013-11-08 00:42:45 <Evilmax> i will past it there...
93 2013-11-08 00:43:08 <ryan-c> Evilmax: Why curl? bitcoind can issue RPC commands to the server.
94 2013-11-08 00:43:44 <Evilmax> curl -u user:pass -d '{"id":"t0", "method": "sendfrom", "params": ["user","dest wallet","amount"] }' http://ip:8332/
95 2013-11-08 00:43:54 <Evilmax> i need curl
96 2013-11-08 00:44:13 <Evilmax> command are runned from another pc
97 2013-11-08 00:45:34 <ryan-c> Evilmax: what's the user parameter you're using in the command (not auth)?
98 2013-11-08 00:45:45 <ryan-c> It needs to match an account name in your wallet.
99 2013-11-08 00:45:49 <Evilmax> i do not understand
100 2013-11-08 00:45:54 <Evilmax> yes
101 2013-11-08 00:45:58 <Evilmax> it matches
102 2013-11-08 00:46:15 <Evilmax> i wrote user, dest wallet and amount only as example
103 2013-11-08 00:46:23 <ryan-c> Evilmax: Try using bitcoind to issue the command
104 2013-11-08 00:46:30 <Evilmax> ok
105 2013-11-08 00:46:35 <Evilmax> i will try
106 2013-11-08 00:46:39 <Evilmax> let me check
107 2013-11-08 00:47:30 <ryan-c> Evilmax: Why are you trying to use sendfrom, anyway?
108 2013-11-08 00:48:52 <Evilmax> wait please
109 2013-11-08 00:48:57 <Evilmax> just a moment
110 2013-11-08 00:49:21 <Evilmax> sendfrom...because i know only that command
111 2013-11-08 00:49:31 <Evilmax> there is an alternative?
112 2013-11-08 00:50:02 <ryan-c> Depends what you're trying to do... normally sendtoaddress is used.
113 2013-11-08 00:50:03 <Evilmax> sendtoaddress, instead, move all daemon bitcoins
114 2013-11-08 00:50:14 <Evilmax> i need that it moves only bitcoins of an account
115 2013-11-08 00:50:20 <ryan-c> Why?
116 2013-11-08 00:50:27 <Evilmax> because my daemon
117 2013-11-08 00:50:31 <Evilmax> is a service
118 2013-11-08 00:50:36 <Evilmax> not a personal wallet
119 2013-11-08 00:51:47 <Evilmax> ok ryan-c
120 2013-11-08 00:52:14 <Evilmax> by using directly bitcoind command "bitcoinnd sendfrom 'user' 'wallet destination' 'amount' "
121 2013-11-08 00:52:17 <Evilmax> it works!
122 2013-11-08 00:52:31 <Evilmax> so...i have to get it working with curl command too
123 2013-11-08 00:52:51 <ryan-c> Evilmax: What happens if you try to send more than that account is supposed to have?
124 2013-11-08 00:52:55 <Evilmax> first to spend all my coins in network fee for test!
125 2013-11-08 00:53:07 <Evilmax> i get an error
126 2013-11-08 00:53:16 <Evilmax> that means insufficient credit
127 2013-11-08 00:53:24 <Evilmax> result: null
128 2013-11-08 00:53:50 <ryan-c> Evilmax: Also, you appear to be using unencrypted RPC over a network. How can you be sure nobody can intercept the password to the bitcoin daemon?
129 2013-11-08 00:54:01 <DonnchaC> Does anyone have experience creating raw multisig tx's, or were would be the best place to go for help? https://gist.github.com/anonymous/ac6b28a729b595d06c53
130 2013-11-08 00:54:04 <Evilmax> now this is not important
131 2013-11-08 00:54:15 <Evilmax> now i have just to resolve this issue
132 2013-11-08 00:54:23 <Evilmax> later i will think abount security
133 2013-11-08 00:54:46 <ryan-c> Evilmax: You should not be trying to run a service that other people store money in.
134 2013-11-08 00:55:05 <Evilmax> why?
135 2013-11-08 00:55:14 <lianj> whats the faceplam unicode symbol again
136 2013-11-08 00:55:16 <Evilmax> that is my intent :)
137 2013-11-08 00:55:18 <Evilmax> ehehe
138 2013-11-08 00:55:44 <ryan-c> Evilmax: With an "I'll think about security later" attitude you will get hacked. Your users will lose their money.
139 2013-11-08 00:56:00 <Evilmax> first to host the service online
140 2013-11-08 00:56:02 <Evilmax> of course
141 2013-11-08 00:56:03 <kuzetsa> Evilmax: I agree with ryan-c on this
142 2013-11-08 00:56:07 <Zarutian> security much be integral part of you design
143 2013-11-08 00:56:08 <Evilmax> i will fix all security issue
144 2013-11-08 00:56:15 <lianj> m) <- good enough
145 2013-11-08 00:56:16 <Evilmax> but now i ask for this issue
146 2013-11-08 00:56:18 <phantomcircuit> Evilmax, what are you trying to do?
147 2013-11-08 00:56:26 <Evilmax> oh boys
148 2013-11-08 00:56:27 <pigeons> think about security later https://inputs.io/
149 2013-11-08 00:56:27 <ryan-c> Evilmax: Even if you think about security first, you need to hire a security expert (or even more than one) to check your work.
150 2013-11-08 00:56:37 <Evilmax> i am trying to host a btc wallet site
151 2013-11-08 00:56:45 <Zarutian> pigeons: hah! indeed!
152 2013-11-08 00:56:51 <phantomcircuit> pigeons, im not entirely convinced the security was the problem there
153 2013-11-08 00:56:51 <ryan-c> Evilmax: You are not qualified to do so. Do not try.
154 2013-11-08 00:57:16 <lianj> phantomcircuit: true
155 2013-11-08 00:57:16 <pigeons> Evilmax: relevant because they were also a hosted btc wallet site
156 2013-11-08 00:57:28 <lianj> phantomcircuit: at least not own app security per se
157 2013-11-08 00:57:33 <phantomcircuit> although the security was certainly not up to the level he claimed
158 2013-11-08 00:57:36 <Evilmax> ok...anyway i asked for help...not for this
159 2013-11-08 00:57:38 <ryan-c> Evilmax: I'm sorry to be harsh.
160 2013-11-08 00:57:39 <phantomcircuit> api keys as get parameters? wat
161 2013-11-08 00:57:50 <ryan-c> Evilmax: But it's what you need to hear.
162 2013-11-08 00:57:53 <Evilmax> just help me about my question
163 2013-11-08 00:57:58 <Evilmax> if it's possible
164 2013-11-08 00:58:08 <Evilmax> no Ry4an
165 2013-11-08 00:58:10 <Evilmax> ryan-c
166 2013-11-08 00:58:11 <lianj> phantomcircuit: convenience api
167 2013-11-08 00:58:16 <Evilmax> about sendfrom command
168 2013-11-08 00:58:25 <phantomcircuit> lianj, is it really that much harder to use post?
169 2013-11-08 00:58:32 <Evilmax> ok, do not worry
170 2013-11-08 00:58:34 <lianj> phantomcircuit: for some
171 2013-11-08 00:58:38 <Evilmax> i will try by myself
172 2013-11-08 00:58:44 <Evilmax> thank you, anyway :)
173 2013-11-08 00:58:47 <pigeons> what was the likely non-security problem phantomcircuit ?
174 2013-11-08 00:58:49 <ryan-c> Evilmax: Your users will get screwed.
175 2013-11-08 00:59:01 <Evilmax> and sorry my english
176 2013-11-08 00:59:01 <phantomcircuit> pigeons, do you know who TF really is? because i dont
177 2013-11-08 00:59:03 <ryan-c> pigeons: He's implying the hack was staged.
178 2013-11-08 00:59:06 <Evilmax> i am tired to translate
179 2013-11-08 00:59:21 <phantomcircuit> pigeons, "here you go anonymous internet person have my bitcoins, please dont steal them kthx"
180 2013-11-08 00:59:37 <lianj> ryan-c: oh that. maybe too. but we can say that for almost any btc hack
181 2013-11-08 00:59:47 <pigeons> phantomcircuit: i don't know him personally i know of a past scam of his. i see what you mean. i'll take it out of channel
182 2013-11-08 00:59:54 <kuzetsa> as an aside... I think perhaps some users might worry about the morality of a person who uses the name "evil" and doesn't consider security for other people's money a top priority.
183 2013-11-08 01:00:09 <phantomcircuit> kuzetsa, lol...
184 2013-11-08 01:00:20 <kuzetsa> particularly after the "pirate at 40" last year
185 2013-11-08 01:00:31 <gmaxwell> kuzetsa: ppft, it's not like anyone has ever been screwed over by someone named pirate or some guy named nefario.
186 2013-11-08 01:00:40 <lianj> kuzetsa: give me bitcoin i give you more back
187 2013-11-08 01:00:57 <kuzetsa> lianj: fortunately for me, I don't have a bitcoin to risk right now
188 2013-11-08 01:01:08 <kuzetsa> it's all invested in hardware :(
189 2013-11-08 01:01:18 <lianj> m(
190 2013-11-08 01:01:42 <phantomcircuit> gmaxwell, im fairly confident nefario didn't actually screw over anybody
191 2013-11-08 01:02:02 <gmaxwell> Anyone know what the deal is with coinbase randomly "refunding" payments of not-exactly-expected amounts to random prior to addresses apparently inferred from analyizing signatures and prior txouts?
192 2013-11-08 01:02:03 <ryan-c> I have been doing computer security work for a very long time. I would not trust myself to make a web wallet. You have to worry about stuff like "hosting provider hacked with 0day" when you're holding a bunch of bitcoins for people.
193 2013-11-08 01:02:20 <kuzetsa> yeah... I wasn't screwed by nefario... I opted in to having my contact info shared with the security issuer who then made it right :)
194 2013-11-08 01:02:23 <gmaxwell> phantomcircuit: I mean, if nothing else he managed to lose a ton of money via the double payments.
195 2013-11-08 01:02:27 <phantomcircuit> gmaxwell, it's for addresses associated with an invoice i think
196 2013-11-08 01:02:44 <phantomcircuit> gmaxwell, sure but that's nor malicious
197 2013-11-08 01:02:47 <phantomcircuit> not*
198 2013-11-08 01:03:03 <ryan-c> well, seems like 5GB ram is enough to build bitcoind
199 2013-11-08 01:03:25 <pigeons> well mr nefario got some vc money for a uk exchange
200 2013-11-08 01:03:33 <phantomcircuit> ryan-c, you can build with 512mb of ram but only if you do it with -j1
201 2013-11-08 01:03:47 <ryan-c> phantomcircuit: Hmm, I only had -j2
202 2013-11-08 01:03:50 <phantomcircuit> pigeons, except they only can do SEPA transfers like everybody else
203 2013-11-08 01:03:56 <ryan-c> well, it's compiled now
204 2013-11-08 01:04:06 <MC1984> why does it take so much ram to compile a 20mb program
205 2013-11-08 01:04:08 <phantomcircuit> pigeons, i'll be impressed if they can get a uk domestic account
206 2013-11-08 01:04:26 <kuzetsa> ryan-c: were you using the "-pipe" cflag or something? that's way more ram than I've ever used for compile without "-pipe" in my compiler toolchain
207 2013-11-08 01:04:37 <pigeons> i'm impressed with any bitcoin exchange that holds bank accounts
208 2013-11-08 01:04:45 <ryan-c> no, i was using mostly default compile settings.
209 2013-11-08 01:04:49 <warren> TD[away]: gmaxwell: forrestv: sounds like p2pool would benefit from something like: bitcoind validates an insufficient difficulty p2pool share is a valid block (except for the difficulty being insufficient).
210 2013-11-08 01:05:01 <phantomcircuit> pigeons, i'd bet they have an account at bzwbk, which isn't hard unless you really are doing something stupid
211 2013-11-08 01:05:11 <gmaxwell> warren: that may be useful but it doesn't work for old shares.
212 2013-11-08 01:05:12 <ryan-c> just had qt disabled and had the "non-portable-wallet" flag.
213 2013-11-08 01:05:16 <kuzetsa> ryan-c: "default" varies depending on which distro provided your toolchain
214 2013-11-08 01:05:24 <ryan-c> it's ubuntu 13.10
215 2013-11-08 01:05:25 <warren> crap.
216 2013-11-08 01:05:47 <kuzetsa> ACTION shrugs
217 2013-11-08 01:05:48 <phantomcircuit> ryan-c, pretty sure that's pipe
218 2013-11-08 01:05:54 <ryan-c> maybe.
219 2013-11-08 01:05:57 <Evilmax> this is the error
220 2013-11-08 01:06:00 <Evilmax> {"result":null,"error":{"code":-1,"message":"value is type str, expected real"},"id":"t0"}
221 2013-11-08 01:06:04 <Evilmax> what means?
222 2013-11-08 01:06:11 <kuzetsa> I've never tried to run ubuntu (as a desktop, server, development environment, or otherwise)
223 2013-11-08 01:06:26 <Evilmax> with sendfrom
224 2013-11-08 01:06:28 <kuzetsa> I'll take your word for it though that 5GB was enough O_O
225 2013-11-08 01:06:47 <ryan-c> kuzetsa: well, I just added an extra 0 to the existing 512MB in the config.
226 2013-11-08 01:07:10 <sipa> Evilmax: so, you're building a site that will be storing money, on a system you're not confortable with, avoiding trying to understand the security issues?
227 2013-11-08 01:07:14 <kuzetsa> "the config" <-- ooooh, ok, that ... wait, what?
228 2013-11-08 01:07:26 <phantomcircuit> sipa, shh it'll be hilarious
229 2013-11-08 01:07:48 <ryan-c> sipa: Yes, that seems to be what he's doing. I already tried telling him about how screwed his users will be.
230 2013-11-08 01:07:49 <Evilmax> please
231 2013-11-08 01:07:53 <Evilmax> just answer to question
232 2013-11-08 01:07:56 <Evilmax> if you know
233 2013-11-08 01:08:04 <kuzetsa> Evilmax: what question?
234 2013-11-08 01:08:23 <sipa> Evilmax: i know, but no; given these conditions i don't think it's wise to help you
235 2013-11-08 01:08:26 <Evilmax> you like to make judgments at random
236 2013-11-08 01:08:43 <Evilmax> question is: why sendfrom doesn't work
237 2013-11-08 01:08:46 <Evilmax> i get:
238 2013-11-08 01:08:50 <Evilmax> {"result":null,"error":{"code":-1,"message":"value is type str, expected real"},"id":"t0"}
239 2013-11-08 01:08:55 <Evilmax> by using curl
240 2013-11-08 01:08:56 <phantomcircuit> Evilmax, because you have no idea what you're doing
241 2013-11-08 01:09:05 <Evilmax> ok phantomcircuit
242 2013-11-08 01:09:10 <Evilmax> so explain me
243 2013-11-08 01:09:15 <Evilmax> want you help me?
244 2013-11-08 01:09:16 <phantomcircuit> im fairly certain nobody here is going to help you in your endeavor since it's clearly a BadIdea(tm)
245 2013-11-08 01:09:22 <kuzetsa> Evilmax: you're using the syntax wrong... you need to somehow change the data type from string to something numeric
246 2013-11-08 01:09:38 <Evilmax> kuzetsa...the string i am using is:
247 2013-11-08 01:09:40 <michagogo> cloud|Evilmax: 3.14, not "3.14"
248 2013-11-08 01:09:57 <kuzetsa> yeah, what michagogo just said
249 2013-11-08 01:09:59 <Evilmax> curl -u user:pass -d '{"id":"t0", "method": "sendfrom", "params": ["user","dest wallet","amount"] }' http://ip:8332/
250 2013-11-08 01:10:00 <kuzetsa> :)
251 2013-11-08 01:10:13 <Evilmax> how many idiots tonigh
252 2013-11-08 01:10:13 <kuzetsa> make sure "ammount" isn't in quotes
253 2013-11-08 01:10:16 <Evilmax> tonight
254 2013-11-08 01:10:25 <michagogo> cloud|Evilmax: amount needs to be a number
255 2013-11-08 01:10:26 <Evilmax> let me ask, please
256 2013-11-08 01:10:27 <kuzetsa> or spelled with the wrong number of "m"
257 2013-11-08 01:10:33 <Evilmax> yes kuzetsa
258 2013-11-08 01:10:35 <Evilmax> it is a number
259 2013-11-08 01:10:38 <michagogo> cloud|not a string with digits in it
260 2013-11-08 01:10:44 <Evilmax> i did not wrote "amount"
261 2013-11-08 01:10:48 <michagogo> cloud|for example
262 2013-11-08 01:10:49 <Evilmax> amount is just for example
263 2013-11-08 01:11:08 <sipa> yes, but it needs to be amount, not "amount"
264 2013-11-08 01:11:16 <Evilmax> mmmm
265 2013-11-08 01:11:18 <michagogo> cloud|curl -u user:pass -d '{"id":"t0", "method": "sendfrom", "params": ["account","1address",3.14159265] }' http://localhost:8332/
266 2013-11-08 01:11:24 <Evilmax> it is an amount numeric not "amount"
267 2013-11-08 01:11:30 <michagogo> cloud|and not: curl -u user:pass -d '{"id":"t0", "method": "sendfrom", "params": ["account","1address","3.14159265"] }' http://localhost:8332/
268 2013-11-08 01:11:32 <Evilmax> ah ok
269 2013-11-08 01:11:35 <Evilmax> maybe i understand
270 2013-11-08 01:11:43 <kuzetsa> O_O
271 2013-11-08 01:11:44 <Evilmax> what you mean
272 2013-11-08 01:11:49 <Evilmax> it is passed as a php variable
273 2013-11-08 01:11:49 <kuzetsa> I'm washing my hands of this
274 2013-11-08 01:11:55 <Evilmax> to a bash script
275 2013-11-08 01:12:03 <sipa> my god
276 2013-11-08 01:12:04 <michagogo> cloud|(but you still shouldn't try to take other peoples' money with this until you know what you're doing...)
277 2013-11-08 01:12:13 <Evilmax> ehehe
278 2013-11-08 01:12:21 <Evilmax> ok
279 2013-11-08 01:12:22 <sipa> you know there's a JSON-RPC implementation for PHP, right?
280 2013-11-08 01:12:30 <Evilmax> yes, i know
281 2013-11-08 01:12:30 <ryan-c> hey, what if one of your users is called ';rm --no-protect-root -rf /;#?
282 2013-11-08 01:12:37 <sipa> so you can directly send commands instead of forking a shell + curl to do so
283 2013-11-08 01:12:41 <Evilmax> tnx to an user of this chan
284 2013-11-08 01:12:51 <Evilmax> and how?
285 2013-11-08 01:13:14 <Evilmax> all works...just this damnned "sendfrom"
286 2013-11-08 01:13:21 <Evilmax> :)
287 2013-11-08 01:13:32 <sipa> have you thought about backups?
288 2013-11-08 01:13:35 <sipa> cold and hot wallets?
289 2013-11-08 01:13:39 <sipa> security?
290 2013-11-08 01:13:46 <sipa> legal protection?
291 2013-11-08 01:13:49 <Evilmax> again security?
292 2013-11-08 01:13:58 <Evilmax> i have first to build this site
293 2013-11-08 01:14:05 <Evilmax> then i will think abount security
294 2013-11-08 01:14:10 <Evilmax> understand?
295 2013-11-08 01:14:10 <ryan-c> <Evilmax> later i will think abount security
296 2013-11-08 01:14:16 <Evilmax> step...bye step!
297 2013-11-08 01:14:19 <ryan-c> Evilmax: You're an idiot.
298 2013-11-08 01:14:26 <Evilmax> ryan-c go to bed
299 2013-11-08 01:14:32 <Evilmax> this is an help channel
300 2013-11-08 01:14:32 <ryan-c> You have to think about security to start with.
301 2013-11-08 01:14:36 <Evilmax> you are just a troll
302 2013-11-08 01:14:53 <michagogo> cloud|Evilmax: Are you planning to take peoples' money here?
303 2013-11-08 01:15:00 <Evilmax> yesterday a guy gave me a great help
304 2013-11-08 01:15:07 <michagogo> cloud|If so, you *must* start with security from the ground up
305 2013-11-08 01:15:09 <Evilmax> but tonight only trolls
306 2013-11-08 01:15:26 <sipa> Evilmax: we're only trying to help
307 2013-11-08 01:15:36 <Fistful_of_LTC> i have a question about mastercoin: how will my bitcoins be kept seperate from my mastercoin? do i need to create a wallet to keep my mastercoins exclusively ?
308 2013-11-08 01:15:38 <Evilmax> i am not trying nothing
309 2013-11-08 01:15:49 <Evilmax> just to create a wallet for one of my sites
310 2013-11-08 01:15:51 <Fistful_of_LTC> Is that my responsibility to not spend them
311 2013-11-08 01:15:54 <Evilmax> where users move bitcoin
312 2013-11-08 01:16:17 <sipa> Fistful_of_LTC: does a mastercoin client even exist?
313 2013-11-08 01:16:23 <Evilmax> thank you sipa for trying to help me...
314 2013-11-08 01:17:03 <Evilmax> even if it is strange help someone calling him "idiot"
315 2013-11-08 01:17:13 <Fistful_of_LTC> there's a few protocol specs from what i can find... and a few steps to follow to make an actual transaction, it seems you're still using BTC wallets though? but the protocol just informs the exodus address of the transaction
316 2013-11-08 01:17:25 <Evilmax> (ryan-c )
317 2013-11-08 01:17:29 <Fistful_of_LTC> i'm not too clear on it, but i figured maybe someone on here could help me out or know a bit more
318 2013-11-08 01:17:58 <Evilmax> maybe for ryan-c it is more simple call other "idiot" behind a pc
319 2013-11-08 01:18:06 <Evilmax> others
320 2013-11-08 01:18:13 <sipa> can we stop this?
321 2013-11-08 01:18:14 <ryan-c> Evilmax: I'm trying to help prevent you from making something that will blow up in your face.
322 2013-11-08 01:18:19 <Evilmax> ok:)
323 2013-11-08 01:18:22 <Evilmax> it's all!
324 2013-11-08 01:18:28 <Evilmax> sorry my english :)
325 2013-11-08 01:18:52 <Evilmax> -_______-
326 2013-11-08 01:19:02 <kuzetsa> Evilmax: the specific error you were having was because of this --> http://en.wikipedia.org/wiki/String_literal
327 2013-11-08 01:19:08 <kuzetsa> the quote marks in your json messed it up
328 2013-11-08 01:19:14 <Evilmax> i ll take a look kuzetsa
329 2013-11-08 01:19:45 <Evilmax> ok... but first
330 2013-11-08 01:19:46 <pigeons> few more investors and they'll build a wallet
331 2013-11-08 01:19:49 <Evilmax> a break
332 2013-11-08 01:19:53 <Evilmax> i want smoke
333 2013-11-08 01:20:10 <kuzetsa> you instead need this --> http://en.wikipedia.org/wiki/Integer_literal (except... well... a "real" datatype, rather than integer, but the idea is the same)
334 2013-11-08 01:20:14 <Evilmax> my girl...has gone away with another boy
335 2013-11-08 01:20:19 <Evilmax> i am very very unhappy
336 2013-11-08 01:20:22 <Evilmax> friends
337 2013-11-08 01:20:34 <Evilmax> now i see your fb page...full of hearts
338 2013-11-08 01:20:38 <Evilmax> ;(
339 2013-11-08 01:20:55 <Evilmax> i will kill them
340 2013-11-08 01:20:59 <Evilmax> i am sure of this
341 2013-11-08 01:21:10 <Evilmax> i am not a thief...i am a killer
342 2013-11-08 01:21:21 <ryan-c> Well... this got dark.
343 2013-11-08 01:21:27 <warren> sipa: I suggested to the mastercoin people that they find a way to do most things offchain
344 2013-11-08 01:21:34 <kuzetsa> please take this discussion to #mudercoin-dev or something?
345 2013-11-08 01:21:52 <kuzetsa> it's rather off-topic for #bitcoin-dev :(
346 2013-11-08 01:21:54 <sipa> warren: don't think you're the first to do so
347 2013-11-08 01:21:56 <kuzetsa> and upsetting :(
348 2013-11-08 01:22:04 <Fistful_of_LTC> warren: is there a wallet you know of? for mastercoin?
349 2013-11-08 01:22:14 <warren> Fistful_of_LTC: mastercoin is a bad idea
350 2013-11-08 01:22:16 <sipa> Fistful_of_LTC: i hope not
351 2013-11-08 01:22:38 <Fistful_of_LTC> sipa: you guys don't think mastercoin is going to be succesful?
352 2013-11-08 01:22:45 <sipa> i hope not
353 2013-11-08 01:22:53 <pigeons> even if its sucessful it doesnt make it a good idea
354 2013-11-08 01:23:05 <Fistful_of_LTC> because it doesn't use bitcoins features where it should
355 2013-11-08 01:23:10 <Fistful_of_LTC> ?
356 2013-11-08 01:23:26 <Fistful_of_LTC> and it's on top of bitcoin instead of using bitcoin?
357 2013-11-08 01:23:35 <sipa> Fistful_of_LTC: as far as i understand it, it's a badly scaling system that abuses bitcoin as a storage mechanism
358 2013-11-08 01:24:13 <Fistful_of_LTC> sipa: the way i see it it's just TCP to bitcoin's IP... with a bit more redundancy in the way it does things maybe
359 2013-11-08 01:24:58 <sipa> the features it adds are nice, but there's no way afaik to implement them efficiently
360 2013-11-08 01:25:04 <Fistful_of_LTC> but then ... is there a good way to do what it wants to do: decentralized markets? that is actually being developped right now?
361 2013-11-08 01:25:18 <sipa> and it remains abusive to do it on top of bitcoin, rather than say, a merged-mined own chain
362 2013-11-08 01:25:25 <firepacket> Linking bitcoin transactions to other bodys of information is essential. there has to be some small data storage allowed. I mean if you think about it, the whole thing is really data storage anyway
363 2013-11-08 01:25:34 <pigeons> Fistful_of_LTC: look at maaku and jtimon's hard-fork freimarkets for a workable implementation
364 2013-11-08 01:25:47 <sipa> firepacket: bitcoin is _not_ data storage
365 2013-11-08 01:25:57 <firepacket> sure it is
366 2013-11-08 01:26:13 <pigeons> even Alex Mizrahi's colored coins are more workable than this mastercoin stuff
367 2013-11-08 01:26:16 <sipa> firepacket: bitcoin is an incredibly expensive system, where you're forcing every full node to process all your data
368 2013-11-08 01:26:34 <warren> Fistful_of_LTC: would be much cheaper to put mastercoin in a low cost alt chain. Just don't be a parasite to bitcoin. don't care where else it goes.
369 2013-11-08 01:26:35 <Fistful_of_LTC> i like colored coins as well, but is that project actually evolving?
370 2013-11-08 01:26:39 <firepacket> the datastorage part (if labeled correctly) can be ignored by thin clients
371 2013-11-08 01:26:42 <warren> hmm, don't put it on litecoin's chain either
372 2013-11-08 01:26:45 <sipa> firepacket: these nodes choose to do so, because what they get is useful: a decentralized trustless worldwide electronic currency
373 2013-11-08 01:26:47 <Fistful_of_LTC> mastercoin's development strategy seems to be moving it forward
374 2013-11-08 01:27:05 <firepacket> it's that little bit of data storage that takes bitcoin's potential to the next level
375 2013-11-08 01:27:10 <firepacket> it doesn't have to be a lot
376 2013-11-08 01:27:12 <Fistful_of_LTC> (ie bounties heh.)
377 2013-11-08 01:27:25 <sipa> firepacket: if you're going to use bitcoin for other purposes, you are forcing them to do work which they aren't paid for
378 2013-11-08 01:27:29 <pigeons> firepacket: you can't have think clients with mastercoin, you need to index the entire btc blockchain to make sure you havent been doublemastercoin spent
379 2013-11-08 01:27:31 <ryan-c> is there a command to get the testnet chain height?
380 2013-11-08 01:27:32 <sipa> firepacket: and may not care about
381 2013-11-08 01:27:36 <Fistful_of_LTC> sipa: i agree with firepacket, although i also agree minimizing redundancy is essential
382 2013-11-08 01:27:38 <ryan-c> er, for the bot in the channel
383 2013-11-08 01:27:43 <maaku> Fistful_of_LTC: we have a distributed exchange, colored coin, and off-chain solution here : https://bitcointalk.org/index.php?topic=280292.0
384 2013-11-08 01:27:52 <firepacket> it's not really "other purposes" bitcoin is a timestamped transaction system
385 2013-11-08 01:28:01 <firepacket> providing information about the transaction is fully included in its purpose
386 2013-11-08 01:28:06 <sipa> firepacket: i fully disagree
387 2013-11-08 01:28:07 <firepacket> a little extra data stoage does just that
388 2013-11-08 01:28:17 <firepacket> you can disagree :)
389 2013-11-08 01:28:29 <sipa> thankfully
390 2013-11-08 01:28:47 <sipa> bitcoin is a fight with scalability
391 2013-11-08 01:29:07 <ryan-c> ACTION is looking at the testnet block explorer
392 2013-11-08 01:29:10 <firepacket> well we agree there
393 2013-11-08 01:29:22 <sipa> then don't put unnecessary data in it
394 2013-11-08 01:29:24 <ryan-c> his someone intenrionally issuing block exactly every 20 minutes?
395 2013-11-08 01:29:38 <Fistful_of_LTC> sipa: how do you think the available data space in bitcoin 0.9 will be and should be used?
396 2013-11-08 01:29:41 <firepacket> that depends on your definition of necesarry
397 2013-11-08 01:29:48 <maaku> if there wasn't a 25btc subsidy, no one would want to pay the real cost of putting data on the chain
398 2013-11-08 01:29:53 <sipa> Fistful_of_LTC: "available data space" ?
399 2013-11-08 01:30:06 <sipa> Fistful_of_LTC: ah, the OP_RETURN data
400 2013-11-08 01:30:14 <sipa> Fistful_of_LTC: i think it should not be used, but i know it will
401 2013-11-08 01:30:15 <Fistful_of_LTC> ya 8B arbitrary data
402 2013-11-08 01:30:21 <Fistful_of_LTC> lol
403 2013-11-08 01:30:46 <sipa> Fistful_of_LTC: it's there because not having it means people go put data elsewhere, where it hurts the system even more
404 2013-11-08 01:31:09 <sipa> it's really just a way to make abuse hurt less
405 2013-11-08 01:31:19 <firepacket> haha
406 2013-11-08 01:31:26 <sipa> i'm quite serious
407 2013-11-08 01:31:36 <firepacket> it's giving the people what they want and need so they don't abuse another feature to get it
408 2013-11-08 01:31:37 <maaku> assuming those abusers even care enough to use it :\
409 2013-11-08 01:31:40 <firepacket> it's the smartest option
410 2013-11-08 01:31:51 <firepacket> but it's not "abuse"
411 2013-11-08 01:31:59 <Fistful_of_LTC> sipa: either way i like it ;)
412 2013-11-08 01:33:49 <Fistful_of_LTC> sipa: It seems to me it adds to bitcoin's flexibility, being able to use the existing blockchain (and therefore size), to add new features in a manner quite independant of it.
413 2013-11-08 01:34:19 <sipa> Fistful_of_LTC: being able to link transactions to additional data, in a committing way, is useful
414 2013-11-08 01:34:27 <Fistful_of_LTC> yes
415 2013-11-08 01:34:30 <sipa> putting data in it, much less
416 2013-11-08 01:34:32 <Fistful_of_LTC> exactly
417 2013-11-08 01:34:32 <michagogo> cloud|ryan-c: that's the testnet's 20-minute rule
418 2013-11-08 01:34:36 <sipa> there are better ways to do so
419 2013-11-08 01:34:45 <Fistful_of_LTC> well you can link it
420 2013-11-08 01:34:47 <ryan-c> michagogo|cloud: ah, i see.
421 2013-11-08 01:34:52 <michagogo> cloud|ryan-c: If 20 minutes go by without a testnet block, one block is allowed to be mined at difficulty 1
422 2013-11-08 01:35:03 <ryan-c> michagogo|cloud: yeah, i have the testnet wiki article up
423 2013-11-08 01:35:11 <michagogo> cloud|Ah, cool
424 2013-11-08 01:35:26 <firepacket> how can you link a transaction to another body of data without including something in it?
425 2013-11-08 01:35:28 <ryan-c> Was the 20 minute rule a recent addition?
426 2013-11-08 01:35:51 <Fistful_of_LTC> sipa: how?
427 2013-11-08 01:35:56 <sipa> firepacket: that's actually possible, but it requires some crypto tricks
428 2013-11-08 01:35:59 <ryan-c> okay
429 2013-11-08 01:36:08 <ryan-c> that was added in 0.7
430 2013-11-08 01:36:11 <maaku> does anyone know where the Bitcoin GUI settings are stored on Mac OS X?
431 2013-11-08 01:36:26 <maaku> it's more of a Qt question.. they're in the registry in windows
432 2013-11-08 01:36:33 <sipa> firepacket: but that's not what i mean; using OP_RETURN data for putting in a hash of some external data is fine
433 2013-11-08 01:36:38 <Zarutian> ACTION hasnt been quite following along
434 2013-11-08 01:36:41 <firepacket> is there a bip or something I can read?
435 2013-11-08 01:36:49 <Fistful_of_LTC> sipa: can't you just sign the data in the "arbitrary data"
436 2013-11-08 01:36:50 <firepacket> oh
437 2013-11-08 01:37:05 <sipa> firepacket: i'm just worried that it is too easy, and will be abused to actually serve as data storage in the block chain
438 2013-11-08 01:37:21 <Fistful_of_LTC> like put a tinyurl, sign the content, have the hash in the OP_RETURN as well as the tinyurl.
439 2013-11-08 01:37:21 <sipa> (which is, compared to every other alternative, much better)
440 2013-11-08 01:37:28 <Zarutian> sipa: hash that can then be put into barebones magnet uri and fetched by whatever method, yes?
441 2013-11-08 01:37:30 <Fistful_of_LTC> let higher level deal with verification
442 2013-11-08 01:39:13 <firepacket> ultimately though, you can't really stop people from using the blockchain for storage. it's the fee structure that has to protect against this abuse
443 2013-11-08 01:40:01 <Zarutian> what is the current fee structure? linear increase in fee in relation to tx size?
444 2013-11-08 01:40:43 <maaku> found it ~/Library/Preferences/
445 2013-11-08 01:40:46 <sipa> firepacket: fees don't pay those who have to verify, transport and store your data
446 2013-11-08 01:41:52 <Zarutian> should it be expotential fee in relation to tx size?
447 2013-11-08 01:41:54 <Fistful_of_LTC> aside from you two in here
448 2013-11-08 01:41:55 <firepacket> what do you mean?
449 2013-11-08 01:41:59 <firepacket> thats what fees are for
450 2013-11-08 01:41:59 <Zarutian> sipa: indeed.
451 2013-11-08 01:42:02 <Fistful_of_LTC> what's the general consensus on mastercoin?
452 2013-11-08 01:42:13 <sipa> firepacket: i'm running a node
453 2013-11-08 01:42:21 <Evilmax> i have understan
454 2013-11-08 01:42:23 <sipa> firepacket: anything you put in the blockchain ends up on my disk
455 2013-11-08 01:42:24 <Evilmax> understand
456 2013-11-08 01:42:28 <sipa> firepacket: you're not paying me for it
457 2013-11-08 01:42:29 <Evilmax> tnnx michagogo|cloud
458 2013-11-08 01:42:52 <sipa> i run a node, because i consider it useful
459 2013-11-08 01:43:01 <firepacket> thats correct, but nobody is paying you to keep any of thsoe transactions on your disk
460 2013-11-08 01:43:14 <michagogo> cloud|firepacket: Exactly
461 2013-11-08 01:43:16 <sipa> if it's mostly used to store other people's data, rather than build a currency, i'll likely stop running a node
462 2013-11-08 01:43:38 <Fistful_of_LTC> ah
463 2013-11-08 01:43:41 <sipa> if it becomes hard to run a node because of that, bitcoin isn't really decentralized anymore
464 2013-11-08 01:43:47 <Fistful_of_LTC> makes more sense now
465 2013-11-08 01:43:52 <Zarutian> sipa: this is what I didnt understand why satoshi didnt have x block cut off and a fixed reward after some halving
466 2013-11-08 01:44:14 <Fistful_of_LTC> sipa: is there a possibility this OP_RETURN is removed?
467 2013-11-08 01:44:22 <sipa> Fistful_of_LTC: removed?
468 2013-11-08 01:44:33 <Zarutian> (basicly any unspent tx more than x blocks ago are lost)
469 2013-11-08 01:44:36 <Fistful_of_LTC> deprecated in the future, due to what you said above
470 2013-11-08 01:44:57 <sipa> OP_RETURN has existed forever
471 2013-11-08 01:45:09 <sipa> it's just being made standard and relayable now
472 2013-11-08 01:45:17 <sipa> that's a local client policy, not a network rule
473 2013-11-08 01:45:22 <Fistful_of_LTC> ok
474 2013-11-08 01:45:53 <sipa> if it's removed, i'm sure some people would fork the client to re-enable it
475 2013-11-08 01:46:13 <Fistful_of_LTC> motherforkers...
476 2013-11-08 01:46:15 <sipa> and as i said, it's better than the alternatives for data storage
477 2013-11-08 01:46:24 <firepacket> i guess i don't get the logic, if you're willing to store other people's transactions. why not store other people's transactional data?
478 2013-11-08 01:46:37 <sipa> firepacket: ?
479 2013-11-08 01:46:38 <Zarutian> talking about the Scripts spec, can anyone tell me if IF, ELSE and THEN constructs are nestable or not?
480 2013-11-08 01:46:43 <sipa> Zarutian: they are
481 2013-11-08 01:47:05 <sipa> firepacket: it's about what purpose it serves, and what the costs of that are
482 2013-11-08 01:47:06 <firepacket> nevermind lol
483 2013-11-08 01:47:11 <Zarutian> sipa: oh, okay. Suspected they werent. Thanks for clearing that up for me.
484 2013-11-08 01:47:35 <sipa> firepacket: if bitcoin grows faster because people use it for pure data storage, which doesn't help its economy, the cost to benefits factor decreases
485 2013-11-08 01:47:43 <firepacket> it's true, full node maintenance needs to be accessible
486 2013-11-08 01:47:46 <Fistful_of_LTC> alright sina, i see your concern. But it seems to me even if you have other people's data, and even if the blockchain gets to what now seems like a ridiculous size, it may be negigible in the future. And the possibility to have data on it actually offsets the downside of size.
487 2013-11-08 01:48:47 <Zarutian> Fistful_of_LTC: I dont think the question is about storage capacity, more about bandwidth of shuttling the blocks around.
488 2013-11-08 01:48:54 <sipa> and verification
489 2013-11-08 01:49:07 <sipa> and latency degradation because of more data
490 2013-11-08 01:49:26 <sipa> and impact on the UTXO set (which OP_RETURN, compared to other alternatives, doesn't have)
491 2013-11-08 01:50:06 <firepacket> the issue is that the fees don't go to the nodes only the miners
492 2013-11-08 01:50:14 <firepacket> shitty
493 2013-11-08 01:50:15 <sipa> but the most important point is that for most cases (in particular mastercoin, as i understand it), there is no need to have that data in the block chain
494 2013-11-08 01:50:30 <Fistful_of_LTC> ah
495 2013-11-08 01:50:34 <sipa> it can be in a separate chain, merge-mined against bitcoin
496 2013-11-08 01:50:34 <Zarutian> ACTION thought the defacto pattern for including extra data in tx was <extra data> OP_DROP <usual transfer code>
497 2013-11-08 01:50:37 <sipa> which has 0 cost to bitcoin
498 2013-11-08 01:50:59 <sipa> Zarutian: nope, the problem is that that data enters the UTXO set
499 2013-11-08 01:51:07 <sipa> with OP_RETURN transactions that's not the case
500 2013-11-08 01:52:53 <Zarutian> merge-mined? basicly, each block-chain regularly insert into each other a tx that link them to gether via prev-block hashes?
501 2013-11-08 01:52:55 <Fistful_of_LTC> could i make a bet with existing bitcoin transactions?
502 2013-11-08 01:54:11 <sipa> Fistful_of_LTC: not in the same way; i think there are some betting schemes possible in theory though
503 2013-11-08 01:54:14 <firepacket> OP_RETURN makes the whole output unspendable?
504 2013-11-08 01:54:14 <Zarutian> sipa: so an extra TXO that doesnt recive any satoshis contains the extra data then?
505 2013-11-08 01:54:19 <sipa> firepacket: indeed
506 2013-11-08 01:54:25 <sipa> firepacket: _provably_ unspendable
507 2013-11-08 01:54:47 <sipa> Zarutian: merge-mining: putting the hash of the other chain in the coinbase
508 2013-11-08 01:55:18 <Fistful_of_LTC> sipa: Mike hearn speaks of an 'oracle' that can verify if something happened, with smart properties i believe, is that possible right now?
509 2013-11-08 01:55:24 <firepacket> so for every spendable transaction to refrence you propose creating a second to reference the first?
510 2013-11-08 01:55:30 <sipa> Fistful_of_LTC: yes
511 2013-11-08 01:55:43 <Fistful_of_LTC> without adding a layer on top of bitcoin?
512 2013-11-08 01:55:47 <michagogo> cloud|firepacket: Specifically, OP_RETURN *means* "make this output unspendable", so if it's the first byte of the scriptPubKey you, as a node, know that you don't need to remember that transaction
513 2013-11-08 01:56:09 <sipa> Fistful_of_LTC: yes
514 2013-11-08 01:56:29 <sipa> Fistful_of_LTC: talk to TD about that
515 2013-11-08 01:56:36 <firepacket> But that does remove much of the utility of including extra data on a spendable transaction
516 2013-11-08 01:56:46 <sipa> firepacket: how so?
517 2013-11-08 01:57:01 <sipa> it's still in the block chain
518 2013-11-08 01:57:06 <sipa> and travels with the transaction
519 2013-11-08 01:57:12 <sipa> and the transaction provably commits to it
520 2013-11-08 01:57:14 <firepacket> the data doesn't get hashed and verified when the output moves?
521 2013-11-08 01:57:24 <sipa> yes it does
522 2013-11-08 01:57:36 <sipa> it just doesn't enter the database
523 2013-11-08 01:57:47 <sipa> of spendable outputs
524 2013-11-08 01:57:53 <firepacket> okay
525 2013-11-08 01:58:02 <sipa> (which is the most important thing to keep bitcoin block quickly verifiable)
526 2013-11-08 01:58:08 <sipa> it's currently 260 MiB or so
527 2013-11-08 01:58:14 <michagogo> cloud|Hmm, is that sourceforge adware installer something that's opt-in on a per-project basis?
528 2013-11-08 01:58:24 <sipa> michagogo|cloud: it's opt-in, yes
529 2013-11-08 01:58:37 <sipa> but i don't like where sf is going with that
530 2013-11-08 01:58:59 <firepacket> okay, if you use op_return how do you provably link that data with the transaction your refrencing?
531 2013-11-08 01:59:05 <ryan-c> is there a way to do 'bitcoind decoderawtransaction `bitcoind getrawtransaction <txid>`' in one command?
532 2013-11-08 01:59:11 <michagogo> cloud|sipa: Yeah, neither do I
533 2013-11-08 01:59:19 <firepacket> it seems like you can use it to store data, but not to reference a transaction
534 2013-11-08 01:59:24 <michagogo> cloud|ryan-c: `bitcoind getrawtransaction <txid> 1`
535 2013-11-08 01:59:43 <Zarutian> sipa, firepacket: the extra txout is part of the whole tx and because txin refers to the whole tx by hash and index tuple
536 2013-11-08 01:59:54 <michagogo> cloud|sipa: Have you (pl) looked at Github's Releases feature they announced in July?
537 2013-11-08 02:00:01 <ryan-c> michagogo|cloud: Thanks. Wasxn't clear what the verbose flag did there.
538 2013-11-08 02:00:04 <Zarutian> (index as in unsigned positive integer)
539 2013-11-08 02:01:33 <sipa> firepacket: i don't understand what you mean by referencing a transaction?
540 2013-11-08 02:01:45 <sipa> firepacket: you can put a transaction hash in there
541 2013-11-08 02:02:02 <firepacket> that just occured to me
542 2013-11-08 02:02:10 <imton> guys, which port should I open in the server to allow RPC remotely? in my client i am getting "Errno::ECONNREFUSED: Connection refused - connect(2)"
543 2013-11-08 02:02:18 <imton> (my client is ruby)
544 2013-11-08 02:02:24 <sipa> imton: 8332 by default
545 2013-11-08 02:02:51 <imton> sipa: I set another port in the config...
546 2013-11-08 02:02:56 <sipa> then that port
547 2013-11-08 02:02:58 <imton> how can i verify it is working?
548 2013-11-08 02:03:03 <michagogo> cloud|imton: You'll need to set rpcallowip
549 2013-11-08 02:03:03 <Zarutian> side question: is there an unix domain socket option in bitcoind?
550 2013-11-08 02:03:08 <sipa> Zarutian: no
551 2013-11-08 02:03:13 <sipa> imton: connecting to it?
552 2013-11-08 02:03:25 <imton> yup
553 2013-11-08 02:03:26 <sipa> (which seems to be failing for you)
554 2013-11-08 02:03:29 <imton> rpcallowip
555 2013-11-08 02:03:32 <imton> ?
556 2013-11-08 02:03:35 <michagogo> cloud|imton: By default it only accepts connections from localhost
557 2013-11-08 02:03:46 <imton> oh
558 2013-11-08 02:04:08 <michagogo> cloud|add an rpcallowip line to the config file on the daemon with the remote IP address you want to allow
559 2013-11-08 02:04:13 <sipa> michagogo|cloud: if that was the problem, i think he'd get a different error
560 2013-11-08 02:04:17 <imton> well.. my ip is dynamic
561 2013-11-08 02:04:20 <ryan-c> Zarutian: You could use socat to make it available via a domain socket, but I'm guessing you want the socket so you can lock down the permissions.
562 2013-11-08 02:04:23 <michagogo> cloud|Oh, would he?
563 2013-11-08 02:04:35 <Zarutian> ryan-c: exactly
564 2013-11-08 02:04:36 <firepacket> ok the only difference is that you wouldn't be able to find the extra data from a transaction. but you're right, mastercoin doesn't really need that ability
565 2013-11-08 02:04:55 <ryan-c> Zarutian: Would making it require TLS auth help you there?
566 2013-11-08 02:05:06 <imton> I see rpcallowip allows wildcard :)
567 2013-11-08 02:05:12 <firepacket> looking at a spendable transaction, you wouldn't know if there was extra data there without knowing where to look
568 2013-11-08 02:05:29 <sipa> firepacket: sure you would
569 2013-11-08 02:05:33 <firepacket> how?
570 2013-11-08 02:05:34 <sipa> firepacket: it's just be wasteful
571 2013-11-08 02:05:38 <sipa> it's just there...
572 2013-11-08 02:05:48 <sipa> whatever you put in a transaction script remains there
573 2013-11-08 02:05:48 <Zarutian> firepacket: hence my suggestion of letting the external transaction data hash be something that can be stuck into an magnet: uri
574 2013-11-08 02:06:00 <sipa> Zarutian: i don't see the point
575 2013-11-08 02:06:16 <ryan-c> Zarutian: actually, never mind, it doesn't appear to support listing with ssl
576 2013-11-08 02:06:36 <sipa> michagogo|cloud: you'd get http 403 if rpcallowip doesn't match
577 2013-11-08 02:06:40 <ryan-c> https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon
578 2013-11-08 02:06:47 <michagogo> cloud|ah, okay
579 2013-11-08 02:07:11 <Zarutian> ryan-c: not really. Thinking about running bitcoind on an non posix system inside an shim that provides illusion of posix syscall api
580 2013-11-08 02:07:37 <ryan-c> what, like cygwin?
581 2013-11-08 02:08:18 <sipa> firepacket: and OP_RETURN is not an unspendable transaction; it's makes a single output of a transaction unspendable
582 2013-11-08 02:08:18 <Zarutian> sipa: allow the extra/external transaction data to be p2p transfered outside of bitcoin proto
583 2013-11-08 02:08:32 <firepacket> i was just about to say, i get it now
584 2013-11-08 02:08:32 <sipa> Zarutian: getrawtransaction sendrawtransaction
585 2013-11-08 02:08:36 <firepacket> you just make 1 outout op_return
586 2013-11-08 02:08:45 <imton> thank you all, with rpcallowip=* now it is working
587 2013-11-08 02:08:46 <firepacket> cool
588 2013-11-08 02:08:48 <sipa> Zarutian: ah, sorry
589 2013-11-08 02:09:08 <imton> thought i know i shouldn't use that wildcard
590 2013-11-08 02:09:09 <Zarutian> ryan-c: more like in capros domain
591 2013-11-08 02:09:20 <sipa> Zarutian: i mean that you rarely need linking to arbitrary data
592 2013-11-08 02:09:26 <ryan-c> Zarutian: not familiar with that
593 2013-11-08 02:09:44 <sipa> Zarutian: but sure
594 2013-11-08 02:15:43 <firepacket> sipa: is mastercoin not using op_return?
595 2013-11-08 02:16:18 <sipa> firepacket: unsure
596 2013-11-08 02:17:12 <Zarutian> ryan-c: see www.capros.org
597 2013-11-08 02:20:14 <Fistful_of_LTC> firepacket: i think they mention it will allow "Class C mastercoin transactions"
598 2013-11-08 02:20:59 <Fistful_of_LTC> "Add 80 bytes of arbitrary data to each transaction. A way to encode data in the most benign way since outputs are âProvably Prune-ableâ and can safely be ignored when parsing the blockchain."
599 2013-11-08 02:24:43 <firepacket> just read gavins post on op_return. i do get the reluctance but it's really an essential feature imo. i'm glad they are supprting it
600 2013-11-08 02:46:15 <Fistful_of_LTC> firepacket: https://github.com/bitcoin/bitcoin/pull/2738
601 2013-11-08 03:11:32 <dexX7> hello, is there a simple explaination for "TX rejected (code -22)" when sending a rawtx? this is the transaction in question: https://blockchain.info/tx/291860f4d2a247c44676dd8fdc1b1c17804aad25cdaf26e6c621ac6223608369^
602 2013-11-08 03:12:16 <CodeShark> if it's already in the mempool of bitcoind it will be rejected
603 2013-11-08 03:12:42 <CodeShark> since it's been relayed, it stands to reason your node has already seen it and has it in its mempool
604 2013-11-08 03:13:36 <CodeShark> in other words, bitcoind won't allow you to send the same transaction twice
605 2013-11-08 03:14:48 <dexX7> hmm.. it happend on the first try, i sent it then via blockchained.info pushtx
606 2013-11-08 03:15:48 <CodeShark> the other possibility is the fee
607 2013-11-08 03:15:57 <CodeShark> you have three outputs that are smaller than 0.01 btc
608 2013-11-08 03:16:07 <CodeShark> so it requires a relay fee
609 2013-11-08 03:16:39 <CodeShark> other than that the transaction looks totally standard
610 2013-11-08 03:17:16 <dexX7> i used a fee of 0.0002, the tx has a size of 506 byte
611 2013-11-08 03:18:35 <CodeShark> check your node's mempool
612 2013-11-08 03:18:41 <CodeShark> see if it has the transaction
613 2013-11-08 03:18:53 <CodeShark> before it gets confirmed, that is
614 2013-11-08 03:19:27 <CodeShark> if it's not there, then take a look at main.cpp - 711 GetMinFee
615 2013-11-08 03:21:43 <dexX7> thanks
616 2013-11-08 03:22:32 <CodeShark> in the past I've added tracers to bitcoind to help me diagnose transaction errors
617 2013-11-08 03:22:57 <CodeShark> I'm thinking it might not be such a bad idea to at least add compile-time options for it
618 2013-11-08 03:40:59 <CodeShark> oh, apparently your transaction is a doublespend
619 2013-11-08 03:48:36 <dexX7> that was intended, more or less. a similar tx with a slightly higher outgoing amounts and a fee of .0005 was smoothly accepted. thanks for your help. :)
620 2013-11-08 04:13:50 <MC1984> i think #bitcoin is getting raided by pol or something
621 2013-11-08 04:57:12 <dexX7> i found the source of problem. the dust threshold is actually 5460 satoshi instead of 5430.
622 2013-11-08 04:57:30 <BlueMatt> did you find the docs that disagreed with the source? :p
623 2013-11-08 04:57:37 <BlueMatt> gavinandresen: did that just to mess with people
624 2013-11-08 04:58:50 <dexX7> the post about 0.8.2 on the forums as well as https://github.com/bitcoin/bitcoin/pull/2577 mentiones 5430
625 2013-11-08 04:58:56 <BlueMatt> yep
626 2013-11-08 04:59:07 <gavinandresen> one⦠two, Five! â¦Three, sir⦠Three!
627 2013-11-08 04:59:09 <BlueMatt> someone copy/paste mistaked there...
628 2013-11-08 04:59:59 <dexX7> :)
629 2013-11-08 05:01:59 <gavinandresen> if you care about dust threshold 5460 instead of 5430, you're going to be really unhappy with changes I hope to get into the 0.9 release that will make the dust threshold float
630 2013-11-08 05:02:25 <gavinandresen> (float as in change as transaction fees go up/down, not float as in floating-point-format-variable)
631 2013-11-08 05:03:17 <BlueMatt> gavinandresen: I want you to write the bitcoinj spv-mode code that handles fees this time...
632 2013-11-08 05:03:28 <dexX7> it's no big deal, i was just wondering about rejected tx and then surprised when i noticed it
633 2013-11-08 05:03:49 <BlueMatt> https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Wallet.java#3085
634 2013-11-08 05:03:53 <BlueMatt> ^ that wasnt fun
635 2013-11-08 05:04:29 <CodeShark> gavinandresen
636 2013-11-08 05:04:45 <CodeShark> gavinandresen: have you written up something on the formula yet?
637 2013-11-08 05:05:29 <gavinandresen> BlueMatt: I'd have to page-swap Java knowledge back into my brain, and I think my swap partition is starting to fail
638 2013-11-08 05:05:44 <BlueMatt> gavinandresen: heh, well ok that could be a problem
639 2013-11-08 05:06:42 <gavinandresen> CodeShark: formula for dust will be the same as it ever was, it will just be calculated based on the 1%-median fee we've seen recently instead of hard-coded
640 2013-11-08 05:06:54 <gavinandresen> I think, I'm actually rebasing all that code right now....
641 2013-11-08 05:07:08 <CodeShark> by recently seen you're talking about the last n blocks?
642 2013-11-08 05:07:14 <CodeShark> last n blocks and mempool?
643 2013-11-08 05:07:37 <gavinandresen> CodeShark: last 10,000 transactions that were in the mempool and left the mempool by being accepted into a block, to be exact
644 2013-11-08 05:08:11 <gavinandresen> CodeShark: ⦠well, last 10,000 zero-priority, fee-paying if we're talking transaction fees
645 2013-11-08 05:08:24 <CodeShark> are you talking about a sort of moving average?
646 2013-11-08 05:08:31 <gavinandresen> (since we can't really reason about transactions with both priority and fee > 0)
647 2013-11-08 05:08:33 <BlueMatt> nice, relay nodes are seeing more spv checks (ie relays from nodes other than mine) instead of all block relays from my node
648 2013-11-08 05:08:57 <BlueMatt> y'all should keep peering :)
649 2013-11-08 05:09:38 <CodeShark> hmm, why 10,000?
650 2013-11-08 05:10:18 <CodeShark> and why not just use the block chain itself (to make, for instance, SPV client logic simpler)
651 2013-11-08 05:11:21 <gavinandresen> You're right, I'll make it 11,000, that is a better number.
652 2013-11-08 05:11:25 <CodeShark> lol
653 2013-11-08 05:11:54 <gavinandresen> I do have a write-up somewhere that talks about the SPV issue....
654 2013-11-08 05:12:03 <CodeShark> perhaps we should run a few simulations with different n to see what happens
655 2013-11-08 05:13:04 <BlueMatt> CodeShark: no, you cant use the chain
656 2013-11-08 05:13:34 <CodeShark> BlueMatt: why not?
657 2013-11-08 05:13:37 <gavinandresen> CodeShark: knock yourself out. During development, I kept track of estimated fees/priority after various numbers, estimates need a minimum of 100 transactions, 10,000 seems like a reasonable number to keep around
658 2013-11-08 05:13:48 <gavinandresen> CodeShark: https://gist.github.com/gavinandresen/6548612
659 2013-11-08 05:14:00 <BlueMatt> CodeShark: because, evil miners.
660 2013-11-08 05:14:02 <BlueMatt> essentially
661 2013-11-08 05:14:21 <BlueMatt> as the person who will end up writing the bitcoinj client-side fee code, I prefer we dont use blocks :)
662 2013-11-08 05:14:50 <CodeShark> perhaps the simplest SPV client logic of all is to just start at 0, try to send - if it fails, raise it small increments until it succeeds
663 2013-11-08 05:16:25 <CodeShark> or set the minimum based on some hardcoded constants - and then raise incrementally until success
664 2013-11-08 05:18:02 <CodeShark> a slightly more complex approach is to use a random sampling
665 2013-11-08 05:18:16 <BlueMatt> ewwwwww
666 2013-11-08 05:18:24 <BlueMatt> better to ask someone
667 2013-11-08 05:18:50 <CodeShark> you mean add a "getfee" message to the p2p protocol?
668 2013-11-08 05:19:18 <gavinandresen> user experience with any "I'll just re-send the transaction" is awful, especially if the keys are encrypted, and especially on a device like a phone that only connects to catch up and send.
669 2013-11-08 05:20:14 <CodeShark> gavinandresen: multiple transactions with the corresponding fees could be signed at the same time
670 2013-11-08 05:20:19 <gavinandresen> (pre-signing a bunch of variations of the transaction "just in case we need more fees" doesn't work either)
671 2013-11-08 05:20:26 <CodeShark> and then the sending could be done in the background without requiring the key
672 2013-11-08 05:20:38 <gavinandresen> ⦠because you'll just end up locking inputs that the user might want to spend, and that sucks
673 2013-11-08 05:21:22 <CodeShark> well, the idea is that one of the presigned transactions will work
674 2013-11-08 05:21:32 <CodeShark> so the inputs aren't locked up
675 2013-11-08 05:22:05 <CodeShark> you could add a change output to control the fee
676 2013-11-08 05:22:08 <gavinandresen> you've got two inputs in your wallet: 1BTC and 50BTC. Now you send 1BTC. What happens?
677 2013-11-08 05:22:12 <BlueMatt> what about hardware wallets...
678 2013-11-08 05:22:22 <BlueMatt> really, you have to ask someone
679 2013-11-08 05:22:24 <BlueMatt> p2p or otherwise
680 2013-11-08 05:22:26 <BlueMatt> probably both
681 2013-11-08 05:23:34 <CodeShark> gavinandresen: if the wallet is designed such that you control the fee with a change output, you'd use both the 1BTC and 50BTC inputs for all the versions
682 2013-11-08 05:23:58 <CodeShark> it does add a small cost of an extra input in the case that no fee is required
683 2013-11-08 05:24:42 <BlueMatt> plus signing txn can get /very/ expensive
684 2013-11-08 05:24:44 <gavinandresen> CodeShark: right, so 49.something BTC are locked up and cannot be spent for some amount of time because you don't know WHICH change output will end up being used
685 2013-11-08 05:24:50 <BlueMatt> just go look at the code fragment I linked above in bitcoinj's wallet
686 2013-11-08 05:24:54 <gavinandresen> That sucks as a user experience
687 2013-11-08 05:25:01 <BlueMatt> its /ugly/
688 2013-11-08 05:25:14 <CodeShark> signing txn can get very expensive?!?!? it takes milliseconds on typical hardware
689 2013-11-08 05:25:26 <CodeShark> I've even managed to sign on an 8 bit processor in a few seconds :p
690 2013-11-08 05:26:23 <gavinandresen> CodeShark: okey dokey. this is the point where I say "patches welcome", and start ignoring you
691 2013-11-08 05:26:38 <CodeShark> gavinandresen: I was just about to say you had a point - no need for rudeness :)
692 2013-11-08 05:27:34 <BlueMatt> except you arent signing one transaction, you're signing a bunch of inputs
693 2013-11-08 05:27:37 <BlueMatt> on an old android phone
694 2013-11-08 05:27:44 <BlueMatt> with the signing done in...java
695 2013-11-08 05:27:47 <BlueMatt> using BigIntegers
696 2013-11-08 05:27:50 <BlueMatt> which are immutable
697 2013-11-08 05:28:20 <CodeShark> I have a secp256k1 implementation for android java that can perform point multiplication in milliseconds
698 2013-11-08 05:29:02 <CodeShark> signing can be highly optimized by using precomputed tables
699 2013-11-08 05:29:02 <CodeShark> verification is much more expensive than signing
700 2013-11-08 05:29:51 <CodeShark> I don't think performance is the real issue - although usability most certainly is
701 2013-11-08 05:40:23 <CodeShark> BlueMatt: In case you're interested, http://pastebin.com/umK1TQ5P
702 2013-11-08 05:41:56 <CodeShark> and that's without any precomputed tables
703 2013-11-08 05:41:58 <BlueMatt> CodeShark: yea, Ive written a highly-optimized secp256k1 impl in java before
704 2013-11-08 05:42:06 <BlueMatt> with like 10 different versions with/without tables
705 2013-11-08 05:42:10 <BlueMatt> and different multiplication methods
706 2013-11-08 05:42:26 <BlueMatt> and they were all slow as fuck, so I gave up and implemented jni bindings for sipa's secp256k1 library
707 2013-11-08 05:42:40 <BlueMatt> well, faster than bouncycastle by a lot, but waay slower than native
708 2013-11-08 05:42:40 <CodeShark> well, of course you're not going to beat natively-compiled C
709 2013-11-08 05:43:11 <CodeShark> in any case, the important optimization application for sipa's library is verification, not signing
710 2013-11-08 05:43:21 <CodeShark> for verification it can make a HUGE difference
711 2013-11-08 05:43:26 <BlueMatt> yes, but its not slow at signing ;)
712 2013-11-08 05:44:09 <CodeShark> right - point is, signing is less resource-intensive inherently and is done much less frequently (at least in terms of real-world bitcoin applications)
713 2013-11-08 05:44:59 <CodeShark> and unless you're using an extremely slow processor performance is probably not a significant issue
714 2013-11-08 05:49:56 <CodeShark> even if it takes on the order of a second for most users it's probably tolerable
715 2013-11-08 05:50:25 <CodeShark> I mean. on the order of a second to do all the signing
716 2013-11-08 05:50:50 <CodeShark> network latency and confirmation times are bigger annoyances
717 2013-11-08 05:56:50 <CodeShark> intermittent network and variable quality of peers/peer selection are much thornier issues to solve
718 2013-11-08 06:06:06 <CodeShark> I'm also thinking that the "evil miner" issue might be somewhat mitigated by removing outlier transactions from blocks in the calculation
719 2013-11-08 06:07:26 <CodeShark> if the mean of fees for transactions in the last n blocks is 0.0005 but a bunch of transactions also have fees that are much higher, you exclude those
720 2013-11-08 06:09:25 <CodeShark> having to maintain a mempool and check when transactions make it into blocks is the REAL complication in the algorithm here
721 2013-11-08 06:09:52 <CodeShark> that's where small devices simply will fail
722 2013-11-08 06:15:38 <CodeShark> so that seems to leave two alternatives in implementing an SPV client - either add a way to ask for fee estimates in the p2p protocol itselfâ¦or use trial and error until the transaction propagates
723 2013-11-08 06:16:26 <Luke-Jr> CodeShark: or let miners advertise their fee policy
724 2013-11-08 06:17:00 <Luke-Jr> could easily stick a pubkeyhash in blocks the miner can use to sign policy broadcast scripts with
725 2013-11-08 06:17:02 <CodeShark> Luke-Jr: there are two separate issues here - miner fee policy and relay policy
726 2013-11-08 06:17:08 <Luke-Jr> true
727 2013-11-08 06:17:18 <Luke-Jr> relay trial and error is pretty simple though
728 2013-11-08 06:17:29 <Luke-Jr> retry every minute until it comes back
729 2013-11-08 06:18:54 <CodeShark> would be nice if the protocol allowed fees paid for relay and not just mining :)
730 2013-11-08 06:20:07 <CodeShark> there are only at best highly indirect economic incentives for full nodes to accept SPV client connections
731 2013-11-08 06:20:46 <Luke-Jr> trivial to add a "pay to use" to the protocol :P
732 2013-11-08 06:22:38 <Luke-Jr> especially when/if we get debt-transactions
733 2013-11-08 06:26:52 <CodeShark> it would be wonderful to separate the two fee types completely
734 2013-11-08 06:27:13 <CodeShark> then a relay node can set its own relay policy just as arbitrarily as a miner can
735 2013-11-08 06:28:05 <CodeShark> it would create incentives to set up dedicated relay servers for thin clients
736 2013-11-08 06:28:36 <CodeShark> while still maintaining decentralization
737 2013-11-08 06:29:19 <CodeShark> furthermore, it doesn't really make economic sense for the relay nodes to be defining their policy based on what miners accept
738 2013-11-08 06:30:10 <CodeShark> a relay node cares about its own resource utilization primarily - and the speed/efficiency of the network as a whole secondarily
739 2013-11-08 06:30:22 <imton> how'd the protocol force senders to pay to the relay-er?
740 2013-11-08 06:31:10 <CodeShark> the relayer could require an output they provide to be in the transaction
741 2013-11-08 06:31:43 <CodeShark> however, this only seems to make sense if the relayer is directly connected to the miners
742 2013-11-08 06:32:13 <CodeShark> once you're more than two steps removed it gets much more complicated
743 2013-11-08 06:32:22 <Eneerge> any of you done much firefox addon development? Anyone know how to detect when one of the firefox error pages is shown. EG: no cipher overlap, 404 errors, etc. I think those are chrome pages.... I have it intercepting all connections before they occur and I can get the response if the connection was successful, but if any chrome page loads, no event is thrown that i'm aware of
744 2013-11-08 06:33:42 <imton> why does it only makes sense if the relayer is directly connected to the miners only?
745 2013-11-08 06:33:58 <CodeShark> if you require an additional hop, how does that node get paid?
746 2013-11-08 06:34:26 <CodeShark> if a transaction takes multiple paths to the miner, each version will also be different
747 2013-11-08 06:35:02 <imton> right
748 2013-11-08 06:35:09 <imton> we always want the shortest path
749 2013-11-08 06:35:16 <CodeShark> I suppose you could pay a relay node up front to process so many messages or whatever
750 2013-11-08 06:35:51 <CodeShark> hub nodes could get wholesale pricing or even free direct connections to miners
751 2013-11-08 06:36:25 <CodeShark> but then you need proof that the node actually relayed the transaction
752 2013-11-08 06:36:40 <CodeShark> and to what peers - etc...
753 2013-11-08 06:40:36 <CodeShark> perhaps we'll just end up getting a few commercial services that offer fast relay with high availability for a fee
754 2013-11-08 06:41:31 <CodeShark> and all these things can be negotiated over some higher level protocol
755 2013-11-08 08:04:21 <last1> anyone using eloipool ? I set it up and mined for quite a bit at roughly 60/65 ghs. submitted about 16 million shares but got no coins
756 2013-11-08 08:04:26 <last1> is this normal / to be expected ?
757 2013-11-08 08:05:23 <Luke-Jr> last1: yes, any further belongs in #bitcoin-mining really
758 2013-11-08 08:06:16 <last1> k, I thought it might be an issue with eloipool
759 2013-11-08 08:33:50 <imton> guys, I am using sipa's watch-only
760 2013-11-08 08:34:07 <imton> I have been a month without off bitcoin world
761 2013-11-08 08:34:20 <imton> I can't remember the API call to get all tx related to an address
762 2013-11-08 08:34:27 <imton> *txs
763 2013-11-08 08:36:42 <sipa> there isn't one
764 2013-11-08 08:37:25 <sipa> you have listtransactions, which works per account
765 2013-11-08 08:37:37 <sipa> listunspent maybe
766 2013-11-08 08:37:50 <imton> mmm... I will be handling wallet outside bitcoind for my users
767 2013-11-08 08:38:55 <imton> I mean.. which is the closest call to your "searchrawtransactions" call in the other branch
768 2013-11-08 08:45:53 <shripadk> hey guys :)
769 2013-11-08 08:48:12 <shripadk> if i send to two multisig addresses (one is 2-of-3 and the other 2-of-2) in a single transaction, can the amount be redeemed? does the limit of 520 byte scriptPubKey and 500 byte scriptSigs cause any problems?
770 2013-11-08 08:48:25 <imton> sipa: in fact i am porting my code from searchrawtransactions call to watch-only
771 2013-11-08 08:50:38 <sipa> listtransactions
772 2013-11-08 08:52:35 <imton> sipa: that's for accounts... should I add a new account for each address I import?
773 2013-11-08 08:53:05 <shripadk> also while redeeming the amount, how do i decide the amount of fee that needs to be included? the only input is the multisig address (via txid + scriptPubKey + redeemScript) and the only output will be the recipient address. will it always be 0.0001btc even for large amounts?
774 2013-11-08 08:53:49 <sipa> imton: what is your use case?
775 2013-11-08 08:54:26 <imton> sipa: let's say online exchange/escrow service
776 2013-11-08 08:57:30 <sipa> imton: you have some database where you keep each user's balance?
777 2013-11-08 08:58:25 <imton> it was a a cache that was updated according to the user wallet, yes
778 2013-11-08 08:58:34 <sipa> ok
779 2013-11-08 08:59:00 <sipa> so just use listtransactions, and see if you see any new receives since the previous call
780 2013-11-08 08:59:21 <imton> ok but how about account handling?
781 2013-11-08 08:59:25 <sipa> and then credit the balance of the users those addresses belong to
782 2013-11-08 08:59:28 <imton> should I use 1 account only?
783 2013-11-08 08:59:37 <sipa> forget about accounts
784 2013-11-08 09:00:06 <sipa> they're only useful if you'd do all handling inside bitcoin
785 2013-11-08 09:00:17 <sipa> and have many issues in that case
786 2013-11-08 09:00:19 <imton> oh, I see , you want me to use this " If [account] not provided will return recent transaction from all accounts."
787 2013-11-08 09:00:24 <imton> right?
788 2013-11-08 09:00:47 <sipa> you can specify account "*" explicitly
789 2013-11-08 09:01:12 <HaltingState> my hardware bitcoin wallet is going to be laser cut anodized aluminum; this is going to look awesome http://i.imgur.com/eUDL3oQ.jpg
790 2013-11-08 09:01:12 <sipa> which means everything
791 2013-11-08 09:01:25 <imton> sipa: great. And do i see both received and spent transactions with listtransactions right?
792 2013-11-08 09:01:51 <sipa> imton: you shouldn't care about spends imho
793 2013-11-08 09:02:05 <sipa> imton: you know when you're sending coins, no?
794 2013-11-08 09:02:24 <imton> sipa: I should. Yes.
795 2013-11-08 09:02:49 <imton> sipa: but I want to know if I can rely on "listtransactions" for everything related to addresses
796 2013-11-08 09:02:49 <sipa> this is for a cold/hot wallet solution, right?
797 2013-11-08 09:03:27 <sipa> or for a system where the wallet is not yours?
798 2013-11-08 09:03:43 <imton> sipa: cold/hot wallet
799 2013-11-08 09:03:58 <imton> well.. no, sorry.
800 2013-11-08 09:04:10 <imton> I mean, is a service for people
801 2013-11-08 09:04:31 <sipa> yes, but is the actual spending wallet yours or theirs?
802 2013-11-08 09:04:43 <sipa> i mean, who has the actual private keys
803 2013-11-08 09:05:09 <imton> Well right now we do, but I am rethinking it to they
804 2013-11-08 09:05:24 <imton> so they are encrypted locally (kind of blockchain wallet)
805 2013-11-08 09:05:43 <imton> it's not lunched yet so, i have time to do it right
806 2013-11-08 09:06:27 <sipa> so, listtransactions will report both sends and receives
807 2013-11-08 09:07:02 <sipa> but if the spends are from a waller you don't control, you can't rely on sends being interpreted correctly
808 2013-11-08 09:07:07 <imton> I just don't want to rely on blockchain.info webapi service, I want to host my own blockchain locally
809 2013-11-08 09:07:58 <sipa> if you just need the balance of someone's wallet, you can tally up receives minus sends of course
810 2013-11-08 09:08:27 <sipa> though in that case it may actually make sense to use the accounts system, and use an account per user
811 2013-11-08 09:08:37 <imton> sipa: in the case another wallet i don't control spends the same txout, will I see it with listtransactions?
812 2013-11-08 09:08:57 <imton> sipa: yes, 1 account for each user may be a little more organized.
813 2013-11-08 09:08:58 <sipa> yes
814 2013-11-08 09:09:10 <imton> sipa: great
815 2013-11-08 09:09:25 <sipa> but you are aware that you'll need to know about the user's wallet
816 2013-11-08 09:09:37 <imton> yes
817 2013-11-08 09:09:40 <sipa> every time a new key gets used, you'll need to know it in advance
818 2013-11-08 09:10:02 <imton> oh, you are right
819 2013-11-08 09:10:10 <sipa> which really requires deterministic wallets to do right
820 2013-11-08 09:10:55 <imton> ok, then I think the most similar thing to searchrawtransactions would be using one account only
821 2013-11-08 09:11:18 <sipa> this is independent from how you implement things
822 2013-11-08 09:11:35 <sipa> you need to know of every key in the wallet before it gets used
823 2013-11-08 09:13:07 <imton> great
824 2013-11-08 09:13:12 <sipa> which works if it's your own wallet of course
825 2013-11-08 09:13:27 <sipa> but i don't see how you'd do it for other people's wallets
826 2013-11-08 09:13:37 <sipa> without deterministic wallets
827 2013-11-08 09:14:25 <imton> I am reading about deterministic wallets
828 2013-11-08 09:14:33 <imton> never heard of them before
829 2013-11-08 09:14:44 <sipa> it's just about this problem
830 2013-11-08 09:14:53 <sipa> every time a user does a transaction
831 2013-11-08 09:15:07 <sipa> change goes to a new freshly-generated address of his
832 2013-11-08 09:15:19 <sipa> you need to know about this change address in advance
833 2013-11-08 09:15:58 <sipa> because otherwise you cannot know that this is a send-to-self output, rather than coins that left the wallet
834 2013-11-08 09:16:26 <imton> but I can generate a new address at the time a tx is made for the change, right?
835 2013-11-08 09:16:40 <imton> or use one from a pool of pre-generated
836 2013-11-08 09:16:40 <sipa> if it is your wallet, sure
837 2013-11-08 09:17:06 <imton> I don't get what is the problem if it is other people's wallet...
838 2013-11-08 09:17:24 <sipa> you cannot know an address that they don't have yet