1 2014-09-21 11:15:00 <firelegend> aaaand
  2 2014-09-21 11:15:12 <firelegend> I managed to set some people back to the straight path
  3 2014-09-21 11:15:23 <firelegend> Storing people's bitcoin in double, nono
  4 2014-09-21 11:15:35 <firelegend> It's a new exchange etc.
  5 2014-09-21 11:30:29 <hearn> huh
  6 2014-09-21 11:30:35 <hearn> gmail has got integrated github support
  7 2014-09-21 11:30:38 <hearn> crazy!
  8 2014-09-21 11:31:09 <firelegend> rather odd
  9 2014-09-21 11:34:01 <fanquake> hearn really? What sort of features?
 10 2014-09-21 11:34:17 <hearn> there's a new "view pull request" button next to a pull req notification email, in the summary view
 11 2014-09-21 11:55:26 <alfacent> https://bitcointalk.org/index.php?topic=790883.msg8911648#msg8911648
 12 2014-09-21 13:07:57 <theadmin`> anybody know how i can force close wallets and not auto-open them with multibit?
 13 2014-09-21 13:09:13 <dabura667> theadmin`: This is not the place to ask that. This channel is only for the development discussion of the Bitcoin Core client. Check Multi-bit's support forums.
 14 2014-09-21 14:20:35 <sipa> dabura667: it's wider than just bitcoin core, but yes, development
 15 2014-09-21 16:01:13 <Happzz> sipa any reason why coinjoin isnt being built in bitcoin-qt?
 16 2014-09-21 16:02:00 <sipa> Happzz: because hardly anyone works on the wallet in bitcoin-qt
 17 2014-09-21 16:05:34 <Luke-Jr> Happzz: patches welcome?
 18 2014-09-21 16:06:02 <sipa> ^
 19 2014-09-21 16:07:26 <Happzz> im asking if there's a good reason it's not built in
 20 2014-09-21 16:07:37 <Happzz> (i thought about one, wanted to know if there are more)
 21 2014-09-21 16:08:04 <Happzz> related to this: can multiple signed transactions be "merged", or they must first be merged and then signed altogether?
 22 2014-09-21 16:10:48 <sipa> first merge, then sign
 23 2014-09-21 16:11:08 <hearn> Happzz: lots of issues to make a coinjoin implementation: https://medium.com/@octskyward/merge-avoidance-7f95a386692f
 24 2014-09-21 16:13:35 <j> hello
 25 2014-09-21 16:13:58 <Guest22465> I have a quesion about bitcoind I was hoping someone could help me
 26 2014-09-21 16:14:26 <Guest22465> its about launching it under a specific user in linux
 27 2014-09-21 16:14:50 <Guest22465> anyone willing to share some wisdom ?
 28 2014-09-21 16:14:55 <Banks> Please take a minute and join wwww.CoinDev.net - Cryptocurrency Project Development Forums
 29 2014-09-21 16:15:33 <Luke-Jr> this is not a support channel, or a spam channel
 30 2014-09-21 16:15:59 <Happzz> thanks hearn
 31 2014-09-21 16:16:14 <Guest22465> well what is it then ?
 32 2014-09-21 16:16:23 <Guest22465> sleeping channel ?
 33 2014-09-21 16:16:34 <Guest22465> shhhhh
 34 2014-09-21 16:41:48 <Banks> Odd, I was suggested to use the IRC over the forums.
 35 2014-09-21 16:42:17 <Banks> But by the looks the past half hour in here. I haven't gained, learned or seen any discussion
 36 2014-09-21 16:42:59 <sipa> Banks: stay a few days :)
 37 2014-09-21 16:43:39 <Luke-Jr> Banks: usually we try to spend more time coding than talking ;)  and for some reason we sleep occasionally too
 38 2014-09-21 16:45:32 <sipa> Banks: and you'll have to beat a huge momentum if you want to try to replace bitcointalk
 39 2014-09-21 16:47:53 <Banks> I have no intentions of replacing bitcointalk.
 40 2014-09-21 16:48:17 <sipa> ok
 41 2014-09-21 16:49:26 <Banks> I'm focusing on the projects themselves, not coins. On a daily bases I seek coders, designers, content writers, merchants, etc. Sure theres plenty of places online to find all of those. But for cryptocurrency? Not many.. all in one place (Just for projects)
 42 2014-09-21 16:50:09 <Banks> But everyone is entitled to opinions, if me trying to create a tool or resource for everyone is considered "spam" guess there isn't much I can do.
 43 2014-09-21 17:57:22 <owowo> ;;estimate
 44 2014-09-21 17:57:23 <gribble> Next difficulty estimate | 35368587733.3 based on data since last change | 36431585387.9 based on data for last three days
 45 2014-09-21 18:03:33 <gfawkes> all i have to say is... fuckin' a! r0x0r my s0x0r5 with working code.
 46 2014-09-21 18:40:43 <AlSzacrel> spend a good of the day creating simulations for the coinselection thing, but it becomes exceedingly obvious that Python is just too friggin slow to test behaviour of UTXO pools bigger than a few thousand with different selection behaviors. :(
 47 2014-09-21 18:42:07 <AlSzacrel> +good part
 48 2014-09-21 18:48:01 <samson_> Can anyone send alert messages ro be relayed around the Bitcoin p2p network or do they need to be signed with the alert key before they are propogated ?
 49 2014-09-21 18:48:09 <samson_> *to
 50 2014-09-21 18:51:20 <justanotheruser> samson_: they need the alert key
 51 2014-09-21 18:51:44 <AlSzacrel> samson_: The article on alerts in the wiki specifies that they need to be signed by a specific key to be considered valid. It doesn't clarify whether invalid alerts are relayed, but I'd think no.
 52 2014-09-21 18:51:46 <justanotheruser> otherwise one could spam the network with alerts
 53 2014-09-21 18:52:17 <justanotheruser> AlSzacrel: clients won't propogate invalid things
 54 2014-09-21 18:52:50 <AlSzacrel> justanotheruser: That would make sense, thanks.
 55 2014-09-21 19:02:37 <samson_> Thanks guys, I assumed that it would only be propogated if the signature matched the alert key - I just wanted to confirm this
 56 2014-09-21 19:06:03 <jintelletec> looking for engineers in san fran or LA looking to work fulltime for btc companies
 57 2014-09-21 19:46:30 <remotemass> Can anyone give me some feedback on this? https://bitcointalk.org/index.php?topic=790883.0
 58 2014-09-21 19:49:14 <justanotheruser> remotemass: it is something that can be done without a hardfork
 59 2014-09-21 19:49:20 <justanotheruser> and probably without a fork in general
 60 2014-09-21 19:50:21 <justanotheruser> also, it means that miners can manipulate the lotto pretty easily
 61 2014-09-21 19:51:28 <remotemass> how could you do it without a fork?
 62 2014-09-21 19:53:22 <justanotheruser> remotemass: https://bitcointalk.org/index.php?topic=277048.0
 63 2014-09-21 20:02:43 <remotemass> how do you think the miners can manipulate the lotto?
 64 2014-09-21 20:03:49 <justanotheruser> remotemass: what is "LAST_HASH_VALUE"
 65 2014-09-21 20:05:15 <newbier> anyone running relay node client from BlueMatt?
 66 2014-09-21 20:05:40 <newbier> running into problem with it
 67 2014-09-21 20:06:07 <remotemass> justanotheruser, once the transactions for one contest of the lotto have 6 confirmations you check the last hash and the next block will have to include coinbase output to the lotto winner
 68 2014-09-21 20:06:50 <remotemass> I mean, the latest hash
 69 2014-09-21 20:07:10 <remotemass> I will give an example:
 70 2014-09-21 20:07:30 <justanotheruser>  remotemass wait
 71 2014-09-21 20:08:02 <justanotheruser> so the hash of the block with the 7th confirmation is the winning hash
 72 2014-09-21 20:08:29 <remotemass> The contest takes place at Block 100. After 6 confirmations we check the hash of block 106. The block 107 will have to include the lotto rewards of the coins burnt at block 100.
 73 2014-09-21 20:09:06 <justanotheruser> remotemass: great, so the miners get to decide who wins
 74 2014-09-21 20:09:27 <remotemass> No way. How would they?
 75 2014-09-21 20:09:56 <justanotheruser> by throwing away blocks that they don't win in
 76 2014-09-21 20:10:19 <justanotheruser> I will reword that
 77 2014-09-21 20:10:31 <justanotheruser> by throwing away the blocks that don't cause them to win
 78 2014-09-21 20:11:32 <remotemass> Who wins is determined by the hash of the block 106. Miners will only be forced to include the lotto rewards in block 107. There's nothing they can do to change the winner
 79 2014-09-21 20:12:03 <justanotheruser> yeah, so the winner of 106 may throw away their block if it isn't a winner
 80 2014-09-21 20:12:09 <fvdl> hi
 81 2014-09-21 20:13:15 <justanotheruser> hi
 82 2014-09-21 20:13:43 <fvdl> anyone can tell me about the 'malleballity bug' in clear terms ?
 83 2014-09-21 20:14:41 <edcba> that sux
 84 2014-09-21 20:15:46 <edcba> ok if i did follow correctly take 3 transactions : "1", "2", "01"
 85 2014-09-21 20:16:12 <edcba> there are only 2 real different transactions but 3 different representations
 86 2014-09-21 20:16:57 <alfacent> sorry, lost connection
 87 2014-09-21 20:17:08 <alfacent> did I miss something?
 88 2014-09-21 20:17:11 <edcba> doesn't matter i was talking to fvdl
 89 2014-09-21 20:17:13 <justanotheruser> fvdl: part of a transaction can be changed while it is still valid
 90 2014-09-21 20:17:25 <alfacent> I was saying: the winner is already chosen when they need to include a block that rewards the lotto winner
 91 2014-09-21 20:17:33 <fvdl> i know that, some parts can be changed, except for the sender and receiver (those are signed)
 92 2014-09-21 20:17:39 <justanotheruser> alfacent: you are remotemas?
 93 2014-09-21 20:18:01 <alfacent> yes
 94 2014-09-21 20:18:03 <alfacent> sorry
 95 2014-09-21 20:18:06 <fvdl> but the transactionID is complete SHA of the whole transaction so the ID changes ?
 96 2014-09-21 20:18:15 <justanotheruser> yes, block 106 chooses the winner based on the hash, right?
 97 2014-09-21 20:18:37 <justanotheruser> first of all this wouldn't be a hardfork, but that is besides the point
 98 2014-09-21 20:18:58 <remotemass> the winner is determined by the hash of block 106 and miners need to include lotto reward in the next block
 99 2014-09-21 20:19:21 <justanotheruser> remotemass: and if a miner mines 106 and it doesn't have them winning, they are free to throw that block away
100 2014-09-21 20:19:48 <earlz> using the blockchain as a seed for a lottery is risky at best
101 2014-09-21 20:20:02 <justanotheruser> over time miners will be able to manipulate this and profit quite a bit
102 2014-09-21 20:20:40 <earlz> A random number "oracle" is hard to come by with a friendly API
103 2014-09-21 20:21:10 <Eliel> remotemass: in short, if the lottery prize is big enough, miners will be willing to throw away their 25 BTC block reward for a better chance at winning the lottery.
104 2014-09-21 20:21:11 <justanotheruser> earlz: https://bitcointalk.org/index.php?topic=277048.0
105 2014-09-21 20:22:16 <earlz> heh cointoss is much easier than a dice roll though
106 2014-09-21 20:22:25 <earlz> maybe it's possible to adapt though
107 2014-09-21 20:22:37 <justanotheruser> earlz: I don't see why it wouldn't be
108 2014-09-21 20:22:46 <justanotheruser> the only risk is annoying people DoSing
109 2014-09-21 20:23:02 <justanotheruser> joining the lotto and setting up 99% then bailing
110 2014-09-21 20:23:17 <remotemass> justanotheruser, yeah you are right. What if you use the hash of another blockchain as your random number?
111 2014-09-21 20:23:39 <justanotheruser> remotemass: then you are vulnerable to the same thing..
112 2014-09-21 20:23:46 <remotemass> indeed
113 2014-09-21 20:27:11 <Eliel> remotemass: there is a workable algorithm for producing fair random numbers though. You have n parties choose a random number and publish a cryptographic hash of their number. When everyone has published the hash, they reveal their numbers and if the numbers match the hashes, they're all hashed together and the result will be used as a random number for the draw.
114 2014-09-21 20:28:51 <justanotheruser> Eliel: it's fair, but is it trustless?
115 2014-09-21 20:29:08 <homicidium> hello
116 2014-09-21 20:29:33 <remotemass> Eliel: how is that algorithm called? Also can you give an example so that it becomes more clear?
117 2014-09-21 20:29:41 <homicidium> ,I wanna learn bitcoins programming language
118 2014-09-21 20:29:50 <homicidium> I wanna learn bitcoins programming language
119 2014-09-21 20:30:01 <homicidium> What was that?
120 2014-09-21 20:30:17 <Eliel> justanotheruser: if you're one of the n parties, there's no need to trust the others. If you're not one of the n parties, you need to trust that one of them produced a proper random number.
121 2014-09-21 20:30:51 <fvdl> remotemass you want to do a random draw between parties, where every party can have input (and so change the number) while that parties can not determine the output by precalculate the end result ?
122 2014-09-21 20:31:58 <justanotheruser> Eliel: what if the last guy knows he lost and doesn't produce his number?
123 2014-09-21 20:32:04 <justanotheruser> does the tx not go through?
124 2014-09-21 20:33:25 <remotemass> fvdl: I'm afraid I cannot follow you. Did you read my post on the forum "fvdl"?
125 2014-09-21 20:33:38 <fvdl> remotemass: nope sorry
126 2014-09-21 20:33:52 <fvdl> remotemass: what do you want to accomplisch ? (a lottery ?)
127 2014-09-21 20:34:10 <remotemass> it's here: https://bitcointalk.org/index.php?topic=790883.0
128 2014-09-21 20:35:10 <remotemass> yes a trustless lottery without game owner, so no taxes being paid or revenues to the game owner
129 2014-09-21 20:35:49 <edcba> more like a bet between parties then
130 2014-09-21 20:36:31 <homicidium> T
131 2014-09-21 20:36:37 <homicidium> TÜRK VAR MI
132 2014-09-21 20:36:39 <remotemass> yes, a bet from which the outcome is random
133 2014-09-21 20:36:44 <fvdl> that is possible
134 2014-09-21 20:37:00 <Eliel> justanotheruser: that situation is problematic but can be addressed by requiring a deposit that is not returned unless the number is revealed.
135 2014-09-21 20:37:14 <fvdl> but if you can see the other entries, you can calculate the outcome ;-)
136 2014-09-21 20:37:22 <fvdl> and determine how much you would invest to get the price
137 2014-09-21 20:37:27 <justanotheruser> Eliel: so you can only bet half the money you own right?
138 2014-09-21 20:37:51 <edcba> ideally you bet X+Y and you get either X either X+n*Y then ?
139 2014-09-21 20:38:26 <Eliel> justanotheruser: something like that.
140 2014-09-21 20:43:02 <fvdl> remotemass: it is possible to make a garantueed proven lottery where it is not possible to fake
141 2014-09-21 20:43:04 <Eliel> justanotheruser: deposit + a rule that if one participant refuses to reveal their number, they forfreit both their bet, chance of winning and deposit. The game proceeds by using all numbers except for the one who stood up.
142 2014-09-21 20:44:23 <remotemass> What if you hash hashes from different blockchains and use that as the RNG ?
143 2014-09-21 20:45:11 <Eliel> remotemass: the problem is that the last hash will always have direct influence over the result.
144 2014-09-21 20:45:24 <remotemass> indeed
145 2014-09-21 20:45:36 <Eliel> and a miner can always choose to not publish one that is not to their favor
146 2014-09-21 20:45:56 <remotemass> fvdl: do you mean it is possible a provably fair lottery ?!
147 2014-09-21 20:47:06 <remotemass> that is possible but can you make it without anyone being the game owner that has to pay taxes or has revenues?
148 2014-09-21 20:47:38 <Eliel> remotemass: the algorithm I outlined is for precisely that situation
149 2014-09-21 20:48:15 <remotemass> what do you mean by "reveal their number" ?
150 2014-09-21 20:48:57 <fvdl> remotemass: at the end someone must divide the price, that can be the miner, but at the end someone has to transfer the funds
151 2014-09-21 20:49:57 <remotemass> is that what you mean by "reveal their number" ?!
152 2014-09-21 20:49:58 <Eliel> remotemass: the numbers aren't revealed before everyone has published a hash of their number. This is to prevent anyone from changing their number after it's been decided.
153 2014-09-21 20:50:59 <remotemass> do you have a link, explaining that algorithm?
154 2014-09-21 20:51:19 <Eliel> with the hashes, you can verify that everyone publishes the number they decided on before seeing others' numbers.
155 2014-09-21 20:52:59 <justanotheruser> Eliel: how do you know whether they are refusing to reveal their number trustlessly
156 2014-09-21 20:53:00 <abrkn> how would running low on ram affect bitcoind?
157 2014-09-21 20:53:29 <fvdl> remotemass: you need a example of the algoritm that proves that the competitors are playing and not cheating ?
158 2014-09-21 20:54:15 <Eliel> I'm pretty sure there's an article about this algorithm somewhere, but unfortunately, I don't remember the name for this algo so, can't even offer up a search term.
159 2014-09-21 20:55:37 <remotemass> I'm confused. But I agree that my proposal is faulty
160 2014-09-21 20:57:19 <Eliel> justanotheruser: that's probably the weakest point in the algo. No way to tell if someone is refusing or just unable to reveal their number.
161 2014-09-21 20:59:05 <Eliel> a reasonable time limit would seem like a good way to deal with it.
162 2014-09-21 20:59:26 <justanotheruser> so an attacker just has to DoS them for that long
163 2014-09-21 20:59:39 <Eliel> long enough that a DoS can be circumvented in most cases.
164 2014-09-21 21:00:07 <Eliel> but that's really getting out of scope for the algorithm.
165 2014-09-21 21:00:21 <remotemass> BTW, do you think that a chain of hashes of tweets could be an interesting Random Number Generator?
166 2014-09-21 21:07:42 <remotemass> Such that the random number generated by a tweet would be a hash of: (that tweet + hash of previous tweet)
167 2014-09-21 21:13:27 <remotemass> What if you use the Hash of : (the next Hashrate of the network + Unix timestamp of date of the adjustment) as the random number?
168 2014-09-21 21:13:36 <justanotheruser> remotemass: no
169 2014-09-21 21:13:52 <justanotheruser> the tweet is manipulatable
170 2014-09-21 21:14:01 <justanotheruser> and the network hashrate + unix timestamp isn't random
171 2014-09-21 21:21:43 <remotemass> Can you predict the exact hashrate the network will have in the future?
172 2014-09-21 21:21:53 <remotemass> I don't think so
173 2014-09-21 21:25:01 <Eliel> remotemass: no, but you can't measure it either
174 2014-09-21 21:34:15 <remotemass> Imagine that you run the contest on the first block after difficulty changes and use as random number the hash of: (all the following 2015 block hashes + new difficulty). Wouldn't that be a good random number?
175 2014-09-21 21:46:05 <kefkius> How can I get the script for a given tx?
176 2014-09-21 21:46:54 <justanotheruser> kefkius: do you have bitcoind?
177 2014-09-21 21:47:04 <kefkius> Yep
178 2014-09-21 21:47:18 <justanotheruser> getrawtransaction <txid>
179 2014-09-21 21:47:25 <justanotheruser> decoderawtransaction <rawtx>
180 2014-09-21 21:47:51 <kefkius> Awesome, thanks
181 2014-09-21 21:48:12 <mr_burdell> or "getrawtransaction <txid> 1" to do it in one command
182 2014-09-21 21:48:54 <justanotheruser> :O