1 2014-04-24 01:53:37 <warren> sipa: btw, is it feasible to have secp256k1 (disabled by default) in 0.9.2?
  2 2014-04-24 02:13:20 <petertodd> killerstorm: fwiw my replace-by-fee code seems to be quite reliable in bumping tx fees to get them into blocks if it's taking awhile; tx pressure is quite real and really does prevent txs from getting mined quickly if you pay absolute minimum for relaying
  3 2014-04-24 02:22:54 <robonerd> hm
  4 2014-04-24 02:23:06 <robonerd> digitalmagus magus as in magus and fungii?
  5 2014-04-24 02:49:22 <pZombie> is it possible to lock an address(indefinitely) in such a way, that it would allow only for timed transactions to be declared 7 days (for example) ahead of time? So if i was to run a bitcoin bank, i would be able to see ahead of time which transactions are going to happen in the future, and in case of a hacker doing a transaction, i would be able to clear the hacker transactions.
  6 2014-04-24 02:51:11 <ThickAsThieves> hearn will make any absurd idea possible if you pay him enough
  7 2014-04-24 02:51:55 <pZombie> i would then be able to issue an emergency transaction which cannot be cleared by either me or the hacker, to a priorly declared cold storage address
  8 2014-04-24 02:52:06 <gmaxwell> pZombie: No, not without some extra infrastructure, but ignoring that — it's not quite clear to me how you'd disambiguate between the hacker and the proper owner, since the hacker has the owners private keys.
  9 2014-04-24 02:52:25 <gmaxwell> (and if you have some private keys that are hacker proof, just use those in the first place :) )
 10 2014-04-24 02:53:21 <petertodd> ThickAsThieves: no need to start accusing people of malice
 11 2014-04-24 02:53:32 <pZombie> gmaxwell - correct, both hacker and owner of the hot wallet that requires to issue transactions 7 days in advance can issue transactions. I would see it got hacked by seeing transactions being issued that were not intended. I would then issue the emergency transaction
 12 2014-04-24 02:54:34 <pZombie> gmaxwell the hacker can also issue the emergency transaction, but that would be a paper wallet i created that never touched the internet. It would not help him at all and the funds would be secured
 13 2014-04-24 02:55:22 <pZombie> this system would help exchanges that got their hot wallets hacked. It would be inconvenient for the users having to wait 7 days, but that was just an example. Any time delay would help
 14 2014-04-24 02:55:36 <ThickAsThieves> <petertodd> ThickAsThieves: no need to start accusing people of malice  /// such diplomacy
 15 2014-04-24 02:55:55 <ThickAsThieves> petertodd is now my favorite dev
 16 2014-04-24 02:56:55 <petertodd> pZombie: you can do this right now with nLockTime by putting funds in an offline wallet with a nLockTime'd transaction moving them back to the hot wallet
 17 2014-04-24 02:59:44 <pZombie> petertodd if a hacker hacks my hot wallet in the meantime, is there any way to prevent the funds from getting stolen once the lock is done?
 18 2014-04-24 03:00:21 <pZombie> because that is not the full functionality i described above
 19 2014-04-24 03:01:31 <petertodd> pZombie: ah right, I think your best bet there is to just use something off-line and be done with it - an attacker can also hack your computer to restrict your ability to see upcoming transactions you know
 20 2014-04-24 03:02:54 <pZombie> i won't just have one computer. I will have several computers that keep an eye on the blockchain, and list the 7 days ahead tranactions in a spreadsheet, so i can see which transactions are legit and if there are some non-legit, in which case i would issue the emergency transaction
 21 2014-04-24 03:03:34 <pZombie> the only way a hacker could steal from me if i was able to see all transactions 7 days ahead, as listed in the chain, would be if he had access to my cold storage emergency address
 22 2014-04-24 03:03:59 <pZombie> which would be close to impossible if i created it offline in a faraday caged computer
 23 2014-04-24 03:04:04 <petertodd> it's a lot easier than you'd expect for an attacker to attack multiple machines; if it isn't, then just use multiple machines to authorize spends w/ multisig
 24 2014-04-24 03:04:18 <petertodd> anyway, short answere is no, bitcoin can't do that :)
 25 2014-04-24 03:06:36 <pZombie> well, i came here to post this idea, in case it might be possible to have this in the future. Addresses which can issue transactions that will be executed 7 days (or any other priorly declared timeframe) in the future without the ability to switch that off
 26 2014-04-24 03:07:25 <petertodd> a more advanced scripting system could definitely allow that, but who knows if that'll be implemented on bitcoin
 27 2014-04-24 03:07:33 <petertodd> ethereum could definitely do it
 28 2014-04-24 03:08:44 <coryfields> wumpus: for backlog: I'm headed out of town until ~tues, but when I get back, I'm going to spend some time getting the osx cross build ready for release
 29 2014-04-24 03:08:53 <pZombie> I am sure if the devs think it is a good idea, it will be implemented at some point. Bitcoin can and will evolve
 30 2014-04-24 03:09:02 <coryfields> warren once again used his super nagging powers on me :)
 31 2014-04-24 03:09:45 <coryfields> wumpus: i'll try to have something ready for testing by the end of next week
 32 2014-04-24 03:09:49 <petertodd> pZombie: it's not that easy; upgrading bitcoin is very hard and risky
 33 2014-04-24 03:10:18 <pZombie> petertodd: sure, but bitcoin also has the best devs working behind it
 34 2014-04-24 03:14:15 <petertodd> pZombie: when I say very hard, I'm speaking from the perspective of those devs
 35 2014-04-24 03:17:04 <pZombie> petertodd: yes, but i think it is an important feature if it is feasible to implement it. It adds a lot of security. Combined with an exchange that allows for users to lock their payout address, a script could search through the list of pre-determined transactions to happen in X days or even X minutes, and see if any transaction has been issued to an address not listed.
 36 2014-04-24 03:17:28 <pZombie> Should this be the case, it would clear all transactions and or issue the emergency transaction
 37 2014-04-24 03:17:48 <pZombie> an exchange hot wallet could not be robbed anymore
 38 2014-04-24 03:19:31 <pZombie> even if the whole exchange gets compromised, it could have some "outside" pcs browse the blockchain on different lines, not known to the hacker, which would issue it
 39 2014-04-24 03:28:40 <pZombie> As for running a bitcoin bank, i would want to split the private addresses (cold storages) into 3 different ( or more ) physical locations in well guarded tresor rooms. I would want to not have to ever access those physical locations. I would want for there being a function which allows for my cold storage wallet to keep filling up my hot wallet periodically with a set amount of coins daily. In the worst case scenario i would have to wa
 40 2014-04-24 03:29:33 <pZombie> in case of my hot wallet getting compromised i would need a function to blacklist my hot wallet address which the cold storage filling it periodically would notice, and would stop
 41 2014-04-24 03:30:24 <pZombie> how else would it be possible to run a bitcoin bank, without having to trust anyone with the private keys, yet if i died, others would need to have access to them still
 42 2014-04-24 03:31:14 <pZombie> if i was the only one with the keys in one location, i could be abducted and blackmailed
 43 2014-04-24 03:31:29 <petertodd> you know about multisig right?
 44 2014-04-24 03:33:05 <pZombie> petertodd: how would multisig help with automagically filling up the hot wallet periodically, and no one having to access any private keys to fill the hot wallet?
 45 2014-04-24 03:33:37 <petertodd> by spreading out approval of those actions across multiple, independent, actors
 46 2014-04-24 03:34:05 <pZombie> petertodd what happens if some of those actors die in a plane crash?
 47 2014-04-24 03:34:25 <petertodd> I'm consulting for an exchange right now on security; long term everything will be multi-system/party approval with multiple means of authenticating customer intent
 48 2014-04-24 03:34:54 <petertodd> multisig can be done in a n-of-m system, only if everyone dies do you have a problem, and even then providing last ditch backups for stuff like that isn't a big deal
 49 2014-04-24 03:36:47 <pZombie> can you elaborate on the last ditch backup part?
 50 2014-04-24 03:37:20 <pZombie> what would happen if all parties involved get abducted
 51 2014-04-24 03:37:35 <petertodd> e.g. leave a copy of the seed in a bank vault under the control of the lawyers
 52 2014-04-24 03:41:34 <pZombie> hm, that could actually work, but i do not feel comfortable knowing how easy the funds could be seized that way
 53 2014-04-24 03:42:32 <petertodd> yeah, it'll be interesting watching best practices for this stuff develop
 54 2014-04-24 03:42:48 <petertodd> in the meantime, you should accept that bitcoin is to a first approximation fixed in stone :)
 55 2014-04-24 03:49:35 <pZombie> anyway, i just wanted to throw some ideas in. Time for a break. See you guys later
 56 2014-04-24 04:02:23 <ThickAsThieves> who runs bitundo?
 57 2014-04-24 04:02:27 <ThickAsThieves> hearn, and who else?
 58 2014-04-24 04:03:09 <Emcy> if bitundo is that pay4doublespend thing
 59 2014-04-24 04:03:16 <Emcy> i dont think mike hearn runs that
 60 2014-04-24 04:05:59 <petertodd> ThickAsThieves: http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/ says Eric Springer
 61 2014-04-24 04:07:44 <justanotheruser> I like how much denial there was about double spending 0conf tx before someone made a website saying they could double spend for you was made
 62 2014-04-24 04:08:03 <petertodd> indeed, or how I showed you don't even need a fancy website
 63 2014-04-24 04:08:47 <justanotheruser> "Just have well connected nodes" forget about push to pool, that's not possible you dummy!
 64 2014-04-24 04:09:58 <petertodd> yeah, well, lots of ignorance around there; not many people really understand how bitcoin works
 65 2014-04-24 04:10:02 <ThickAsThieves> “Fact is, unconfirmed transactions aren’t safe.”
 66 2014-04-24 04:10:08 <ThickAsThieves> fukn newsflash!
 67 2014-04-24 04:11:06 <ThickAsThieves> "e says that ideas such as replace-by-fee could solve the possible implications of double spending unconfirmed transactions on-block by enforcing the replacement of an existing transaction only with another that has a higher fee."
 68 2014-04-24 04:11:10 <ThickAsThieves> christ...
 69 2014-04-24 04:11:43 <ThickAsThieves> can we apply this to breathing rights?
 70 2014-04-24 04:11:54 <petertodd> heh, that article could have been a bit more technical and clear :)
 71 2014-04-24 04:13:10 <ThickAsThieves> i wish bitcoin had a way to confirm transactions to prevent doublespending
 72 2014-04-24 04:13:15 <ThickAsThieves> wtf are we to do?
 73 2014-04-24 04:13:18 <justanotheruser> What is the best option for pos? I was thinking either pay the story X btc, then when you checkout they refund you the leftover amount. You also could make a 2 of 2 tx with a 3rd party the merchant trusts not to doublespend
 74 2014-04-24 04:13:30 <justanotheruser> s/story/store
 75 2014-04-24 04:15:39 <petertodd> justanotheruser: I expect we'll find that replace-by-fee scorched-earth works pretty well. It doesn't protect you from sybil attacks like real confirmations do however.
 76 2014-04-24 04:16:11 <petertodd> but I gotta finish up my replace-by-fee implementation to actually try that out for real!
 77 2014-04-24 04:16:26 <justanotheruser> petertodd: could you explain how this works?
 78 2014-04-24 04:17:58 <petertodd> justanotheruser: really simple: I pay you 100mBTC with a transaction paying 1mBTC fee, I double-spend that tx with a 10mBTC fee, sending the funds back to me. You say "Fuck you!" and spend all 100mBTC to fees. Miners are incentivized to mine the "scorched-earth" transaction, so I still lose all the money with high probability, removing the incentive to try to screw you over.
 79 2014-04-24 04:18:58 <petertodd> e.g. if I'm buying a coffee from you, your marginal lose for the coffee is quite low, and it turns what was profitable fraud into simple vandalism
 80 2014-04-24 04:19:07 <justanotheruser> petertodd: how can I spend the 100mBTC tx if its unconfirmed?
 81 2014-04-24 04:19:36 <petertodd> justanotheruser: you can spend unconfirmed transactions; that just means a miner who includes both in their block gets 100mBTC of fees
 82 2014-04-24 04:20:01 <justanotheruser> Ohh, so its child pays for parent to screw you over?
 83 2014-04-24 04:20:07 <petertodd> exactly!
 84 2014-04-24 04:20:45 <justanotheruser> Smart. Isn't that vulnerable to Finney attacks?
 85 2014-04-24 04:20:50 <petertodd> it works *really* well for gambling sites, as my possible profit for the double-spend is a small % of the money I'll lose if the scorched earth tx goes through
 86 2014-04-24 04:21:05 <petertodd> justanotheruser: you mean sybil attacks, and absolutely yes it is vulnerable, just like zeroconf is right now
 87 2014-04-24 04:21:40 <petertodd> justanotheruser: basically every real confirm is very good evidence that you aren't being sybil attacked; any unconfirmed tx just can't give you that guarantee
 88 2014-04-24 04:21:53 <justanotheruser> petertodd: I don't mean finney? Isn't there still incentive for a pool to double spend because they get hash rate*100mBTC of that?
 89 2014-04-24 04:22:41 <justanotheruser> I mean as an expected value, obviously it isn't consistently hash%*100
 90 2014-04-24 04:23:05 <petertodd> justanotheruser: well one way to think about it is that replace-by-fee lets you pay someone to do a finney attack, and as it turns out, the merchant being screwed over is the party who can afford to pay the most!
 91 2014-04-24 04:26:32 <justanotheruser> Well the merchant can afford 99mBTC, but if they pay that, then a mining pool has incentive to perform this attack because they get their product plus some fees some of the time right?
 92 2014-04-24 04:27:03 <petertodd> ah, yeah, if you're assuming the mining pool is in on it sure, but that's just Yet Another example of why mining centralization is very dangerous - without large mining pools the chance of any one miner finding a block at the right time is really low
 93 2014-04-24 04:28:45 <justanotheruser> Gregory's UTXO querying PoW isn't SPV-able is it? Because that's the only way I could see mining pool centralization being stopped
 94 2014-04-24 04:28:45 <petertodd> after all, lets be clear, it's *not* perfectly secure, but it does get you to at least the level of security people think zeroconf has right now, but with incentive compatibility. replace-by-fee is also useful for a lot of other applications, e.g. fee bumping, coinjoin, etc.
 95 2014-04-24 04:29:27 <petertodd> justanotheruser: nah, it's SPV-compatible: you can include SPV-proofs that the UTXO queried was the right one for instance
 96 2014-04-24 04:30:10 <justanotheruser> How is an SPV client to prove a block header is valid without the UTXO?
 97 2014-04-24 04:30:35 <dgenr8> petertodd: pretty well, unless you care that the money is thrown away to miners and you have to start all over
 98 2014-04-24 04:30:36 <petertodd> well whatever UTXO was queried as part of the mining process is simply proven via a compact merkle path proof
 99 2014-04-24 04:31:29 <justanotheruser> I see. Are there any reasons not to include that in the next hard fork other than temporary network insecurity?
