1 2014-07-12 01:26:10 <cronus> why is my .bitcoin directory over 40G when the blockchain is supposedly ~21G?
  2 2014-07-12 01:29:25 <jcorgan> can't you just look at what files are taking up space?
  3 2014-07-12 01:30:39 <cronus> oh i have a bootstrap.dat.old lingering.. can I delete this?
  4 2014-07-12 01:42:34 <buZz> yes
  5 2014-07-12 01:57:16 <cronus> uhh bitcoind was using ~50% of my ram on my vps (~1GB of 2GB) so I upgraded to a 4GB machine and now its using ~50% of that at 2GB..what’s going on? Why does its memory usage scale with what’s available..can I not limit it?
  6 2014-07-12 01:57:57 <CodeShark> limit the number of connections
  7 2014-07-12 03:09:51 <sipa> phantomcircuit: we do
  8 2014-07-12 03:10:41 <phantomcircuit> sipa, ignoring the failure and breaking isn't exactly what i meant
  9 2014-07-12 03:25:56 <sipa> what failure?
 10 2014-07-12 03:28:01 <phantomcircuit> sipa, if send only transmits half of the buffer, currently that's used as a signal to stop trying to call send() but the partial message isn't retransmitted afaict
 11 2014-07-12 03:31:32 <sipa> eh yes it i
 12 2014-07-12 03:31:38 <sipa> s
 13 2014-07-12 03:32:27 <sipa> we just remember the offset in the send buffer
 14 2014-07-12 03:32:44 <sipa> which is updated when bytes are sent
 15 2014-07-12 04:16:45 <cronus> with importaddress, I supply address in 1xxx format? and what does rescan do? check for any transactions involving the address?
 16 2014-07-12 04:22:07 <Luke-Jr> importaddress, despite its name, adds transactions unrelated to the address too; it's really just a hacky way to do a watch-only wallet
 17 2014-07-12 04:23:19 <cronus> what do you mean adds transactions unrelated to the address
 18 2014-07-12 04:24:54 <Luke-Jr> cronus: you'll see all the transactions to the address, but you'll also see unrelated transactions going out
 19 2014-07-12 04:25:47 <cronus> hm dont follow, where will I see these other transactions?
 20 2014-07-12 04:25:51 <Luke-Jr> in the wallet
 21 2014-07-12 04:26:38 <cronus> my plan is to use importaddress to add each address I use for an order and then notifywallet in my conf as a callback to know when one of my order addresses received a transaction
 22 2014-07-12 04:27:34 <Luke-Jr> just be aware you'll also get unrelated transactions in there too
 23 2014-07-12 04:27:34 <Luke-Jr> sure, that should work
 24 2014-07-12 04:27:34 <Luke-Jr> you can just ignore those
 25 2014-07-12 04:27:35 <Luke-Jr> unfortunately, there's no way to simply watch *just* the address (yet?)
 26 2014-07-12 04:27:48 <cronus> so you’re saying my notifywallet will go off for transactions on addresses that I’m not explicitly even watching?
 27 2014-07-12 04:27:57 <Luke-Jr> yes
 28 2014-07-12 04:28:03 <cronus> weird.
 29 2014-07-12 04:28:43 <cronus> well thanks for the heads up..would have been banging my head on that one
 30 2014-07-12 04:28:43 <Luke-Jr> basically some (but not all) transactions sent FROM the wallet which the address in question is a part of
 31 2014-07-12 04:30:42 <cronus> oh well i wont be sending any transactions from any of the addresses in my wallet
 32 2014-07-12 04:30:48 <cronus> so guess it wont be a real issue
 33 2014-07-12 04:31:05 <Luke-Jr> you never send transactions from addresses, only to.
 34 2014-07-12 04:31:39 <cronus> ok from the wallet that holds my addresses
 35 2014-07-12 04:31:53 <Luke-Jr> so you're just going to save them forever? :P
 36 2014-07-12 04:31:58 <cronus> yes lol
 37 2014-07-12 04:32:03 <cronus> well
 38 2014-07-12 04:32:05 <cronus> fine
 39 2014-07-12 04:32:09 <cronus> i guess some day maybe ill move them
 40 2014-07-12 04:32:18 <cronus> but yeah its basically going straight into cold storage
 41 2014-07-12 05:09:30 <jcorgan> sipa: fyi, i just benchmarked secp256k1_ecdsa_create_pubkey at 19.5K/sec on a single core Xeon, and was able to parallelize it up to 200K/sec on a 12 core
 42 2014-07-12 05:27:30 <iwilcox> Does -keypool make any sense without wallet support?  In the commandline usage blurb its doc line isn't wrapped in #ifdef ENABLE_WALLET.
 43 2014-07-12 05:30:47 <gmaxwell> iwilcox: brillant, please submit a pull req fixing this!
 44 2014-07-12 05:33:44 <gmaxwell> iwilcox: actually you should also move it to the wallet section (be sure nothing else in the help text uses it)
 45 2014-07-12 05:33:54 <gmaxwell> also -gen requires the wallet.
 46 2014-07-12 05:35:00 <iwilcox> Presumably genproclimit too then
 47 2014-07-12 05:35:32 <gmaxwell> yep. (mining works, just not the internal miner)
 48 2014-07-12 05:50:57 <iwilcox> While I'm on pedantic little cleanups, in createrawtransaction's docs, redeemScript is listed as required; I've certainly seen cases where bitcoind was happy for me to omit it, and indeed https://bitcoin.org/en/developer-examples#offline-signing shows it being used without redeemScript.
 49 2014-07-12 05:51:09 <iwilcox> When is it needed?  Would it be clearer to say "optional"?
 50 2014-07-12 05:51:29 <iwilcox> Sorry, signrawtransaction
 51 2014-07-12 05:52:26 <jcorgan> sipa: i'd like to use libsecp256k1 to do some general purpose EC math (such as is used in BIP32 child-key derivation).  It looks like you have all the functions needed prototyped in ecmult.h and num.h, but these aren't exported.
 52 2014-07-12 06:36:42 <TYDIRocks> Hello I'm making a small client just for fun. I'm using HD keys. I should be storing the public keys with the address right/
 53 2014-07-12 06:37:36 <shesek> TYDIRocks, the address can be derived from the public key, there's no need to store both of them
 54 2014-07-12 06:37:53 <shesek> (the public key, however, cannot be derived from the address)
 55 2014-07-12 06:37:56 <TYDIRocks> True, not sure why I didn't think of that...thanks
 56 2014-07-12 06:38:05 <shesek> though, if you're using HD keys, you shouldn't really need to store public keys either
 57 2014-07-12 06:38:20 <shesek> just the master private/public key
 58 2014-07-12 06:38:33 <TYDIRocks> Well I'm making it so they can use multisigs
 59 2014-07-12 06:38:34 <shesek> and possibly the chain codes, if they're not deterministic
 60 2014-07-12 06:38:39 <TYDIRocks> Should I just be storing the IDs then?
 61 2014-07-12 06:39:08 <shesek> generally speaking, you should be storing the minimum amount of information that's needed to compute whatever you need when you need it
 62 2014-07-12 06:41:13 <TYDIRocks> Okay thanks. I think I'll store the IDs. I'll have to see how this API's wallet variable works.
 63 2014-07-12 06:44:13 <TYDIRocks> How does the QT work thought where you input the address and it signs the message?
 64 2014-07-12 06:44:22 <TYDIRocks> If the addresses aren't stored with the public keys
 65 2014-07-12 06:44:40 <TYDIRocks> Wait I just...nvm
 66 2014-07-12 06:44:45 <TYDIRocks> Getting late haha
 67 2014-07-12 06:49:07 <TYDIRocks> Actually yes how do they sign a message just from putting the Bitcoin address in? Would I need to run through the IDs and see which ID corresponds to that address?
 68 2014-07-12 13:26:32 <sipa> jcorgan: so, no inyernal data structures are exposed in the public api (because they're implementation and architecture defined), and i'd like to keep it that way
 69 2014-07-12 13:27:14 <sipa> jcorgan: though you can already do much
 70 2014-07-12 13:27:55 <sipa> jcorgan: for bip32, everything is already there (see the tweak_add function)
 71 2014-07-12 13:34:06 <jcorgan> thanks, i'll look into it.
 72 2014-07-12 14:04:31 <buzio> hi guys.  super-quick question: are transaction amounts hidden in the blockchain, through various methods (e.g. splitting up the transaction into random amounts, etc).  Or, if I know that A is planning to pay B exactly 3.1415926 btc, can I just watch the blockchain and instantly know when that transaction has taken place? (if the parties use normal wallet software)
 73 2014-07-12 14:05:56 <buzio> "buzio: if there exists only one transaction of 3.1415926 btc recently, yes"
 74 2014-07-12 14:06:24 <CodeShark> the transaction amounts are completely transparent in the block chain
 75 2014-07-12 14:06:44 <buzio> CodeShark (btw I'm the same person as Ninja-something, I was on before).  I then have an important suggestion:
 76 2014-07-12 14:06:53 <CodeShark> however, by sending change outputs you can slightly complicate the analysis (but only slightly)
 77 2014-07-12 14:06:55 <buzio> I think this information should NOT be leaked.  It's quite informative, for an anonymous network.
 78 2014-07-12 14:07:09 <buzio> So, I have an important architectural suggesteed addition to bitcoin:
 79 2014-07-12 14:07:43 <buzio> In the future, you should be able to use the network to request new addresses from someone, knowing only their address.  You should then be able to send to a list of new addresses, splitting the amount up into random amounts.
 80 2014-07-12 14:08:13 <buzio> This would be a very good step toward anonymizing transactions.  It would also defeat a lot of the mining of the blockchain that people already do today, quite idly.
 81 2014-07-12 14:08:21 <buzio> I meant datamining
 82 2014-07-12 14:08:30 <CodeShark> it seems the only complete solution to this problem will most likely involve zero-knowledge proofs of some form or another
 83 2014-07-12 14:08:47 <CodeShark> but unfortunately the state of crypto technology isn't quite there yet
 84 2014-07-12 14:09:11 <buzio> CodeShark, why?  What's wrong with the obvious solution of just asking for some new (fresh) addresses, securely exchanged?  There is no way for anyone to know that the 5 addresses you've sent to are in fact just received by yourself a moment ago in response to your query.
 85 2014-07-12 14:09:30 <buzio> it could just as easily be 5 addresses you already knew about.
 86 2014-07-12 14:09:34 <CodeShark> you'll have to gather your funds up sooner or later
 87 2014-07-12 14:09:43 <CodeShark> and that will allow an eavesdropper to piece together your wallet
 88 2014-07-12 14:10:21 <buzio> granted, codeshark, but it's a far cry from being instantly told of the size of every transaction.  Plus, the more data going through the network, the harder it is to piece anything together.
 89 2014-07-12 14:10:47 <buzio> something as simple as delaying "gathering up the money" on the recipient side, into a number of transactions over 1 hour, would make it quite difficult to correlate.
 90 2014-07-12 14:10:57 <CodeShark> unless you are mixing coins (as in having many parties participate in the same transaction such that an eavesdropper cannot associate the inputs with the outputs) there's no real way to prevent an eavesdropper from associating your addresses
 91 2014-07-12 14:11:25 <otila> well there are ring signatures https://cryptonote.org/inside.php
 92 2014-07-12 14:11:28 <CodeShark> but a truly decentralized p2p coin mixing protocol is a bit of a challenge
 93 2014-07-12 14:11:41 <buzio> I mean, imagine the recipient keeps the received 3.141592 bitcoins in the 5x addresses.  When they next spend 3 bitcoins, if they NEED to do so from those recipient addresses (don't have any other money fro example) they can still just do so over the course of an hour.  It's quite hard to correlate.  Even, could be over the course of 2 days.
 94 2014-07-12 14:12:11 <earlz> money must come from somewhere,and end up somewhere else. pretty difficult to make that perfectly anonymous
 95 2014-07-12 14:12:33 <buzio> CodeShark - if you take 3 days to send from an address, then the only association between the 5 addresses (or maybe even 2 of them) is that "they received money within 1 hour of each other, sent money within 1 day of each other", for example....
 96 2014-07-12 14:13:00 <CodeShark> the inconveniences involved in such a protocol probably outweigh most of the potential benefits for most people
 97 2014-07-12 14:13:18 <buzio> earlz - I don't know.  It could be not-that-difficult, if it is difficult to associate a number of addresses as belonging to the same person.  I think a lot of people would be fine with wallet software taking 1-3 days to finish sending, e.g. tens of thousands of dollars, through the network.
 98 2014-07-12 14:13:46 <buzio> They could much prefer the amount being split up into various addresses, rather than just sent as 1 transaction.
 99 2014-07-12 14:14:22 <buzio> CodeShark, I just consider it hilarious that an 'anonymous' crypto currency network, in fact transmits the exact time and amount of any transaction by any of its users.  A bit funny :)
100 2014-07-12 14:14:23 <earlz> I tend to think that remaining anonymous isn't hard with proper precautions at the border of the network like mining and exchanges. And then no anonymous thing is required...
101 2014-07-12 14:14:41 <earlz> and honestly, the only real world use case I can think of involves money laundering.
102 2014-07-12 14:14:44 <CodeShark> buzio: anonymity was NOT one of the design specs of bitcoin
103 2014-07-12 14:14:52 <CodeShark> it was NEVER one of the design specs
104 2014-07-12 14:15:06 <CodeShark> it would be a desirable feature - but it was never a part of the original design
105 2014-07-12 14:15:27 <CodeShark> that people say it's anonymous just reflects their lack of understanding
106 2014-07-12 14:15:29 <buzio> earlz - not really.  It could be, for example, that something has a very public price (a certain price in BTC), and only 5 buyers could be interested in it.  Consider real estate, whatever.  Do you want to announce the transaction when it occurs? (to anyone looking for that exact BTC transfer)
107 2014-07-12 14:15:57 <jcorgan> buzio: are you ban evading?
108 2014-07-12 14:15:59 <buzio> to anyone who knows the real-world pricing information?
109 2014-07-12 14:16:09 <earlz> you'd arrange with the seller to give you multiple addresses to send to
110 2014-07-12 14:16:22 <earlz> and then you'd send to each address separate amounts
111 2014-07-12 14:16:32 <buzio> jcorgan - No, I'm not ban evading.  The other nick in here was ninja something, no ban though.  In -otc there was a ban of a few days, think it expires tomorrow, but I am not in there.
112 2014-07-12 14:16:55 <buzio> earlz- right, this is what I mean.  Shouldn't this be automated, since it's so easy to do programmatically?
113 2014-07-12 14:17:30 <buzio> earlz - I just always look at BTC by analogy with the real-world banking system, and the real-world banking system hardly publishes every transfer amount and date, just anonymized...
114 2014-07-12 14:18:50 <buzio> earlz - plus, granted you don't say anonymity is a design goal, but surely it's part of the security.  Isn't it why most wallet software does mixing or similar?
115 2014-07-12 14:18:54 <earlz> A lot of people argue the ability to easily prove to the public that you send funds somewhere is also a feature
116 2014-07-12 14:19:19 <CodeShark> transparency is a feature - privacy is a feature - it depends on the application :)
117 2014-07-12 14:19:29 <earlz> of course it's not what you want all the time, but remaining anonymous is easy enough to do that I don't think it warrants using a relatively new cryptographic concept like ring signatures
118 2014-07-12 14:20:29 <buzio> earlz - can't you prove that just by publishing the symetric key and signed exchange you use to exchnage the 5 addresses you request? (per my proposal)
119 2014-07-12 14:20:59 <CodeShark> most wallet software does nothing more than merely create a change output whose position in the outputs is randomized
120 2014-07-12 14:21:09 <buzio> earlz - e.g. I propose you can send a message somehow to a recipient address and get back a list of 5 signed, new addresses, encrypted with a symmetric key for this exchange.
121 2014-07-12 14:21:41 <buzio> then you can just send the amounts to those 5 addresses (over an hour? a day?  whatever - including from several of your addresses, not just one.)
122 2014-07-12 14:22:06 <CodeShark> we need to stop thinking in terms of addresses - it sets back inovation :)
123 2014-07-12 14:22:21 <buzio> the recipient could do the same.  So, it would kind of be an analogy with RAID-5 striping.  There are "physically" however many drives (addresses) but logically just the one.
124 2014-07-12 14:22:29 <CodeShark> we have scripts - a challenge script and a solution script
125 2014-07-12 14:22:31 <buzio> CodeShark - what do you want me to call it instead of addresses?
126 2014-07-12 14:23:09 <earlz> how do you send that out-of-band message to get those addresses?
127 2014-07-12 14:23:20 <CodeShark> when sending a transaction, you provide a challenge script. to claim the value, someone needs to provide a solution script. in other words, when you append the solution script to the challenge script and run it, it must evaluate to true
128 2014-07-12 14:23:24 <earlz> htat problem already exists with multisig
129 2014-07-12 14:24:08 <CodeShark> bitcoin doesn't hold balances at addresses in the sense of a post office - it holds unspent outputs with challenge scripts that require a solution script to claim
130 2014-07-12 14:24:16 <buzio> earlz - well, I know you don't like people embedding data into the blockchain, but that certainly would be one way to do it.
131 2014-07-12 14:24:23 <earlz> I personally am excited to a new set of p2sh transactions being relayed as standard
132 2014-07-12 14:24:32 <buzio> CodeShark, okay
133 2014-07-12 14:24:44 <earlz> lol that was my proposed multisig solution and instant flames :)
134 2014-07-12 14:25:08 <buzio> earlz - I think we're slightly behind moore's law on that one.
135 2014-07-12 14:25:18 <earlz> for what
136 2014-07-12 14:25:46 <buzio> earlz - there are 7 billion people in the world, but 70 GB is a huge file today (for a blockchain).  Whereas 1 GB total blockchain is fine.  So, we're just a bit off in terms of the standard storage sizes versus the amount of data the world's people need to exchange.
137 2014-07-12 14:26:52 <buzio> I mean, if we were slightly ahead on moore's law of storage, and the standard today were 12 terabyte hard-drives, 2 terabytes of storage in mobile phones, then embedding very very small data in the blcockchain would be more acceptable.
138 2014-07-12 14:27:01 <earlz> eventually, I imagine the self-cleaning blockchain idea will be implemented
139 2014-07-12 14:27:03 <CodeShark> I hope all transactions become p2sh
140 2014-07-12 14:27:33 <CodeShark> we can keep full generality while maintaining a truly standardized txout script format
141 2014-07-12 14:27:41 <earlz> I know theirs multibit and all that, but a fully validated node with perfect security not requiring a full blockchain would be amazing
142 2014-07-12 14:28:07 <buzio> earlz, CodeShark - in terms of the closer-to-physical p2p network layer of bitcoin - I don't know much about it.  How do nodes communicate?  Isn't there already some kind of low-level message passing (or otherwise how do nodes get each other updates)
143 2014-07-12 14:28:08 <earlz> I still don't completely understand how p2sh works at a technical level heh
144 2014-07-12 14:28:35 <CodeShark> buzio: bitcoin is a flood network
145 2014-07-12 14:29:01 <CodeShark> each node receives messages from others, validates them, and sends them to other nodes until everyone has gotten it
146 2014-07-12 14:29:04 <buzio> CodeShark, oh.  That's awful!  lol
147 2014-07-12 14:29:13 <earlz> buzio: there is, but you can't relay anything on the network unless it's provable that there are fees redeemable with it, signed with the alert key, or for network overhead like getting a peer list
148 2014-07-12 14:29:37 <buzio> CodeShark - every single message literally saturates every single link in the whole network?  (between any two nodes, regardless of if they've both seen it
149 2014-07-12 14:29:57 <CodeShark> well, nodes at least offer it
150 2014-07-12 14:30:06 <CodeShark> if the other node already has it it doesn't have to request the actual data
151 2014-07-12 14:30:14 <buzio> CodeShark, with the only difference being a isngle back-link not getting saturated (if I *just* got something from you, then my link back to you is the only one I don't saturate with it)
152 2014-07-12 14:30:35 <CodeShark> only the hashes get thrown around the entire network between every link
153 2014-07-12 14:30:46 <buzio> CodeShark, ah, okay.  So it's not quite a flood network then, if the data doesn't have to necessarily travel.  Close, though.
154 2014-07-12 14:30:48 <CodeShark> the actual messages only need to be received once by each peer
155 2014-07-12 14:31:11 <earlz> and there are strict limits in place to avoid ddos attacks
156 2014-07-12 14:31:36 <buzio> CodeShark, earlz - well, yeah.  But if you allowed any kind of message passing this topology would break apart.  It's awful for point to point message passing!
157 2014-07-12 14:32:02 <buzio> CodeShark, earlz - especially if the data is out-of-band and doesn't need to enter the blockchain for some reason
158 2014-07-12 14:33:20 <buzio> CodeShark, earlz - would it be possible to add (in a future version of the protocol) a message-passing algorithm, where if you pay a small fee, you can have your message routed, even though the message itself is just getting routed then discarded, not added to the blockchain?
159 2014-07-12 14:33:38 <CodeShark> take a look at bitmessage
160 2014-07-12 14:33:50 <CodeShark> the small fee is paid in computational expense
161 2014-07-12 14:33:55 <CodeShark> or take a look at namecoin
162 2014-07-12 14:34:12 <buzio> CodeShark, earlz - this would prevent DOS attacks but allow message passing, in important cases, even in the current topology
163 2014-07-12 14:34:13 <earlz> it's not possible currently, but I think it has valid use cases.
164 2014-07-12 14:34:15 <CodeShark> where you pay to associate arbitrary key value pairs in a public database
165 2014-07-12 14:34:29 <earlz> many people think using out-of-band http or some such should suffice though
166 2014-07-12 14:35:11 <CodeShark> the ideal solution would involve people being able to lease storage space via decentralized crypto
167 2014-07-12 14:35:27 <buzio> I know about both namecoin and bitmessage
168 2014-07-12 14:35:48 <buzio> I was just wondering why bitcoin couldn't use its existing p2p network the same way - as long as there was a small fee paid, in order to transmit (flood) the message
169 2014-07-12 14:35:55 <CodeShark> the problem with both namecoin and bitmessage (and bitcoin, for that matter) is that the incentives are misplaced
170 2014-07-12 14:36:13 <buzio> who is jcorgan?
171 2014-07-12 14:36:25 <jcorgan> me
172 2014-07-12 14:36:28 <buzio> who are you?
173 2014-07-12 14:36:49 <CodeShark> we need to figure out a way to compensate critical services like validation and relay - and not just mining
174 2014-07-12 14:36:57 <buzio> CodeShark - agreed.
175 2014-07-12 14:37:30 <buzio> CodeShark, it should be fairly trivial to only relay (flood) messages that have been paid for through a fee.  Obviously the total bandwidth of the network is WAY more than the amount they want to add to the blockchain
176 2014-07-12 14:37:47 <sipa> buzio: we already do
177 2014-07-12 14:37:51 <CodeShark> buzio - that's sort of how it works right now. most nodes will not relay dust
178 2014-07-12 14:37:54 <sipa> buzio: but the fee goes to miners
179 2014-07-12 14:37:57 <buzio> I mean it's a real problem if the size of the blockchain increases by 500 MB every day.  It's no problem at all if that much traffic goes through the network as messages.
180 2014-07-12 14:38:37 <sipa> it can only increase 144 MB per day
181 2014-07-12 14:38:39 <buzio> CodeShark - I know, but there doesn't seem to be a message layer on top of bitcoin, even though the network is all set up for it?
182 2014-07-12 14:39:45 <buzio> CodeShark - hence bitmessage and the like.  But it would be ideal if certain things - such as exchanging a signed list of addresses encyrpted with a symmetric key - could happen on-network.  That would make bitcoin network stronger.
183 2014-07-12 14:40:05 <CodeShark> why would it make the network stronger?
184 2014-07-12 14:40:07 <buzio> CodeShark, also, it would remove some of the data that people put in the blockchain anyway
185 2014-07-12 14:40:16 <earlz> the problem with an out-of-band fee'd network still requires sending and then redeeming those fees
186 2014-07-12 14:40:17 <CodeShark> you can negotiate such stuff outside the p2p network
187 2014-07-12 14:40:37 <buzio> CodeShark, as I just said, it would make people not have to spin their own algorithms for splitting up transactions - which could be prone to various problems.
188 2014-07-12 14:40:45 <CodeShark> you already need out-of-band stuff to connect buyers and sellers
189 2014-07-12 14:41:13 <buzio> CodeShark - well, yes, but if you're going from "give me an address" to "give me 10 addresses" that's quite a difference....
190 2014-07-12 14:41:15 <CodeShark> so once they are connected they can negotiate the key exchange directly
191 2014-07-12 14:41:27 <earlz> If you could relay incompletely signed multisig transactions, that could help multisig to actually be user friendly
192 2014-07-12 14:41:33 <buzio> CodeShark - but they're not really "connected".  People copy over addresses by hand.
193 2014-07-12 14:41:41 <buzio> earlz - yes.
194 2014-07-12 14:42:03 <CodeShark> earlz - I've given lots of thought to that problem and have concluded that it would only make sense atop a more general decentralized application network
195 2014-07-12 14:42:04 <sipa> but they copy it over some mechanism
196 2014-07-12 14:42:14 <buzio> CodeShark - I mean, as long as there is a fee you have to pay to get nodes to transfer messages, the network would be completely immune to DDOS'ing
197 2014-07-12 14:42:17 <sipa> some transport medium
198 2014-07-12 14:42:32 <sipa> buzio: but you can't
199 2014-07-12 14:42:37 <buzio> sipa - but that can include reading it on the telephone, copying it onto a piece of paper or into a contract, handing it to them, etc
200 2014-07-12 14:42:42 <CodeShark> and earlz, fwiw I've managed to make multisigs fairly user-friendly but with some centralization :)
201 2014-07-12 14:42:49 <earlz> It's also almost impossible to prove if a node is properly acting like a relay or not.
202 2014-07-12 14:42:55 <buzio> CodeShark, what is the centralization?
203 2014-07-12 14:43:08 <CodeShark> http://test.ciphrex.com/coinsocket/
204 2014-07-12 14:43:12 <buzio> earlz - what do you mean?  It is possible to know, because of PKI associated with the addresses....
205 2014-07-12 14:43:13 <earlz> yea, that's my problem. stop the centralization and make it doable all from the local wallet :)
206 2014-07-12 14:43:30 <earlz> relays have a public key?
207 2014-07-12 14:43:45 <CodeShark> full validation isn't even practical from most local wallets anymore
208 2014-07-12 14:44:00 <buzio> earlz - they could just pass messages that were signed by the same key as responsible for paying the fee just paid.
209 2014-07-12 14:44:20 <buzio> earlz - any message not signed by a key that also paid the transaction fee for passing the message would get dropped.  that sort of thing...
210 2014-07-12 14:44:31 <sipa> there is no concept like 'the key responsible for paying the fee'
211 2014-07-12 14:44:39 <sipa> keys do not pay; keys certify
212 2014-07-12 14:44:51 <buzio> CodeShark - but the more general application layer - you already have that :) the lower-level flood network...
213 2014-07-12 14:44:56 <earlz> that still wouldn't incentive relays. adding out of band could significnalty increase bandwidth costs
214 2014-07-12 14:45:21 <sipa> nodes have no incentive to relay messages unless they either get paid, or it benefits the network
215 2014-07-12 14:45:28 <buzio> does anyone here know or has talked with jcorgan?
216 2014-07-12 14:45:31 <CodeShark> a sufficiently general decentralized application protocol with properly placed incentives is the holy grail
217 2014-07-12 14:45:56 <CodeShark> where you could get compensated for providing any kind of computational resource that benefits the network
218 2014-07-12 14:46:02 <buzio> CodeShark - it doesn't seem that hard?  I mean bitmessage does it...
219 2014-07-12 14:46:03 <CodeShark> storage, connectivity, CPU, whatever
220 2014-07-12 14:46:03 <earlz> yea, that's the dream lol
221 2014-07-12 14:47:23 <CodeShark> once we have that, bitcoin will truly look like nothing more than a successful early experiment
222 2014-07-12 14:48:14 <CodeShark> but we don't have that yet :p
223 2014-07-12 14:48:19 <buzio> CodeShark - that seems kind of odd, as bitcoin didn't have that architectural goal - the main goal was in creating a crypto currency and associated remittance network...
224 2014-07-12 14:48:36 <earlz> heh, I have some crazy ideas for a non-bitcoin fork, but bitcoin really did take almost everything into account. It's hard to cover all the bases with a fundamentally differentd esign required for some of these goals
225 2014-07-12 14:49:25 <CodeShark> the main goal of bitcoin was the clever combination of decentralized timestamping with a cryptocurrency which at once incentivized the decentralized timestamping AND also generates the currency in a decentralized fashion
226 2014-07-12 14:49:31 <earlz> satoshi was a genius lol
227 2014-07-12 14:50:18 <CodeShark> so we now know how to do decentralized timestamping
228 2014-07-12 14:50:30 <earlz> I think the main weakness is PoW. I hate PoS, but some secure way of creating new blocks would be awesome
229 2014-07-12 14:50:35 <CodeShark> I'd say that's the #1 innovation of satoshi
230 2014-07-12 14:50:44 <earlz> PoS has tons of problems
231 2014-07-12 14:51:33 <CodeShark> now we just need to figure out how to provide the right incentives for solving other problems besides decentralized timestamping :)
232 2014-07-12 14:52:37 <earlz> lol I'm pretty sure bitcoin was the first piece of software to prove a piece of distributed software could remain coherent and with wide spread concensus
233 2014-07-12 14:52:53 <earlz> that in itself is quite an accomplishment
234 2014-07-12 14:53:50 <buzio> Who is jcorgan - he just banned me from the bitcoin cancel and in discussing put me on /ignore, saying that other ops instituted the ban (they didn't).
235 2014-07-12 14:53:54 <buzio> chanel*
236 2014-07-12 14:54:06 <buzio> is he a respected op here?
237 2014-07-12 14:54:44 <buzio> earlz - on your non-bitcoin fork, namecoin would be an example...
238 2014-07-12 14:54:48 <earlz> rule #1 you do not talk about altcoins lol maybe we broke that
239 2014-07-12 14:55:17 <buzio> well, you mentioned a hard fork
240 2014-07-12 14:55:25 <earlz> namecoin is a bitcoin fork
241 2014-07-12 14:55:41 <buzio> yes, "heh, I have some crazy ideas for a non-bitcoin fork, but bitcoin really did take almost everything into account."
242 2014-07-12 14:55:54 <buzio> namecoin would certainly fit that discription (non-bitcion fork)
243 2014-07-12 14:55:58 <earlz> oh.. I mean a coin not based on bitcoin
244 2014-07-12 14:56:40 <earlz> completely new implementation. A while back I even layed down some code for it, but realized flaws in my design and privacy issues and all sorts of crap
245 2014-07-12 14:56:51 <earlz> not to mention it'd take months if not years to implement
246 2014-07-12 15:01:09 <earlz> net split or something?
247 2014-07-12 15:06:41 <CodeShark> the implementation is the relatively simple part :)
248 2014-07-12 15:07:15 <CodeShark> given the right resources and correctly placed incentives you'd be surprized how quickly you could have an implementation
249 2014-07-12 15:07:55 <CodeShark> it's figuring out HOW to distribute incentives correctly - and how to enforce them noncoercively - that's the real challenge :)
250 2014-07-12 15:11:05 <CodeShark> with crypto, we are only coerced by natural laws
251 2014-07-12 15:12:48 <CodeShark> of course, crypto does not replace social contracts
252 2014-07-12 15:13:00 <CodeShark> it merely provides a mechanism for their enforcement
253 2014-07-12 15:13:58 <CodeShark> but perhaps that's best left for the #bitcoin-philosophy channel :)
254 2014-07-12 19:03:43 <cronus> does bitcoind deal with btc amount in satoshis? Or is it denominated in bitcoins?
255 2014-07-12 19:03:53 <cronus> ie with a gettransaction call what format should I expect
256 2014-07-12 19:04:27 <earlz> usually everything is in btc values
257 2014-07-12 19:17:22 <cronus> ok, guess ill store them as strings and use a lib like GMP to work with them when needed
258 2014-07-12 19:49:33 <chichov> are there any applications for SIGHASH_SINGLE and SIGHASH_NONE?
259 2014-07-12 20:14:46 <shesek> chichov, you mean application as in interesting use cases, or applications as in something implemented that uses it?
260 2014-07-12 20:14:58 <chichov> shesek: the first
261 2014-07-12 20:29:23 <cronus> I originally compiled and setup bitcoind as root but my app server uses a different unix user and I want to use rpc..seems like if I try using bitcoin-cli from the other user it looks in /$HOME/.bitcoin/bitcoin.conf for configuration but this wont exist for app server user.. is it safe to do something like: mv /root/.bitcoin/ /otheruser/.bitcoin/   will everything else just work?
262 2014-07-12 22:57:20 <jcorgan> sipa: ping
263 2014-07-12 22:57:53 <sipa> jcorgan: pang
264 2014-07-12 22:58:28 <jcorgan> i'd like to confirm my understanding of the tweak functions in libsecp256k1
265 2014-07-12 22:58:45 <jcorgan> privkey_tweak_add(d, k) = d+k mod n
266 2014-07-12 22:58:49 <sipa> correct
267 2014-07-12 22:59:00 <jcorgan> pubkey_tweak_add(Q, k) = Q+Gk
268 2014-07-12 22:59:08 <sipa> correct
269 2014-07-12 22:59:19 <jcorgan> privkey_tweak_mul(d, k) = d*k mod n
270 2014-07-12 22:59:26 <sipa> correct
271 2014-07-12 22:59:38 <jcorgan> pubkey_tweak_mul(Q, k) = Qk
272 2014-07-12 23:00:07 <sipa> correct
273 2014-07-12 23:00:17 <jcorgan> thanks :)
274 2014-07-12 23:00:27 <jcorgan> is there some specific meaning to the term 'tweak'
275 2014-07-12 23:00:44 <sipa> there is, in cryptography, and this is not it
276 2014-07-12 23:00:56 <sipa> i should probably rename those
277 2014-07-12 23:01:08 <sipa> it's really just particular mutations of keys
278 2014-07-12 23:02:06 <jcorgan> got it.  how to use those for bip32 derivation is a lot more clear now
279 2014-07-12 23:33:43 <sipa> we just retargetted: 3.08% up only