100 2014-04-24 04:32:02 <petertodd> justanotheruser: it's not even a hard-fork actually; doing it would be a political fight I'm sure
101 2014-04-24 04:33:24 <petertodd> hmm... come to think of it, the politics of doing that on dogecoin are probably tractable...
102 2014-04-24 04:34:27 <justanotheruser> petertodd: how would that not be a hard fork? You're changing the PoW
103 2014-04-24 04:35:19 <petertodd> justanotheruser: no, I'm adding additional conditions to the PoW - blocks valid under the system still look valid to old nodes
104 2014-04-24 04:36:25 <justanotheruser> petertodd: how? Wouldn't the target have to be changed significantly?
105 2014-04-24 04:37:06 <justanotheruser> Wouldnt the transition involve 1month blocks? (If not more)
106 2014-04-24 04:40:27 <petertodd> nope. So, the rule would still be H(blockheader) < target, but in addition there would be a new rule that, say, forced you to extract a random UTXO derived from the rest of the block such incrementing the extraNonce required a new UTXO extraction
107 2014-04-24 04:40:57 <gmaxwell> next hard fork? as if there had ever been a prior one?  (what we had with 0.8 vs older version wasn't really a hard fork— old nodes still run fine, they're just non-determinstically unreliable; most important all alternative implementations were wrong wrt 0.7 and the fixing of the database bug made them right)
108 2014-04-24 04:42:57 <justanotheruser> petertodd: wouldn't the bottleneck be on CPUs then?
109 2014-04-24 04:43:32 <justanotheruser> Or hard drives, more generally, non-asic hardware
110 2014-04-24 04:43:55 <petertodd> justanotheruser: not CPU's, disk storage. Basically you want the PoW to now prove not only that you had access to hashing power, but also some small, but not trivial, amount of IO bandwidth. The idea is the IO bandwidth is still a small part of the total cost of the PoW, but high enough that outsourcing it over a network is infeasible.
111 2014-04-24 04:45:34 <Belxjander> petertodd: along the order of requiring X amount of IO bandwidth through local means? as a scale difference from memory access? compared to block transfer over a network device with network traffic inconsistencies differentiating the network vs local-storage difference in timing?
112 2014-04-24 04:47:10 <petertodd> Belxjander: so cache->ram->ssd->disk->internet are something like an order of magnitude slower and higher latency each time, so forcing the UTXO set to be held locally without requiring custom hardware for it is quite possible
113 2014-04-24 04:47:16 <justanotheruser> petertodd: so what is controversial about this?
114 2014-04-24 04:47:50 <dgenr8> all the horsing around with scorched earth, fee bump, etc comes to a screeching halt at a random time, when next block is found
115 2014-04-24 04:47:51 <petertodd> Belxjander: basically one way of looking at it is to make low-latency access to the UTXO set a requirement to mine - speed of light ensures that access is local to the hashing power
116 2014-04-24 04:48:05 <Belxjander> petertodd: well...not exactly...how do you differentiate a dedicated local network or FibreChannel Storage unit which is networked compared to local disk storage that is actually attached ?
117 2014-04-24 04:48:19 <dgenr8> a predictable time, such as t=0, would be saner
118 2014-04-24 04:48:33 <petertodd> justanotheruser: lots of miners have rasberry pi's controlling their hashing power for starters, and secondly there are interests who would rather mining become more, rather than less, centralized
119 2014-04-24 04:48:44 <petertodd> Belxjander: latency is one way
120 2014-04-24 04:49:13 <petertodd> dgenr8: you have to work within the limitations of the system - decentralized consensus just can't come to consensus reliably in a short period of time and still be decentralized
121 2014-04-24 04:49:27 <Belxjander> petertodd: I've seen HDD and SSD storage times that have exceeded LAN storage times for specific use-cases and that was a local dedicated network setup for the storage caching
122 2014-04-24 04:49:35 <justanotheruser> Well its nice to know that's not a hard fork in case its ever necessary
123 2014-04-24 04:50:01 <petertodd> Belxjander: so what? that's a *local* area network
124 2014-04-24 04:50:27 <Belxjander> 
ACTION is also using a machine that right now has a latency time for hard-disks that is actually *slower* than the latency time for the dual-ethernet ports on the motherboard

125 2014-04-24 04:50:29 <petertodd> Belxjander: if some miner wants to borrow someone elses UTXO set in the same neighborhood, I don't really care much
126 2014-04-24 04:51:11 <Belxjander> petertodd: I'm considering on the same machine but yes...the Local vs InterNET latency times will screw with the prioritization scheme you gave above
127 2014-04-24 04:51:43 <justanotheruser> Belxjander: then there is an incentive for miners to have decent non-asic hardware aswell
128 2014-04-24 04:51:50 <petertodd> Belxjander: but like I said, you can build a system where the UTXO set *must* be within, say, 50km of the miner by simple speed of light calculations, that's fine and still a big improvement over what we have right now
129 2014-04-24 04:52:26 <petertodd> Belxjander: in reality, because network bandwidth isn't free, they'll probably have it locally, even better
130 2014-04-24 04:52:33 <Belxjander> petertodd: so you just want to limit the distance to reasonably local...
131 2014-04-24 04:52:37 <petertodd> yup
132 2014-04-24 04:53:10 <Belxjander> petertodd: sorry...I was reading what you said as "more immediate" based on CPU->memory CPU->serialized-transfer-to-another-machine latency differences
133 2014-04-24 04:53:26 <Belxjander> hrmmm]
134 2014-04-24 04:53:55 <Belxjander> then it would actually be practical for me to setup a whole raspi stack and dedicatedly have them mine to a "node" controller on this machine which gates it to the Internet
135 2014-04-24 04:54:08 <Belxjander> but then I still have the pre-requirement of portation to a PowerPC host
136 2014-04-24 04:54:16 <dgenr8> petertodd: I agree with that statement but don't know why you made it
137 2014-04-24 04:54:51 <petertodd> Belxjander: indeed, end goal is only to ensure that the UTXO set is widely distributed after all
138 2014-04-24 04:54:57 <Belxjander> anything with a latency less than 1 whole second?
139 2014-04-24 04:55:27 <petertodd> Belxjander: well, as a side effect that also ensures that miners have to actually have it to mine - you can mine without validating or even having blockchain data right now
140 2014-04-24 04:55:43 <Belxjander> then again I can feed out the blockchain to SATA+2xEthernet-TX+Dedicated-Local-Hardware attached to a Geekport within a 1second timeframe
141 2014-04-24 04:55:57 <justanotheruser> petertodd: so would the utxo need to be queried every time you tried to hash the block?
142 2014-04-24 04:56:17 <petertodd> Belxjander: probably more like milliseconds - speed of light * 1ms is 300km
143 2014-04-24 04:56:30 <Belxjander> petertodd: I would personally insist on a full blockchain and have a SHA512 sum of the blockchain per-block key as an additional index for validation purposes
144 2014-04-24 04:56:33 <petertodd> Belxjander: note too that what I said above doesn't actually directly prove latency... it's a bit more involved
145 2014-04-24 04:56:46 <Belxjander> so you have to have at least 1 local copy of that index AND the blockchain to generate it
146 2014-04-24 04:57:07 <dgenr8> petertodd: the vandalism analogy is not apropos.  from merchant's point of view, scorched earth or not, he got ripped off 1 latte
147 2014-04-24 04:57:09 <petertodd> Belxjander: there's some interesting tradeoffs re: validation there
148 2014-04-24 04:57:58 <petertodd> dgenr8: right, and 1 latte isn't worth much, so eating the cost due to vandals isn't a big deal so long as it there's no direct incentive to do it. of course, with gambling sites, that's not an issue as the fraudster actively loses a bunch of money
149 2014-04-24 04:58:35 <petertodd> justanotheruser: basically, querying proves bandwidth, querying *twice* can be used to prove low-latency
150 2014-04-24 04:59:18 <dgenr8> petertodd: fraudster has nonzero chance of success and worst case is he pays for his purchase
151 2014-04-24 05:00:35 <justanotheruser> petertodd: I don't understand your answer? Is it H(H(Block header)|UTXO decided from H(block header))?
152 2014-04-24 05:00:37 <petertodd> dgenr8: yes, and like I said, there's real-world costs involved here in the physical example, and if that's not enough you can do things like require your customer to pay some % extra, then refund them after the confirmation goes through. fidelity bonds can be used as well
153 2014-04-24 05:01:17 <petertodd> justanotheruser: you're trying to force the UTXO set to be queried often as part of the mining process - that's what proves bandwidth
154 2014-04-24 05:01:50 <petertodd> justanotheruser: proving latency is a bit more tricky, but essentially you need two queries that are dependent in the right way
155 2014-04-24 05:02:45 <justanotheruser> petertodd: is the order of how the block would be set and how the tx would be selected concrete?
156 2014-04-24 05:02:58 <dgenr8> petertodd: if merchants like a world where fraud is deterred by commonplace scorched-earth, they will like a world where first spends are final much better
157 2014-04-24 05:03:08 <justanotheruser> *block would be hashed
158 2014-04-24 05:03:49 <petertodd> justanotheruser: yes, it has to be carefully designed and deterministic to ensure shortcuts aren't possible
159 2014-04-24 05:04:11 <petertodd> dgenr8: I'm sure they would, but they're asking for somehting impossible in a decentralized system, so we're going to have to give them the next best thing
160 2014-04-24 05:04:57 <dgenr8> petertodd: the next best thing is a world where respend success probability diminishes with time, on a time horizon much shorter than inter-block time
161 2014-04-24 05:05:27 <petertodd> dgenr8: I know that; I'm sorry, but that's just not possible
162 2014-04-24 05:06:15 <dgenr8> petertodd: actually we're not that far from it now.  there is eligius' self-defeating behavior.  but he will come around
163 2014-04-24 05:06:26 <gmaxwell> dgenr8: uh thats not correct at all.
164 2014-04-24 05:06:32 <gmaxwell> really this bitcoin 101 stuff does not belong here.
165 2014-04-24 05:07:22 <gmaxwell> please move it to #bitcoin
166 2014-04-24 05:07:32 <petertodd> dgenr8: I'm sure in five years this bitcoin 101 stuff will be better understood by the non-academics, but in the meantime, keep in mind that there's a lot of people with really basic misunderstandings of the technology around
167 2014-04-24 05:08:02 <gmaxwell> 
ACTION pushes people towards #bitcoin

168 2014-04-24 05:08:08 <Belxjander> I know there is a lot about cryptocurrencies that I simply have no knowledge of
169 2014-04-24 05:08:15 <robonerd> who can haz help me mine bit coins with my game boy!?
170 2014-04-24 05:08:52 <Belxjander> obonerd: not me
171 2014-04-24 05:09:41 <dgenr8> gmaxwell: after putting many hours in #3883 including code specifically at yours and petertodd's request, that just seems a bit harsh
172 2014-04-24 05:10:24 <petertodd> dgenr8: it took me about one year of part-time study to understand bitcoin competently
173 2014-04-24 05:10:38 <justanotheruser> petertodd: I'm confused how you can have a UTXO querying PoW where your bottleneck isn't the hard disk?
174 2014-04-24 05:11:09 <gmaxwell> dgenr8: You're saying things which are _physically_ precluded, I wasn't attempting to be harsh.
175 2014-04-24 05:11:11 <Belxjander> petertodd: any recommendable guide for the bitcoin client sources as to what the layout entails or is it all just digging in and getting familiar with the layout?
176 2014-04-24 05:11:18 <petertodd> justanotheruser: it's not that your bottleneck isn't your hard disk, it's that the *cost* of *sufficient* io bandwidth is a small % of the total cost of your mining setup
177 2014-04-24 05:11:51 <Belxjander> petertodd: damm...I definitely need to talk with you more properly about this
178 2014-04-24 05:12:24 <petertodd> Belxjander: yeah, just dig in IMO. I'd suggest tracing what happens when a block is received for instance. you might find reading my python-bitcoinlib sources helpful too - easier to directly experiment with w/ regard to scripting functionality
179 2014-04-24 05:12:26 <Belxjander> as I know of at least two physical devices where the IO latency is very very small and they are both independently network capable seperate from the host
180 2014-04-24 05:12:41 <Belxjander> petertodd: what version of python is essential for those?
181 2014-04-24 05:13:05 <Belxjander> 
ACTION can't actually compile or build the original bitcoin-qt as-is without needing to get to grips with it...

182 2014-04-24 05:13:09 <petertodd> Belxjander: works on 2.7 and 3.3 (3.4 apparently has some issues right now, pull-reqs much appreciated!)
183 2014-04-24 05:13:21 <Belxjander> I lack qt AND recent boost libraries with the proper build requirements
184 2014-04-24 05:13:29 <petertodd> Belxjander: install a copy of ubuntu in a VM
185 2014-04-24 05:13:41 <petertodd> Belxjander: quite seriously for security reasons I do my development in VM's
186 2014-04-24 05:13:51 <Belxjander> petertodd: no VM software on this machine...so any kind of assumption that will work falls flat :)
187 2014-04-24 05:14:12 <Belxjander> petertodd: I have an AmigaOS desktop and an Android tablet for my own personal use
188 2014-04-24 05:14:21 <petertodd> Belxjander: crazy nutter :P
189 2014-04-24 05:14:26 <gmaxwell> dgenr8: a person with private key A gives pays for a latte in LA, another person with the same private key A pays for dinner in new zealand, both at the same moment with the same coin. At that instant they are both outside of each others light cones. Both reciepents believe they have valid spends. But only one can. The first spend cannot be guaranteed to be valid instantly. The whole defintion of 'first' doesn't even have a well formed ...
190 2014-04-24 05:14:29 <Belxjander> AMCC440EP processor in the AmigaOS desktop
191 2014-04-24 05:14:32 <gmaxwell> ... meaning in a fully decenteralized system.
192 2014-04-24 05:14:47 <Belxjander> petertodd: well... PPC and ARM,... nothing Intel in sight here
193 2014-04-24 05:15:06 <gmaxwell> dgenr8: you can do better or worse, but the claim you made about it being close is really untrue, regardless of any miners.
194 2014-04-24 05:15:11 <dgenr8> gmaxwell: perfectly understood.  now relax "instantly"
195 2014-04-24 05:15:20 <Belxjander> 
ACTION will probably have to dig up some kind of box and stick the AMD64 board in the closet into it with a HDD and PSU to use that over a network link then

196 2014-04-24 05:15:24 <gmaxwell> dgenr8: and eligius' policy is absolutely irrelevant to this discussion.
197 2014-04-24 05:16:10 <petertodd> dgenr8: not how re: gmaxwell's great example, the only reason replace-by-fee scorched-earth works is because it's *reactive* Same idea roughly as coinbase reallocation really, but done in a way that only harms the double-spender rather than quite possibly innocent third-parties.
198 2014-04-24 05:16:40 <Belxjander> gmaxwell: in a well formed decentralized system there is no "first..." anything... there is only "point of event" and the "radius of knowledge" as a waveform from that point with anything within the raduis from the event consolidating the event occurance afaik
199 2014-04-24 05:17:17 <Belxjander> stones in a pond...watch the ripples in the water
200 2014-04-24 05:17:30 <dgenr8> as the time between the first and second spends grows, the probability of observers forming different opinions of which was first diminishes
201 2014-04-24 05:17:53 <Belxjander> two stones with seperate ripples in the water...do the waves negate or modify ?
202 2014-04-24 05:18:11 <gmaxwell> dgenr8: Consider, those conflicting transactions announced concurrently to differing parties— some are going to consider one first, some are going to consider the other first. No special difference in forwarding policy is required to result in a difference in mempool, just a difference in location from which you view the rest of the universe.
203 2014-04-24 05:18:51 <dgenr8> at inter-transaction time of 1 minute, it's quite unlikely that any observers will have a different opinion
204 2014-04-24 05:18:59 <gmaxwell> dgenr8: what time between? the attacker is free to choose any offset he wants. (or even absent an attacker, chance is free to choose any offset)
205 2014-04-24 05:19:09 <Belxjander> gmaxwell: time-of-day and timezones comes to mind as a question of seperation based on location there ... would that have any kind of effect?
206 2014-04-24 05:20:17 <dgenr8> merchant waits 1 minute before handing over goods.  any double spend that follows will be seen as such by vast majority of observers.
207 2014-04-24 05:21:49 <gmaxwell> dgenr8: there is no requirement that the double spend ever be relayed outside of a block.
208 2014-04-24 05:22:17 <gmaxwell> (also,fwiw, we frequently see 90th percentile network saturation times for transactions over one minute)
209 2014-04-24 05:22:22 <Belxjander> dgenr8: to me that would be walking into the store and swiping to make a purchase with my wallet and then swiping the item through the register to clear it and waiting for the register to confirm/deny the transaction for the item,  Japanese style of swiping out on the same floor of the shopping center as the item is f
210 2014-04-24 05:22:22 <Belxjander> ound to buy it...and then having an extra step of swiping the item out of inventory at the main doors ?
211 2014-04-24 05:22:54 <dgenr8> gmaxwell i admit to holding the belief that reference client has actual sway over network behavior
212 2014-04-24 05:23:03 <Belxjander> hang-on... what is the time-delay required for the majority of the network to actively see a transaction before it is "mined"?
213 2014-04-24 05:23:11 <petertodd> gmaxwell: yup! replace-by-fee-using double-spends work occasionally even when both tx's have high fees due to imperfect network relaying
214 2014-04-24 05:23:21 <petertodd> Belxjander: 0s
215 2014-04-24 05:23:42 <gmaxwell> dgenr8: I don't believe most hashpower is currently directly running the github.com/bitcoin  reference client.
216 2014-04-24 05:23:57 <Belxjander> petertodd: the whole network see's every spend immediately?... what about your latency where 1s = 300km of network travel distance?
217 2014-04-24 05:24:04 <sipa> dgenr8: and the reference client does not relay double spends
218 2014-04-24 05:24:06 <petertodd> dgenr8: note how I've been able to greatly improve the chances of double-spends getting mined by running just *four* replace-by-fee nodes
219 2014-04-24 05:24:16 <gmaxwell> sipa: he's been working on a pull req for that.
220 2014-04-24 05:24:25 <dgenr8> gmaxwell: if true, and I don't doubt you, doesn't necessarily invalidate my naive belief
221 2014-04-24 05:24:38 <gmaxwell> no, I was just adding some extra data.
222 2014-04-24 05:24:44 <Belxjander> petertodd: I definitely have to talk with you about how the bitcoin client works
223 2014-04-24 05:24:51 <petertodd> Belxjander: all it takes is one miner seeing the tx and finding a block with it, so yes, ~0s is your lowerbound
224 2014-04-24 05:25:03 <gmaxwell> I'm not quite sure it's greater than 50% but a large portion (certantly over a third) runs luke's fork.
225 2014-04-24 05:25:12 <sipa> dgenr8: and even if it did, the second transaction would not relay well if it did not follow standardness rules (but was perhaps sent tonsome miners that are known not to follow those directly)
226 2014-04-24 05:25:43 <gmaxwell> Standardness rules by their nature aren't consistent, they're not even consistent in the reference implementation when we upgrade them.
227 2014-04-24 05:25:46 <Belxjander> petertodd: well I will need to have a list of "core functions" that are in whatever core library the default client uses...and then work out what is essential from after that point
228 2014-04-24 05:25:57 <gmaxwell> Wrt transaction propagation times, this is the kind of data I was referring to: http://bitcoinstats.com/network/propagation/2014/01/25
229 2014-04-24 05:26:06 <dgenr8> sipa: i understand that issue and agree it is a big concern
230 2014-04-24 05:26:43 <sipa> dgenr8: i think it completely undermines the abilityg to reliably detect double spends
231 2014-04-24 05:27:38 <dgenr8> sipa: ask it the other way .. why do 92% of miners mine first spend?
232 2014-04-24 05:28:06 <petertodd> dgenr8: what makes you think it's 92%
233 2014-04-24 05:28:17 <dgenr8> petertodd: your 8% number for eligius
234 2014-04-24 05:28:45 <petertodd> dgenr8: eligius mines first seem modulo what they blacklist
235 2014-04-24 05:28:49 <petertodd> *seen
236 2014-04-24 05:28:57 <gmaxwell> dgenr8: I don't think thats a useful question. An attack always picks the boundary.  E.g. you could have 99.9999% of the pixels on your website that do nothing, and one pixel that if you click it sends the clicker 1 btc. The average payment per pixel is very low, 0.000001 btc or whatever. And yet if you deployed that you'd be broke overnight. :)  Attacks and failures care little about the average case.
237 2014-04-24 05:29:27 <petertodd> dgenr8: here, give me a bitcoin address and I'll show you
238 2014-04-24 05:29:29 <gmaxwell> dgenr8: huh? eligius mines the first transaction they accept.
239 2014-04-24 05:29:50 <petertodd> dgenr8: android wallet shows it well
240 2014-04-24 05:30:26 <gmaxwell> I'd pointed this out on the pull req. _No_ miners mine the first spend they see, most (we believe) mine the first they accept.
241 2014-04-24 05:31:17 <dgenr8> my main belief is that there is nothing bad about relaying respends, and it may enable good things
242 2014-04-24 05:31:17 <gmaxwell> Acceptance rules aren't completely uniform, even without people running different code, bitcoind has commandline flags that influence them and some pool server software influences them too.
243 2014-04-24 05:32:31 <gmaxwell> I don't have any issue with relaying respends, so long as its done in a way that doesn't itself form a dos attack vector. Though I do have some concern that people may think it provides security that it does not, and as a result it will make some people at greater risk— but I don't think thats a reason not to do it.
244 2014-04-24 05:33:04 <petertodd> dgenr8: yes, relaying respends can let miners learn about those respends and mine them...
245 2014-04-24 05:33:15 <gmaxwell> It will greatly enable 'greedy-rational' behavior by miners, making sure they know about more profitable doublespends.
246 2014-04-24 05:33:22 <gmaxwell> (mixed blessing there!)
247 2014-04-24 05:33:47 <dgenr8> transparency
248 2014-04-24 05:34:31 <dgenr8> as I said on the mailing list, I don't believe mining double spends is rational, greedy or not
249 2014-04-24 05:35:05 <gmaxwell> I think I didn't communicate effectively there by greedy I mean it in the algorithims sense, favoring the immediate benefit.
250 2014-04-24 05:35:25 <sipa> dgenr8: by greedy-rational we usually mean excluding any reasoning lijke "this will make tge system less valuable, so it is bad for me", as it is very badly quantifiable
251 2014-04-24 05:35:39 <gmaxwell> in any case I don't care to debate that— I'm just pointing out from a purely technical perspective providing the data enables it.
252 2014-04-24 05:36:11 <sipa> dgenr8: or in other words: if you include that as an absolute reason, nobody woukld ever steal a bitcoin, because a system where bitcoins aren't ever stolen is more valuable
253 2014-04-24 05:36:42 <dgenr8> understood.  do private payment processors have private respend relay networks?
254 2014-04-24 05:37:04 <dgenr8> i also see this as a democratization of that capability
255 2014-04-24 05:37:11 <gmaxwell> dgenr8: I'd certantly like to take you to the next meeting I have with starry eyed mining business people who have a 24 month plan that (in their figuring) results in them having 75% of the total network hashpower. :)
256 2014-04-24 05:37:50 <gmaxwell> dgenr8: I've seen no evidence of that, but indeed, I'd rather the network provide it than people try to do crazy things like connect to all nodes— which doesn't scale.
257 2014-04-24 05:37:55 <dgenr8> gmaxwell: with that, who needs a few extra fees
258 2014-04-24 05:38:21 <dgenr8> I have a node on mainned relaying respends.  It has seen 125 in the last 4 days
259 2014-04-24 05:38:24 <dgenr8> mainnet
260 2014-04-24 05:38:36 <gmaxwell> dgenr8: Yes but its not my point, a single company controlling 75% of the hashpower would _throughly_ undermine the security model and would rightfully erode confidence in bitcoin.
261 2014-04-24 05:38:43 <petertodd> dgenr8: oh, with my replace-by-fee patch?
262 2014-04-24 05:38:59 <dgenr8> no, with my respend relay patch
263 2014-04-24 05:39:06 <petertodd> dgenr8: oh right, that one
264 2014-04-24 05:39:23 <gmaxwell> dgenr8: I'm surprised you've seen that many. Did you see which peers were giving them to you?
265 2014-04-24 05:39:35 <dgenr8> next step is to add that logging
266 2014-04-24 05:39:39 <sipa> dgenr8: reliably detecting double spends only works if you learn about all of them
267 2014-04-24 05:39:45 <petertodd> gmaxwell: there appears to be people who have already implemented replace-by-fee fee-bumping
268 2014-04-24 05:39:55 <gmaxwell> are you also comparing conflicts vs the blockchain itself? ... there should be a lot more there.
269 2014-04-24 05:40:12 <petertodd> dgenr8: to bitcoind getpeerinfo | grep 04000 on that node for me...
270 2014-04-24 05:40:20 <gmaxwell> petertodd: more likely increased minfee.
271 2014-04-24 05:40:23 <dgenr8> petertodd: lets examine the txes before reaching that conclusion
272 2014-04-24 05:40:41 <sipa> dgenr8: please do not assume the current behaviour on the network won't ever change
273 2014-04-24 05:41:05 <dgenr8> gmaxwell: no .... gavin's code is not reached when conflict is in the chain
274 2014-04-24 05:41:28 <sipa> dgenr8: if subsidies go down, and fees become more relevant, i am sure that the incentive for wanting highest fee instead of first will go up
275 2014-04-24 05:41:37 <gmaxwell> dgenr8: ah okay, makes sense to me, so the only ones you should see is when someone has non-default policy of if there is a face.
276 2014-04-24 05:41:42 <gmaxwell> er, s/face/race/
277 2014-04-24 05:42:09 <dgenr8> sipa: yes, i hope eveyone sees the wisdom of final-at-submission long before then
278 2014-04-24 05:42:15 <petertodd> gmaxwell: yup, seen a few that aded 0.1mBTC. Also looks like some wallets double-spend by accident too
279 2014-04-24 05:42:34 <sipa> dgenr8: and if your patch is widely deployed, people will just do double spends where one of them wikll badly propagate
280 2014-04-24 05:42:41 <petertodd> dgenr8: I'm asking you to check for me if my replace-by-fee node is connected to your relay node
281 2014-04-24 05:43:26 <dgenr8> petertodd: mine is 54.186.233.100
282 2014-04-24 05:43:43 <petertodd> dgenr8: I've got a few replace-by-fee, easier if you check on your side
283 2014-04-24 05:44:15 <gmaxwell> sipa: plus you have things like people double spending with greater fees to speed up an non-confirming transaction.
284 2014-04-24 05:44:22 <sipa> dgenr8: on a private network, where you don't need to trust the sender, you can instead just relay the txins being double-spent (as you don't need proof they are actually do double spend)
285 2014-04-24 05:44:48 <sipa> dgenr8: which has much lower worst case resource requirements
286 2014-04-24 05:46:35 <dgenr8> sipa: yes that is luke-jr's point but at least it may focus attention on the miners that accept those txes ... the first spends are public
287 2014-04-24 05:47:06 <gmaxwell> but ... there is no such thing as first. :(
288 2014-04-24 05:48:01 <dgenr8> gmaxwell: the charts and percentiles don't seem to agree on that page
289 2014-04-24 05:48:13 <sipa> ...?
290 2014-04-24 05:49:30 <gmaxwell> dgenr8: they do, it's just a long tail and the end runs off the chart notice the peak of the spike is not very high. (p=0.18 ir so)
291 2014-04-24 05:50:21 <sipa> what are you talking about?
292 2014-04-24 05:50:45 <dgenr8> the pdf of transaction chart seems to be at zero but who am i to judge.
293 2014-04-24 05:50:46 <gmaxwell> sipa: the cdecker transaction propagation data.
294 2014-04-24 05:51:08 <sipa> sigh
295 2014-04-24 05:51:43 <sipa> as i said: if your patchnis widely deployed, and used to detect double spends, it will change attacker's behaviour to avoid it
296 2014-04-24 05:51:44 <gmaxwell> Though thats not material to there not being a first. There really isn't a first. Even if the prop time was 1 second, transactions can be announced concurrently.
297 2014-04-24 05:51:47 <dgenr8> an interested merchant will make some attempt to be well-connected
298 2014-04-24 05:52:00 <gmaxwell> Expirence doesn't support that.
299 2014-04-24 05:52:03 <gmaxwell> (at least not so far)
300 2014-04-24 05:52:18 <gmaxwell> The people who try seem to mostly do ignorant things that the network couldn't support in any case.
301 2014-04-24 05:52:39 <sipa> i think reliable double-spsnd detection is only possible in a network with severaln trusted nodes
302 2014-04-24 05:52:51 <dgenr8> sipa: i'm sure attackers will try to adapt, yes
303 2014-04-24 05:53:15 <petertodd> dgenr8: note how double-spend detection can incentivize attackers to attack the network...
304 2014-04-24 05:53:42 <sipa> and yes, the double spend relays introduce their own resource usage and dos potential
305 2014-04-24 05:54:00 <dgenr8> #3883 mentions a paper with 3 concrete recommendations: merchants being well connected, a merchant waiting period, and respend alerts
306 2014-04-24 05:55:29 <sipa> and, if those have 0 cost on their own, they are certainly good ideas
307 2014-04-24 05:55:55 <petertodd> dgenr8: paper ≠ good
308 2014-04-24 05:56:19 <dgenr8> petertodd: don't put words in my mouth ;)
309 2014-04-24 05:56:55 <dgenr8> but they did actually test these things
310 2014-04-24 05:57:02 <gmaxwell> dgenr8: would that be the paper that goes on at length basically blowing up the claims on Bitcoin wiki showing that they don't work, and sort of mocking the bitcoin community? :P
311 2014-04-24 05:57:22 <sipa> dgenr8: i am only saying that to someone who wants to double spend, your limited double spends provides little proection
312 2014-04-24 05:57:55 <dgenr8> sipa: alone, no.  piece of the puzzle
313 2014-04-24 05:58:08 <sipa> what else?
314 2014-04-24 05:59:00 <dgenr8> i don't see how the network can ever support real-time transactions unless submitters consider txes final at submission
315 2014-04-24 05:59:49 <dgenr8> and I guess I think that is more important than the use cases for altering transactions
316 2014-04-24 06:00:54 <sipa> i do not think the network can support reakl time transactions *reliably* at all
317 2014-04-24 06:01:02 <petertodd> You know, with all the amazing things that Bitcoin makes possible, the fact that people are so incredibly concerned about being able to support fast transactions at the expense of other important goals is bizzare.
318 2014-04-24 06:02:43 <Belxjander> petertodd: for the same reason that "speed" tumped quality in the choice of what CPU out of all the CPU families became "popular" seems a plausible "speed first, quality later" approach generalyl
319 2014-04-24 06:02:46 <Belxjander> generally
320 2014-04-24 06:05:28 <petertodd> Belxjander: indeed, and kinda sad. OTOH, good reason to implement more of those amazing things :)
321 2014-04-24 06:06:16 <Belxjander> petertodd: well I will just have to finish the AmigaOS IME I am working on...
322 2014-04-24 06:06:34 <warren> https://bitcointalk.org/index.php?topic=582345.0  If you know Bitcoin users who are a native speaker of non-English languages could you please refer them here?
323 2014-04-24 06:06:56 <Belxjander> right now I need to sort out a Unicode UTF-8 output based on any arbitrary string input giving me a chorded-search-key arrangement
324 2014-04-24 06:07:21 <Belxjander> warren: I speak English but I am learning Japanese at the moment...
325 2014-04-24 06:07:47 <warren> technical Japanese is not easy to do if you aren't good at Japanese
326 2014-04-24 06:07:53 <Belxjander> warren: and no...I don't generally visit the bitcointalk forums for any reason
327 2014-04-24 06:08:05 <warren> it's written to bitcoin dev list too
328 2014-04-24 06:08:19 <Belxjander> warren: well I am learning to read Kanji and however technical it gets I seem to have no real issues with it
329 2014-04-24 06:08:37 <warren> https://www.transifex.com/projects/p/bitcoin/  Here's the language coverage.  anything less than 100% needs volunteers.
330 2014-04-24 06:09:48 <sipa> warren: it is not really advisable that people translate to anything but their native language imho
331 2014-04-24 06:09:55 <warren> sipa: right
332 2014-04-24 06:10:35 <warren> Belxjander: native Japanese speakers often can't translate technical things properly
333 2014-04-24 06:10:58 <sipa> of course, many people have a second language that they are more than proficient in
334 2014-04-24 06:41:30 <dgenr8> petertodd: how important can those other goals be, if you can accept them being terminated when a block is found?
335 2014-04-24 06:45:17 <dgenr8> sipa: so, you like respend detection, but so far don't believe it should be a capability of the bitcoin network itself?
336 2014-04-24 06:49:17 <Emcy> they wont put first DS relaying in
337 2014-04-24 06:49:29 <Emcy> (some good reasons for that though it seems)
338 2014-04-24 06:49:57 <gmaxwell> dgenr8: I'm confused about your last comment to petertodd.
339 2014-04-24 06:51:45 <gmaxwell> dgenr8: he means goals like decenteralization, trustlessness, autonomy, and things like that. Imposing a lot of attempted behavioral controls and things like blacklists for the coins of naughty people can be seen as not very compatiable with the idea being that the system works because of math and inherent motivations instead of regulations.
340 2014-04-24 06:51:59 <sipa> dgenr8: i don't think the public network (which has far stronger DoS protection necessities and must function with bad actors participating) _can_ reliably offer double spend detection
341 2014-04-24 06:52:28 <dgenr8> gmaxwell: i read it as things like ability to bump fees.  At a random moment, you lose that ability.
342 2014-04-24 06:54:32 <gmaxwell> dgenr8: being able to choose the fees for transactions you include in blocks you create (and also take the orphan risk for) isn't at odd at not being able to choose the fees in blocks other people create. You still speak your mind in your portion of the blocks.  (and its not like we can take away that ability to choose in any case)
343 2014-04-24 06:55:52 <dgenr8> gmaxwell: i thought replace by fee referred to anyone being able to bump fees on their spends, not just the tiny minority who are miners
344 2014-04-24 06:57:05 <gmaxwell> By bump fees I thought you meant miners being able to choose the fees they accept. As far as replacement with other fees, well— thats not a minor feature, since thats whats you need to do to pay the lowest fees on the fee market if you don't care about the transaction being fast.
345 2014-04-24 06:58:01 <gmaxwell> (you pay low fees and then if it doesn't go through in an acceptable time you increase them, like a reverse auction)
346 2014-04-24 06:58:01 <sipa> s/minor/miner/ ?
347 2014-04-24 06:58:19 <gmaxwell> hah no minor!
348 2014-04-24 07:04:36 <dgenr8> gmaxwell: can a fee bump be accomplished with a child transaction?
349 2014-04-24 07:05:45 <sipa> dgenr8: in your latest mail, you mean every transaction needs to have a hash of _the_ previous transaction?
350 2014-04-24 07:08:23 <dgenr8> sipa: last known transaction on the highest-fee chain of unconfirmed transactions
351 2014-04-24 07:09:31 <sipa> who puts it there?
352 2014-04-24 07:11:13 <dgenr8> sipa: tx creator, or his agent, by inspecting mempool.  please see that as an idealized musing and not some kind of proposal.
353 2014-04-24 07:11:41 <sipa> dgenr8: yes, i saw you consider it a bad idea
354 2014-04-24 07:12:04 <sipa> dgenr8: but there are way worse reasons why that can't work
355 2014-04-24 07:12:45 <sipa> dgenr8: in particular, if transactions take (let's say) 10s to propagate across the network, you can only do an average of 1 transaction per 10 seconds
356 2014-04-24 07:13:17 <dgenr8> sipa: yes, that is the big one I am aware of.  others?
357 2014-04-24 07:14:07 <sipa> hmm, that was not what i read as your reason
358 2014-04-24 07:14:13 <sipa> never mind if that is what you meant
359 2014-04-24 07:17:02 <sipa> anyway, it also requires every sender to have a consistent view of miner's memory pools
360 2014-04-24 07:18:10 <sipa> which really means you need very low latency across the network, otherwise by the time a miner sees your transaction (chain), it will already be far behind on accumulated fees the miner has
361 2014-04-24 07:18:19 <sipa> in its best chain
362 2014-04-24 07:18:41 <dgenr8> sipa: although network relay gives bad actors information, it gives everyone information
363 2014-04-24 07:19:14 <sipa> which, even if you slow transactions down enough to make this not a problem, means you exclude any type of non-full node from producing transactions
364 2014-04-24 07:19:27 <sipa> in particular, no offline transaction signing
365 2014-04-24 07:19:29 <dgenr8> sipa: sorry that was not on txchain topic
366 2014-04-24 07:20:08 <sipa> dgenr8: the information isn't bad
367 2014-04-24 07:20:21 <sipa> dgenr8: it's the fact that it has costs associated with it, and little guarantees
368 2014-04-24 07:21:03 <dgenr8> sipa: today a very naive double spend can work
369 2014-04-24 07:21:07 <sipa> and if you trim it down to have little costs (rate limit, not relay nonstandard doublespends, ...), it becomes trivial to circumvene
370 2014-04-24 07:21:24 <sipa> dgenr8: it only needs one smart cow to figure out how to circumvene
371 2014-04-24 07:21:50 <sipa> preventing only against the least technically competent attacker isn't very useful
372 2014-04-24 07:22:05 <dgenr8> sipa: it currently does not relay nonstandard
373 2014-04-24 07:22:16 <sipa> i know
374 2014-04-24 07:22:26 <sipa> which is necessary, otherwise it becomes a dos vector
375 2014-04-24 07:23:10 <sipa> but with it, the information you get is "nope, i haven't heard about any double spends on this... wait, except if the double spend is nonstandard!"
376 2014-04-24 07:23:15 <dgenr8> someone asked me how common successful respends are
377 2014-04-24 07:23:44 <dgenr8> my answer was about as common as real time merchants taking bitcoin
378 2014-04-24 07:24:23 <gmaxwell> I don't see why you relate the two?
379 2014-04-24 07:25:17 <dgenr8> gmaxwell: could they not be accepting it, because they have analyzed the risks?
380 2014-04-24 07:28:56 <dgenr8> sipa: to answer your question, yes, you would need a full-node agent, and oops, i had not thought of offline signing.  thank you for reading it.
381 2014-04-24 07:34:35 <dgenr8> exit
382 2014-04-24 07:36:58 <brookman32k> Hello. I am experimenting around with the JSON-RPC api in bitcoin-qt. When doing a number of "sendtoaddress" calls in a row (~50 transactions), bitcoin-qt is becoming incredibly slow/hanging. What is the reason for that?
383 2014-04-24 09:15:14 <michagogo> cloud|warren: hi
384 2014-04-24 09:15:21 <michagogo> cloud|(re: 04:27:34 <warren> michagogo|cloud: around?)
385 2014-04-24 09:23:19 <michagogo> cloud|04:53:37 <warren> sipa: btw, is it feasible to have secp256k1 (disabled by default) in 0.9.2? <-- Uh, it's impossible to *not* have secp256k1 in any release
386 2014-04-24 09:23:29 <michagogo> cloud|(unless you mean libsecp256k1 :-P)
387 2014-04-24 09:26:45 <wumpus> michagogo|cloud: you're always very literal
388 2014-04-24 09:33:40 <michagogo> cloud|wumpus: I'm aware
389 2014-04-24 09:42:58 <GAit> i was reading a pull request for a BIP which also discussed bip32 gap limits. Isn't there any inherit issue with using gaps with risking of reusing addresses?
390 2014-04-24 09:43:32 <brookman32k> In the rpc api, is it somehow possible to retrieve the unspent coins (i.e. balance) of an arbitrary (non wallet) address?
391 2014-04-24 09:44:03 <michagogo> cloud|brookman32k: no
392 2014-04-24 09:44:21 <michagogo> cloud|You need an index for that, which Bitcoin Core doesn't maintain
393 2014-04-24 09:44:34 <GAit> brookman32k: you could use electrum server for that
394 2014-04-24 09:44:39 <michagogo> cloud|(or a 3rd party)
395 2014-04-24 09:44:51 <brookman32k> michagogo|cloud: So to do that, I have to crawl every transaction and create my own index?
396 2014-04-24 09:45:04 <michagogo> cloud|If you want to do it locally, yes
397 2014-04-24 09:45:44 <brookman32k> I'll try that... thanks
398 2014-04-24 09:47:39 <brookman32k> How many transactions (txids) are there currently? I counted about 1.4M in the testnet.
399 2014-04-24 09:48:47 <michagogo> cloud|one sec
400 2014-04-24 09:49:18 <brookman32k> nvm. just found it. about 37M
401 2014-04-24 09:51:14 <michagogo> cloud|2014-04-24 09:25:16 UpdateTip: new best=00000000000000001f41ede42a5a6504a93d5f62bb4de47d3df1c5415fd4030e  height=297454  log2_work=78.185929  tx=37458163  date=2014-04-24 09:24:24 progress=0.999997
402 2014-04-24 10:16:35 <hearn> brookman32k: bitcoinj has a postgres backend that can answer queries of that form
403 2014-04-24 10:21:48 <GAit> is it me or is very hard to read a bitcoin dev mailing list thread from the beginning? the interface is brutal
404 2014-04-24 10:23:23 <GAit> actually not that bad, i should have used mail archive instead of sourceforge directly
405 2014-04-24 10:26:43 <wumpus> yes the gmane interface is better than sourceforge's
406 2014-04-24 10:28:45 <hearn> sourceforge sucks badly
407 2014-04-24 10:29:05 <hearn> it’d be great if we could move to either google groups, or maybe something like the D forum software. it has a nice ultra-fast web UI, mailing list and even NNTP support
408 2014-04-24 10:29:34 <hearn> but basically anything is better than sf.net at this point
409 2014-04-24 10:30:20 <wumpus> did you try the gmane interface? it has NNTP support as well, as well as two ways of showing things, of which one is very similar to google groups'
410 2014-04-24 10:30:43 <wumpus> http://dir.gmane.org/gmane.comp.bitcoin.devel
411 2014-04-24 10:30:57 <hearn> yeah gmane is ok too
412 2014-04-24 10:31:38 <GAit> wumpus: quite nice thanks :)
413 2014-04-24 10:31:50 <wumpus> I don't want to move the mailing list for this, it's public subscription and anyone can archive and display the posts in any way they want
414 2014-04-24 11:01:35 <bedeho> In getblocks message, is "@block locator hashes" a 32 byte char array? or is it 32*hash_count byte char array?
415 2014-04-24 11:03:59 <GAit> do you think a bip for bip0032 based multisignature wallets should be discussed separately from the current bip0032 structure thread?
416 2014-04-24 11:05:38 <GAit> maybe there's already a discussion i missed that concentrates on bip0032 multisig wallets
417 2014-04-24 11:18:39 <hearn> GAit: no bip yet. “multisig wallets” are complex, as you know :) best to wait for things to settle down before trying to standardise anything
418 2014-04-24 11:30:47 <GAit> hearn: i'm not particularly interested in rushing a bip about it but it would be interesting to discuss with a wider audiance the options available. I would like one day to import my multisig wallet anywhere i like by just passing with a metadata file host, master public key together with my mnemonics/seed and being able to change third party or wallet software easily. i.e. decouple them
419 2014-04-24 11:31:14 <hearn> divorce them :)
420 2014-04-24 11:32:58 <GAit> yeah something like that. some cheating function :D
421 2014-04-24 12:13:15 <sirk390> Hi all, I am trying to compile bitcoin 0.9.1 on centos, but have this bug saying " key.cpp:134:  `pkey != __null' failed".  It seems the default openssl doesn't contain the bitcoin ecdsa curve. To solve it, I downloaded and build the last version of open ssl, but after re-building bitcoins still picks up the system openssl. I tried to set the variables SSL_CFLAGS and SSL_CFLAGS, but I couldn't figure out how to use them... Is t
422 2014-04-24 12:15:13 <Luke-Jr> sirk390: your IRC client doesn't respect freenode's line limit, so that got cut off at ".. Is t"
423 2014-04-24 12:15:29 <Luke-Jr> sirk390: I believe warren and/or gmaxwell have fixed OpenSSL RPMs somewhere.
424 2014-04-24 12:17:53 <sirk390> Luke-Jr: I was saying I was trying to point bitcoin to my local version of openssl using SL_CFLAGS and SSL_CFLAGS
425 2014-04-24 12:18:38 <sirk390> Luke-Jr: but i couldn't figure out exactly how to do it. When I was setting those flags, bitcoin would find no ssl at all anymore
426 2014-04-24 12:18:55 <Luke-Jr> usually to control what libraries are linked at runtime, you need to run with LD_LIBRARY_FLAGS
427 2014-04-24 12:19:24 <Luke-Jr> what were you setting them to?
428 2014-04-24 12:20:06 <sirk390> Luke-Jr: I was setting  SSL_LIBS=-L/usr/local/lib64/ SSL_CFLAGS=-I/usr/local/include/
429 2014-04-24 12:21:13 <Luke-Jr> try SSL_LIBS='-L/usr/local/lib64/ -Wl,-rpath,/usr/local/lib64/ -lssl' SSL_CFLAGS='-I/usr/local/include/'
430 2014-04-24 12:21:36 <Luke-Jr> (the -rpath means you shouldn't need LD_LIBRARY_FLAGS at runtime)
431 2014-04-24 12:22:15 <Luke-Jr> also be sure you're setting these as configure options
432 2014-04-24 12:22:21 <Luke-Jr> eg, by running: ./configure SSL_LIBS='-L/usr/local/lib64/ -Wl,-rpath,/usr/local/lib64/ -lssl' SSL_CFLAGS='-I/usr/local/include/'
433 2014-04-24 12:22:26 <sirk390> Luke-Jr: Ok, thanks a lot, I will try
434 2014-04-24 14:20:24 <tyrick> anyone awake in here?
435 2014-04-24 14:20:38 <dhill> 5 more minutes mom
436 2014-04-24 14:42:31 <fanquake> ;;blocks
437 2014-04-24 14:42:32 <gribble> 297493
438 2014-04-24 14:54:57 <nezZario> Nothing like waking up in the morning and reading my bitcoin-dev
439 2014-04-24 14:55:21 <tyrick> ya
440 2014-04-24 14:55:23 <tyrick> devs
441 2014-04-24 14:55:38 <tyrick> yay. wake up, all
442 2014-04-24 14:55:45 <sipa> glad i slept through most of it :)
443 2014-04-24 14:56:04 <tyrick> 
ACTION so happy

444 2014-04-24 14:56:37 <fanquake> speaking of sleep. It's about that time.
445 2014-04-24 14:56:59 <jgarzik> hearn, what wiki page has that old bond market stuff on which I based pybond?  my search-fu is failing me.
446 2014-04-24 14:57:04 <sipa> fanquake.sleep(28800);
447 2014-04-24 14:57:09 <hearn> https://en.bitcoin.it/wiki/Distributed_markets
448 2014-04-24 14:57:16 <sipa> jgarzik: will you be in amsterdam?
449 2014-04-24 14:57:22 <jgarzik> sipa, yes
450 2014-04-24 14:57:24 <sipa> cool
451 2014-04-24 14:58:00 <tyrick> Although bitcoind.cpp has a main(), running bitcoind seems to not start at that main() function
452 2014-04-24 14:58:15 <tyrick> Where does this program start?
453 2014-04-24 14:58:26 <sipa> there
454 2014-04-24 14:58:29 <kinlo> tyrick: it does start at main(), why do you assume it doesn't?
455 2014-04-24 14:59:03 <tyrick> If I print out to a log on the first line of main, it isn't the first thing that prints out to the log file
456 2014-04-24 14:59:19 <fanquake> sipa No work tomorrow, can probably do without it tonight.
457 2014-04-24 14:59:20 <sipa> tyrick: constructors of global objects can be invoked before main()
458 2014-04-24 14:59:49 <hearn> openssl writeup - http://www.tedunangst.com/flak/post/worst-common-denominator-programming
459 2014-04-24 14:59:53 <kinlo> tyrick: you did print out correctly, coz opening the same file twice, with different buffers might mess up order
460 2014-04-24 15:00:01 <hearn> i think it must be the first time ever that anyone has actually looked at the code with a critical eye
461 2014-04-24 15:00:26 <tyrick> sipa: I see
462 2014-04-24 15:00:32 <sipa> hearn: i suddenly find a lot more support for work to remove our openssl dependency :)
463 2014-04-24 15:00:39 <hearn> indeed
464 2014-04-24 15:00:57 <hearn> i wish android didn’t use it to implement the java ssl api. sigh.
465 2014-04-24 15:01:00 <sipa> "i hated openssl before it was uncool"
466 2014-04-24 15:01:08 <nezZario> haha
467 2014-04-24 15:01:37 <hearn> lol
468 2014-04-24 15:01:39 <nezZario> sipa, what is to come of a replacement?
469 2014-04-24 15:01:40 <hearn> http://opensslrampage.org/
470 2014-04-24 15:01:46 <hearn> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/bn/bn_mont.c.diff?r1=1.17;r2=1.18
471 2014-04-24 15:01:48 <hearn> hilarious
472 2014-04-24 15:01:53 <hearn> tandem machines!
473 2014-04-24 15:02:28 <hearn> there are so many double free’s they’re fixing
474 2014-04-24 15:02:58 <jgarzik> sipa, lol
475 2014-04-24 15:03:28 <jgarzik> RE replacement, there is PolarSSL, which some people want me to use with my C library (picocoin / libccoin)
476 2014-04-24 15:04:20 <hearn> i bet all ssl libraries written in C suck and are full of bugs
477 2014-04-24 15:04:43 <hearn> also polarssl has cert parsing bugs: https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf
478 2014-04-24 15:04:56 <Diablo-D3> someone is writing a wrapper for nss to do the openssl api
479 2014-04-24 15:05:15 <nezZario> I don't fully understand what openbsd guys are doing to openssl.. I know they're not going to try to move the changs upstreame not going to move the changes upstream, so they're going tto just have a "openbsd version of openssl", right?
480 2014-04-24 15:05:22 <nezZario> OpenOpenSSL
481 2014-04-24 15:05:28 <Diablo-D3> nezZario: libressl
482 2014-04-24 15:05:36 <Diablo-D3> they're basically trolling the openssl guys
483 2014-04-24 15:05:47 <nezZario> I like openopenssl better :)
484 2014-04-24 15:05:51 <sipa> nezZario: for everything but ssl, easily
485 2014-04-24 15:06:05 <sipa> we use openssl mostly for bignum and base crypto stuff
486 2014-04-24 15:06:15 <sipa> ssl itself is another beast :(
487 2014-04-24 15:06:32 <sipa> but not necessary for just bitcoind (unless you need rpcssl)
488 2014-04-24 15:11:17 <nezZario> btw
489 2014-04-24 15:11:24 <nezZario> what was the pay to IP thing all about anyway?
490 2014-04-24 15:12:31 <hearn> you mean the feature in v0.1?
491 2014-04-24 15:12:52 <nezZario> yeah, did it ever even work?
492 2014-04-24 15:13:37 <Diablo-D3> I dont think it did
493 2014-04-24 15:13:39 <Diablo-D3> and it never made sense
494 2014-04-24 15:13:49 <hearn> i can’t recall if i tried it or not
495 2014-04-24 15:14:09 <hearn> i think it did work at least in 2009, but it didn’t get used much because back then bitcoin users were hardly online simultaneously
496 2014-04-24 15:15:00 <Diablo-D3> I don't remember it working
497 2014-04-24 15:15:10 <Diablo-D3> 
ACTION was actually around back then

498 2014-04-24 15:15:25 <hearn> did you try it?
499 2014-04-24 15:16:15 <Diablo-D3> You know, I can't remember
500 2014-04-24 15:16:46 <hearn> let’s assume satoshi did try it at least once and possibly nobody else did :)
501 2014-04-24 15:16:55 <hearn> it actually did have some advantages over pay to address
502 2014-04-24 15:17:02 <hearn> that’s why we brought it back in a more modern form
503 2014-04-24 15:17:26 <nezZario> hearn: brought it back as?
504 2014-04-24 15:17:29 <GAit> payment protocol
505 2014-04-24 15:17:56 <hearn> BIP 70
506 2014-04-24 15:25:59 <hearn> sipa: where was the discussion of your attempts to use merkleblocks for relaying by default/
507 2014-04-24 15:26:06 <hearn> i can’t find it anymore. it’s not a pull req?
508 2014-04-24 15:43:35 <octocodercat> Is it possible to send a message in the script of a transaction?
509 2014-04-24 15:47:05 <hearn> “possible”, yes. a good idea? no
510 2014-04-24 15:55:03 <sipa> hearn: an a gisttr by gavin
511 2014-04-24 15:55:13 <sipa> hearn: on a gist by gavinandresen
512 2014-04-24 15:56:27 <tyrick> send a message in the script of a transation?
513 2014-04-24 15:56:43 <tyrick> transaction*  * * ***       *
514 2014-04-24 15:57:18 <sipa> octocodercat: why would you want to do that? it's horrible for privacy, and puts unnecessary burden on the network (which has to keep your data around forever)
515 2014-04-24 15:57:40 <sipa> octocodercat: it's private date between the sender and the receiver; just send it directly to them (through the payment protocol for example)
516 2014-04-24 15:58:11 <tyrick> wait, you can send massages to receivers?
517 2014-04-24 15:58:24 <tyrick> through the payment protocol?
518 2014-04-24 15:58:26 <sipa> using the payment protocol, yes
519 2014-04-24 15:58:30 <sipa> and refund addresses
520 2014-04-24 15:58:54 <Luke-Jr> octocodercat: there is no standard for that, no
521 2014-04-24 16:03:50 <tyrick> I don't see a refund address option?
522 2014-04-24 16:04:29 <octocodercat> Hmm
523 2014-04-24 16:04:33 <tyrick> also, looking at transactions in a block, I don't see anything there either
524 2014-04-24 16:05:16 <sipa> tyrick: see BIP 70-72
525 2014-04-24 16:05:25 <sipa> tyrick: the payment protocol is not the bitcoin P2P protocol
526 2014-04-24 16:05:53 <sipa> tyrick: the only data that belongs on the P2P network is data necessary for the world to validate your transaction; anything else is private communication between the sender and the receiver
527 2014-04-24 16:06:41 <sipa> tyrick: the payment protocol introduces payment requests and payment messages that are exchanged between sender and receiver to negotiate the bitcoin transaction before it is broadcast on the network
528 2014-04-24 16:06:51 <tyrick> have these been implemented?
529 2014-04-24 16:06:54 <sipa> yes
530 2014-04-24 16:07:12 <sipa> by bitcoin core, bitcoinj, bitcoin wallet for android, bitpay
531 2014-04-24 16:08:53 <tyrick> why isn't this in the core gui?
532 2014-04-24 16:08:57 <sipa> it is
533 2014-04-24 16:09:07 <sipa> since 0.8.0
534 2014-04-24 16:09:09 <tyrick> seems like the only fields are Pay To, Label, and Amount
535 2014-04-24 16:09:11 <sipa> sorry, since 0.9.0
536 2014-04-24 16:09:36 <sipa> you can load a payment request file, and the protocol handler for bitcoin: links with a payment protocol URI in them work
537 2014-04-24 16:10:45 <tyrick> Hm, so the message can only be sent if a payment request has been ... requested
538 2014-04-24 16:11:30 <sipa> yes, otherwise you don't where to send it
539 2014-04-24 16:11:32 <sipa> *know
540 2014-04-24 16:11:57 <tyrick> what about just sending the message to any public bitcoin address
541 2014-04-24 16:12:01 <tyrick> just as I can send coins
542 2014-04-24 16:13:23 <sipa> that would require broadcasting it on the network, as you don't know which IP to send it to
543 2014-04-24 16:13:32 <sipa> which means you lose privacy, and burden the network
544 2014-04-24 16:13:33 <tyrick> I see
545 2014-04-24 16:13:39 <tyrick> so it would become public at that point
546 2014-04-24 16:13:54 <tyrick> makes sense now
547 2014-04-24 16:22:00 <hearn> sipa: hive is also working on implementing it
548 2014-04-24 16:22:05 <hearn> and coinbase
549 2014-04-24 16:22:08 <hearn> not sure they launched yet tho
550 2014-04-24 16:26:46 <tyrick> doesn't blockchain implement messages with transactions?
551 2014-04-24 16:27:30 <tyrick> This seems more like a 3rd party solution for apps built around btc
552 2014-04-24 16:28:20 <sipa> b.i does it through their own centralized database
553 2014-04-24 16:28:32 <sipa> which makes it unacceptable for decentralized applications
554 2014-04-24 16:36:50 <maaku> any objection to adding operator bool() to uint256?
555 2014-04-24 16:37:01 <maaku> it already supports operator!()
556 2014-04-24 16:37:33 <sipa> maaku: sgtm
557 2014-04-24 16:40:06 <maaku> 
ACTION will actually try it next time before asking ... tons of ambiguous conversion errors

558 2014-04-24 16:40:13 <maaku> i guess that's why it wasn't there in the first place!
559 2014-04-24 16:40:38 <sipa> you can always use !! :)
560 2014-04-24 16:40:47 <maaku> yeah i think that's what i'll do
561 2014-04-24 16:42:27 <wumpus> I remember that's usually a problem with bool() operators on types in c++, it's very easy to introduce ambiguity or unintended conversions, better to use explicit conversions
562 2014-04-24 17:00:55 <yoyoceramic> Is there a proof of assets scheme whereby multisig addresses can be checked for soluability?
563 2014-04-24 17:01:51 <yoyoceramic> Particularly if the addresses were created from a combination of xpub keys in a BIP32 heirarchy?
564 2014-04-24 17:02:58 <sipa> you can always reveal the redeemscript + signatures by the necessary keys
565 2014-04-24 17:04:59 <gmaxwell> or even signatures by less than necessary to spend might be interesting. e.g. if 3/4 are needed to spend, showing two shows at least that those keys could block the spend. Might have some useful implications wrt keeping keys online
566 2014-04-24 17:05:42 <yoyoceramic> gmaxwell That's an interesting way to think about it.
567 2014-04-24 17:10:26 <yoyoceramic> So the xpriv at the same depth in a bip32 could verify a P2SH addresses created from a combination of the xpub keys.  Are there any implementations of this done on a bulk level?  For example, if you prevenerated several P2SH addresses to store them in a databse
568 2014-04-24 17:21:53 <gmaxwell> yoyoceramic: there is some multisig brainwallet genrating webpage that is setup for that, I'm not aware of any released real wallets that do. Codeshark was working on a wallet.
569 2014-04-24 17:24:49 <yoyoceramic> gmaxwell Thanks.  I have been playing around with it.
570 2014-04-24 17:24:50 <gmaxwell> ::sigh:: https://bitcointalk.org/index.php?topic=582744.0
571 2014-04-24 17:28:31 <midnightmagic> holy micropayment fail
572 2014-04-24 17:29:09 <btiefert> "sigh" is right
573 2014-04-24 17:35:23 <wallet42> 1 hour no block?
574 2014-04-24 17:35:59 <gmaxwell> ;;tblb 3600
575 2014-04-24 17:36:00 <gribble> The expected time between blocks taking 1 hour and 0 seconds to generate is 1 week, 0 days, 4 hours, 18 minutes, and 15 seconds
576 2014-04-24 17:36:22 <gmaxwell> wallet42: a reasonable and expected event which should happen about once a week.
577 2014-04-24 17:36:39 <wallet42> whats the formula? tblb?
578 2014-04-24 17:36:41 <shesek> nice, didn't know gribble can do that
579 2014-04-24 17:37:13 <nedot> hi anybody know where i could found bitcoin bet casino script?
580 2014-04-24 17:37:14 <nedot> .
581 2014-04-24 17:37:16 <wallet42> ;;tblb 7200
582 2014-04-24 17:37:18 <gribble> The expected time between blocks taking 2 hours and 0 seconds to generate is 24 years, 5 weeks, 1 day, 5 hours, 39 minutes, and 17 seconds
583 2014-04-24 17:37:30 <gmaxwell> it can't go too high before it runs out of precision.
584 2014-04-24 17:37:45 <gmaxwell> nedot: entirely wrong channel for that question, and no I don't.
585 2014-04-24 17:38:00 <nedot> gmaxwell: i need something easy
586 2014-04-24 17:38:12 <nedot> just for research
587 2014-04-24 17:39:17 <shesek> nedot, as he mentioned, that's not the right channel for that
588 2014-04-24 17:39:32 <nedot> shesek could u recommend anywhere else?
589 2014-04-24 17:39:36 <nedot> where?
590 2014-04-24 17:41:30 <rnicoll> have you tried Googling?
591 2014-04-24 17:41:54 <nedot> rnicoll: nop, i didnt find anything
592 2014-04-24 17:41:58 <nedot> there
593 2014-04-24 17:42:01 <nedot> here
594 2014-04-24 17:42:02 <nedot> :P
595 2014-04-24 17:42:22 <wallet42> gmaxwell: but the script does not include the current diff increase?
596 2014-04-24 17:42:34 <nedot> why does nobody solve the blockchain? last solved 10 min and then 1 hour ago?
597 2014-04-24 17:42:41 <nedot> why delay?
598 2014-04-24 17:42:51 <wallet42> nedot: nobody wants the reward
599 2014-04-24 17:43:11 <nedot> wallet42: is that a joke?
600 2014-04-24 17:43:18 <wallet42> nedot: yes
601 2014-04-24 17:43:28 <nedot> then he should not minner :)
602 2014-04-24 17:43:29 <wallet42> its called variance
603 2014-04-24 17:43:57 <nedot> no its called delay :)
604 2014-04-24 17:44:08 <nedot> you remember? "bitcoin fast easy"
605 2014-04-24 17:44:13 <nedot> i just say..
606 2014-04-24 17:44:16 <sipa> nedot: #bitcoin please
607 2014-04-24 17:44:28 <nedot> dont take it personally
608 2014-04-24 17:44:52 <nedot> but its not the first time
609 2014-04-24 17:45:55 <nedot> gmaxwell: should it be easy to build a portable wallet? if i upload the blockchain to a webserver /FTP and let it use that data?
610 2014-04-24 17:46:19 <nedot> with encryption ofc
611 2014-04-24 17:47:41 <sipa> nedot: if you're going to trust a webserver to serve correct data about the world's finances, why do you use a full client at all?
612 2014-04-24 17:47:54 <sipa> nedot: use a webclient if you're fine with that level of trust; much faster