| 00:00:04 | bramm: | phantomcircuit, That was a very sophisticated attacker |
| 00:00:49 | phantomcircuit: | bramm, it really wasnt |
| 00:01:16 | bramm: | phantomcircuit, You might be giving a bit much credit to unsophisticated attackers :-) |
| 00:01:19 | phantomcircuit: | it was just someone who was bored and not afraid of jail |
| 00:01:48 | midnightmagic: | The joke has grown out of the uncountable repetition of DHT suggestion, and eventually we started teasing each other by suggesting dht for everything. |
| 00:02:06 | phantomcircuit: | afaict they just abused a published exploit in tp link routers that basically was just default snmp permissions being set wrong |
| 00:02:07 | bramm: | A fair amount of why the internet as a whole keeps working is that people who are capable of building and running botnets tend to be disinterested in it |
| 00:02:41 | phantomcircuit: | the scanning the internet bit was maybe sophisticated |
| 00:02:45 | phantomcircuit: | the breaking in? not so much |
| 00:03:00 | midnightmagic: | i don't recall anybody seriously suggesting a dht even just for block propagation |
| 00:03:36 | bramm: | It might make sense to use a DHT-like structure for bit coin peers selecting who they talk to, to keep latencies down |
| 00:04:01 | sipa: | optimizing for latency makes sense, but isn't a 100% win either |
| 00:04:37 | midnightmagic: | bramm: that would likely fail the connectivity benefits of a randomized peer selection |
| 00:04:38 | sipa: | if you have a strong tendency of the network to connect to peers with low latency, you may get clustering, which may make separating the network easier |
| 00:05:12 | bramm: | midnightmagic, It can do better than random actually, but also requires a fair number of connections |
| 00:06:05 | phantomcircuit: | really what we need is a better than random peer selection algorithm and then to make wallet transaction broadcasts more selective in who they talk with |
| 00:06:15 | bramm: | phantomcircuit, The vast majority of script kiddies are literally incapable of writing a line of code. It's true though that for something like DDOSing BitTorrent or Bitcoin it's plausible that someone might have an actual business model behind it, at which point getting the resources together to do such attacks would be easy |
| 00:06:24 | midnightmagic: | bramm: The benefit of a strong, unpredictable connectivity graph are more important than latency |
| 00:06:43 | sipa: | well, latency matters for scaling |
| 00:06:46 | phantomcircuit: | bramm, uh ok maybe your definition of sophisticated is different then mine |
| 00:07:14 | sipa: | yeah, i don't think anyone here was too worried about script kiddies |
| 00:08:44 | bramm: | Well if we're actually on the subject of peer selection in bit coin, it's probably more analogous to peer selection in BitTorrent, which we also do using IPs. Basically for every pair of nodes we hash together the IPs of the endpoints to determine a 'score' for that connection, and you accept a new incoming connection if it has a higher score than the lowest one you currently have |
| 00:09:23 | bramm: | I just turned off spelling 'correction', sorry about that. |
| 00:12:51 | midnightmagic: | initial peer discovery was more the issue, as people really had a problem with the IRC channel on lfnet that we used to use, and then had a problem with the centralized DNS seeders we use now. Once we have good connectivity, peer discovery is easier because the network chats about peers all by itself. The joke was that the initial seeds are all equivalently centralized. |
| 00:12:59 | phantomcircuit: | bramm, peer selection for the p2p protocol is actually more similar to relay selection in tor |
| 00:13:14 | phantomcircuit: | which they haven't gotten right either :/ |
| 00:24:39 | bramm: | I suppose peer selection it bit coin has two separate goals: anonymity and connectivity. Unfortunately these are in direct conflict :-P |
| 00:25:20 | sipa: | if you're not running a wallet, there is little privacy to lose or gain |
| 00:25:39 | sipa: | as a miner perhaps you don't want to be attackable, and being unknown helps |
| 00:25:59 | sipa: | also, there is connectivity and latency |
| 00:26:00 | phantomcircuit: | sipa, yeah i was thinking there should be guard nodes which are long lived that receive wallet transaction broadcasts |
| 00:26:07 | sipa: | which are also in conflict with eachother |
| 00:26:22 | phantomcircuit: | and another group of nodes which are cycled on staggered schedules |
| 00:26:30 | sipa: | latency matters, because it correlates directly with block propagation speed |
| 00:28:12 | bramm: | For latency purposes it makes sense to keep a certain number of slots for lowest ping time peers and the rest for random |
| 00:28:35 | bramm: | And when you're sending stuff out first send to a random peer and then to your lowest latency peers |
| 00:29:40 | phantomcircuit: | bramm, you basically never want to send wallet txs to low latency peers actually |
| 00:30:07 | phantomcircuit: | not without significant forethought |
| 00:30:12 | midnightmagic: | i thought block chain consensus is still convergent up to absurd maximums and out past the moon |
| 00:30:45 | phantomcircuit: | midnightmagic, convergent yes, but with stupid high latency links you might end up with lots of tiny reorgs |
| 00:30:57 | midnightmagic: | meh |
| 00:31:34 | bramm: | So is there anything other than signatures, locktime, and preimages which a coin can be contingent on? |
| 00:33:46 | dgenr8: | bramm: the coin's script can define intricate requirements for spending it |
| 00:33:52 | Eliel_: | it's possible to require the spending transaction to provide data that hashes to a specific hash. |
| 00:33:54 | lechuga_: | they're more contingent on script execution result than a signature. there is no requirement for there to be an actual ecdsa signature to claim an output |
| 00:34:16 | lechuga_: | unless specified by the output's script |
| 00:34:18 | Eliel_: | but yes, it's scriptable so, a lot of things are possible |
| 00:34:24 | midnightmagic: | who was it who appeared to do some actual calculations for blockchain convergence.. amiller I think? or andytoshi? |
| 00:34:25 | dgenr8: | bramm: have you looked at the bitcoin "payment channel" work? |
| 00:34:38 | bramm: | dgenr8, no, got a link? |
| 00:34:42 | dgenr8: | bramm: https://bitcointalk.org/index.php?topic=244656.0 |
| 00:34:45 | sipa: | midnightmagic: convergence isn't enough; if there's a 40% forking rate, you're giving a 40% advantage to a collusion attacker |
| 00:34:55 | bramm: | Presumably the sidechains stuff adds all kinds of new possible contingencies |
| 00:35:26 | amiller: | midnightmagic, i never computed anything |
| 00:35:45 | lechuga_: | ever? |
| 00:35:50 | sipa: | 42. |
| 00:35:52 | lechuga_: | lol |
| 00:36:01 | sipa: | amiller did come with the auto-adjusting block rate, to basically aim for (iirc) 50% forking rate |
| 00:36:20 | midnightmagic: | amiller: was it not you who at one point determined convergence area from speed-of-light from surface of the earth up to some radius past the moon? |
| 00:36:42 | bramm: | What is this 'forking rate'? |
| 00:36:51 | amiller: | rate of stale blocks |
| 00:36:54 | sipa: | bramm: how many mined blocks don't end up in the active best chain |
| 00:37:42 | sipa: | because the finder of the following block hasn't seen the previous one yet |
| 00:38:14 | bramm: | My best guess about forking rate is that it's about 5 seconds for things to get distributed and about 10 minutes for things to happen so the fork rate should be around 5 / 600 or just under 1% |
| 00:38:50 | sipa: | yup |
| 00:39:10 | sipa: | as long as the ratio is large between them, that rule holds pretty well |
| 00:39:37 | bramm: | I did some math once to figure out the 'optimal' average length of time between blocks and got the diameter of the network times e, with things getting really bad below that because of fork rate and not much worse above it, so that would imply that to make transactions go through as quickly as possible the average time between blocks should be around 30 seconds |
| 00:39:37 | sipa: | if it's smaller you need to take the actual interblock interval distribution into account |
| 00:39:54 | sipa: | but as i said: just convergence isn't enough |
| 00:40:04 | sipa: | because it assumes no attackers |
| 00:40:30 | bramm: | I think 10 minutes between blocks is a bit excessive |
| 00:40:43 | sipa: | maybe it could have been 1-2 minutes |
| 00:40:58 | bramm: | 2 minutes is already quite conservative |
| 00:41:00 | phantomcircuit: | except that would give larger miners an advantage |
| 00:41:00 | sipa: | but a collusion attacker (one which knows he has a majority of the hash rate or close to it) only mines on top of blocks he produces himself |
| 00:41:09 | bramm: | Not that 10 minutes is particularly problematic |
| 00:41:32 | sipa: | and therefore doesn't suffer from the forking rate that is the result of the distance/propagation delay between miners |
| 00:41:52 | bramm: | Right, large miners can keep their own forks and force a reorg with some reliability |
| 00:41:58 | sipa: | right now i think there is like 1-2%? |
| 00:42:07 | bramm: | The lack of credit for partials is a bit of a problem here |
| 00:42:37 | sipa: | that pretty much means that with 1 minute blocks and everything else equal, we'd likely have 10% forks, which may already be significant |
| 00:43:00 | sipa: | credit for partials? |
| 00:46:59 | andytoshi: | midnightmagic: i didn't do those calculations either |
| 00:48:26 | midnightmagic: | :-/ was it just an eyeballing/estimate based on 10 minutes of speed-of-light from the surface of the earth then? |
| 00:50:14 | midnightmagic: | gmaxwell stop making yourself useful and stand in as my offloaded memory |
| 00:52:07 | midnightmagic: | .. could've sworn someone said they worked it out. it was near the time amiller was looking for a research project but perhaps that was just a proximal event |
| 00:52:20 | bramm: | sipa, If partials were baked into the protocol then a miner couldn't use their own forks because they'd lose due to not having partials |
| 00:52:32 | sipa: | what are partials? |
| 00:52:36 | bramm: | or some variant thereof, there are a few different ways it could be set up with different tradeoffs |
| 00:52:54 | bramm: | A partial is something you get when you were trying to mine which doesn't make a new block but gets you a mining reward |
| 00:53:05 | sipa: | ah, right |
| 00:53:08 | bramm: | And also reinforces the validity of whatever you were mining off of |
| 00:53:10 | sipa: | p2pool shares, bacially |
| 00:53:13 | dgenr8: | bramm: see asic-faq question 5 |
| 00:53:58 | bramm: | dgenr8, Do you mean proofs of stake or something else? |
| 00:54:21 | amiller: | "giving credit for partials" is basically my current best idea for how to make nonoutsourceable puzzles with integrated p2pool so you don't need a pool |
| 00:54:47 | dgenr8: | no credit for partials = a "progress-free" PoW |
| 00:54:57 | amiller: | not really |
| 00:54:58 | bramm: | amiller, I'm not sure what you mean by 'nonoutsourceable' but I think I agree with you |
| 00:55:13 | amiller: | bramm: see http://cs.umd.edu/~amiller/nonoutsourceable.pdf |
| 00:55:39 | bramm: | Okay, that goes on my list of stuff to read |
| 00:56:12 | bramm: | This list is rather long, my goal for today was to get through atomic transactions, which I mostly have a handle on and need to read a little more closely later |
| 00:57:06 | bramm: | I sometimes get pulled away by a meatspace DOS attack. It typically starts with DADDY I'M HUNGRY |
| 00:59:38 | nsh: | and then your child summons a million tiny zombies? |
| 01:00:09 | nsh: | because that is probably not considered normal development behaviour before adolescence at least |
| 01:00:14 | nsh: | oh, my bad, you didn't actually say DDoS |
| 01:00:25 | nsh: | * nsh returns to cave |
| 01:02:22 | andytoshi: | midnightmagic: my guess is maaku |
| 01:02:47 | andytoshi: | it's also possible that gmaxwell or i did it, i'm sure i remember talking about it |
| 01:21:35 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 01:47:30 | PRab_: | PRab_ is now known as PRab |
| 01:55:30 | super3: | amiller: you around? |
| 02:01:28 | bramm: | This 'nonoutsourceable' concept is interesting. It's trying to make it so that any outsourcing requires a lot of trust. The opposite side is to reduce the incentive for outsourceing |
| 02:09:09 | PRab_: | PRab_ is now known as PRab |
| 02:12:52 | instagibbs_: | phantomcircuit: shorter block times, provided the rise in stale rates is low, actually could end up helping smaller pools due to decreased variance |
| 02:16:33 | instagibbs_: | trying to get the details published but here are slides from a talk by Dave Hudson. Check out slides 63+: https://docs.google.com/presentation/d/1nVGCU6MDdLad8yOAmNWDbCUqXerq5Ss1B5J7AcLmZ1w/edit#slide=id.p13 |
| 02:17:04 | instagibbs_: | 66 particularly |
| 02:22:20 | phantomcircuit: | instagibbs_, that's a pretty large conditional |
| 02:23:38 | instagibbs_: | *shrug* mining connections I'm guessing have greatly decreased latency since the olden days. Something to think about at least. There will always be a tradeoff. |
| 02:23:40 | phantomcircuit: | and the effect is actually very small |
| 02:27:46 | instagibbs_: | it's the marginal benefits between large/small pools that's in question. Squeezing the benefits down to a much smaller fraction of total hashing power could have benefits. I'll bug the author again for the writeup. |
| 02:29:41 | bramm: | What are the main practical incentives for mining pools? |
| 02:30:09 | phantomcircuit: | bramm, reduced variability in reward |
| 02:30:47 | phantomcircuit: | mining by yourself is unlikely to ever return a reward until you approach significant mining size |
| 02:30:52 | instagibbs_: | that, and with "hosted mining" you don't actually have to run anything |
| 02:31:01 | instagibbs_: | or run a full node... |
| 02:31:16 | instagibbs_: | but casting those aside, what phantomcircuit said |
| 02:36:58 | amiller: | super3, hi |
| 02:37:49 | super3: | how have you been? |
| 02:38:18 | amiller: | bramm, yeah so 'nonoutsourceable' raises the distrust *against* pooling, having p2pool shares "integrated" into the official rules reduces the incentive *for* pooling... |
| 02:38:47 | amiller: | the story for anti-hosted-mining is a lot sketchier :/ |
| 02:39:01 | amiller: | busting up pools without also busting up hosted mining seems like a net negative, pools seem lesser of two evils |
| 02:39:10 | amiller: | super3, good! thanks, what you up to? |
| 02:39:39 | super3: | seeing how many hard drives it takes to get to the moon |
| 02:40:28 | bramm: | What do you mean by 'hosted mining', and what's the problem with it? |
| 02:40:52 | phantomcircuit: | bramm, you pay me money, i buy hw and runt he hw for you |
| 02:41:02 | amiller: | hosted mining is roughly when someone pays a large corporation to run some mining rig in a data center somewhere |
| 02:41:14 | phantomcircuit: | effectively i control which transaction your money pays to mine |
| 02:41:28 | amiller: | due to economies of scale, orgs like this can offer better deals the more consolidated they are |
| 02:41:32 | bramm: | I don't see how hosted mining is a problem, or avoidable. Practically everything is hosted services these days. |
| 02:41:54 | amiller: | hosted mining is a consolidation of power |
| 02:42:05 | super3: | i mean my main thing about nonoutsourceable is that it would be impossible to integrate into bitcoin |
| 02:42:06 | bramm: | Oh, yeah, economies of scale. Probably the best bet for fixing that is to use resources people already have sitting around not being very well utilized |
| 02:42:08 | amiller: | someone could go blackmail the administrator of that organization |
| 02:42:12 | bramm: | Like memory. Cuckoo might help. |
| 02:42:37 | phantomcircuit: | amiller, otoh individuals who are bad at calculating costs might not realize what the economies of scale really are |
| 02:42:44 | amiller: | bramm so just like for pooling, there are two sides to a solution, a) create a barrier/disincentive by sowing the seeds of 'distrust', and b) remove the incentive |
| 02:42:49 | phantomcircuit: | (this has been an issue selling people contracts recently) |
| 02:42:52 | amiller: | cuckoo removes the incentive by reducing the benefits of consolidation |
| 02:42:55 | amiller: | (maybe!) |
| 02:43:20 | amiller: | nonoutsourceable puzzle can also in some fantasy world or something create enough distrust that people wouldn't be as happy with hosted mining providers |
| 02:43:43 | phantomcircuit: | amiller, kind of doubt it |
| 02:43:55 | phantomcircuit: | virtually nobody asks for proof of anything |
| 02:44:01 | amiller: | phantomcircuit, yeah, well, you and apparently everyone else, i haven't had an easy time getting any traction for this |
| 02:44:12 | phantomcircuit: | nearly everybody just calculates expected returns and compares with actual return |
| 02:44:15 | amiller: | the pessimistic view is that everyone is already totally trusting of big organizations |
| 02:44:34 | amiller: | phantomcircuit, yes okay, so, there is an implicit assumption there about how things *already* work, and i propose to change that. |
| 02:44:44 | amiller: | right now, there is no super jackpot |
| 02:44:49 | instagibbs_: | I think a lot of possible hobbyist miners don't do it because you have to lay down $2K+ to even pray for even |
| 02:44:51 | amiller: | you get the 25 btc every 10 minutes, that's the only lotto game there is |
| 02:45:06 | rusty: | amiller: or they are happy with the exposure being limited to the time it takes them to xfer out their profits? |
| 02:45:11 | super3: | not because of technical reasons, but existing miners will just reject it |
| 02:45:18 | amiller: | suppose you got 20 btc every 10 minutes most of the time, but *sometimes* you win a 10000 btc jackpot |
| 02:46:01 | instagibbs_: | amiller you have a dumping ground for lotto-style mining thoughts? or are they just rattling around |
| 02:46:07 | rusty: | amiller: ah, so you're trying to use that to change the trust dynamics. Interesting idea... |
| 02:47:03 | amiller: | instagibbs, yeah, sorry, your buffer here is the dumping ground ;/ i have a forum post here https://bitcointalk.org/index.php?topic=305781.0 but it's kind of sketchy |
| 02:47:18 | phantomcircuit: | amiller, oh right |
| 02:47:22 | phantomcircuit: | yeah that might change things |
| 02:47:41 | amiller: | basically for this to work i need to assume some kind of unusual decision theory things and even if i'm right i don't know yet how to do the science and give some kind of evidence for it |
| 02:51:27 | instagibbs_: | im interested because I'm quite doubtful of long-term PoW if people are actually mining at cost |
| 02:53:45 | amiller: | if the economics of this are anything like state lottos, then people will be mining at less -than-cost |
| 02:54:08 | instagibbs_: | *assuming you mean -EV* |
| 02:54:11 | amiller: | yes |
| 02:54:17 | bramm: | When are rewards going to drop by half again? |
| 02:54:20 | instagibbs_: | I read that post a long time ago |
| 02:54:26 | instagibbs_: | 2016ish |
| 02:56:14 | bramm: | I wish it was sooner. It will be interesting to see what happens on the next drop |
| 02:57:06 | kanzure: | block 420000 |
| 02:57:16 | kanzure: | best to measure time by number of blocks rather than 2016 |
| 02:58:30 | bramm: | What block number is it on now? |
| 02:58:48 | bramm: | I wonder how many miners are going to wonder why their revenues suddenly dropped by half |
| 02:59:10 | kanzure: | current blockheight is approximately 332650 depending on who you are |
| 02:59:17 | kanzure: | or rather, depending on which nodes you know |
| 02:59:26 | kanzure: | (because 332651 is out there) |
| 03:16:27 | bramm: | So that's early 2016 probably |
| 03:18:31 | phantomcircuit: | amiller, its not enough of a lottery for that really |
| 03:19:53 | amiller: | not now it isn't :/ |
| 03:19:55 | bramm: | I have a question about the atomic transactions protocol |
| 03:20:12 | amiller: | bramm, the tiernolan one? |
| 03:20:18 | bramm: | amiller, yes that one |
| 03:20:43 | amiller: | i know that one, i want to help! |
| 03:20:58 | bramm: | Why have the counterparty sign a return transaction? Why not just make it so that the coin can be unlocked with a combination of A's signature and a timelock of 24 hours? |
| 03:21:00 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 03:26:15 | amiller: | you can't make a "coin" (an unspent transaction output) unlockable |
| 03:27:12 | amiller: | that limitation is just sort of a quirk of bitcoin script, there's a proposed opcode OP_CHECKLOCKTIMEVERIFY that would let you do that |
| 03:28:05 | bramm: | Ah, that's what I suspected |
| 03:28:23 | amiller: | s/unlockable/unlockable-after-some-time |
| 03:31:18 | bramm: | So transactions can be time-locked but coins can't? |
| 03:31:49 | bramm: | I hope I'm not irritating everybody by saying 'coin' instead of 'unspent output'. It's just shorter. |
| 03:32:30 | lechuga_: | 'utxo' |
| 03:33:12 | bramm: | Okay I can use that. Is utxo short for something? |
| 03:33:19 | lechuga_: | unspent transaction output |
| 03:33:25 | tromp_: | unspent transaction output |
| 03:33:52 | tromp_: | just as short as coin! |
| 03:34:35 | lechuga_: | doubt any1 really annoyed by 'coin' tho |
| 03:37:14 | lechuga_: | re: OP_CHECKLOCKTIMEVERIFY, see also: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki |
| 03:37:31 | amiller: | i like calling those coins too, but it confuses people who don't know it :/ "utxo" either you know it or it's obviously incomprehensible |
| 03:38:01 | amiller: | bramm, exactly, a transaction can be timelocked but a utxo can't |
| 03:56:31 | bramm: | tromp_, I have a question about cuckoo |
| 03:56:34 | op_null: | bramm: the problem with "coin" really is that it gives people the idea that they are somehow 1BTC units. at least with utxo you can't have people forming preconceived notions about their function. |
| 03:57:37 | tromp_: | yes, bramm? |
| 03:58:00 | bramm: | tromp_, Does it need something as strong as siphash? Could it use something weaker like, say, a single round of AES? |
| 03:58:33 | bramm: | Or is a single round of AES about the same as siphash? |
| 03:58:37 | tromp_: | i tried with reduced rounds, even down to siphash11, and couldn't see any effect on cycle length distribution |
| 03:58:52 | bramm: | What is siphash11? |
| 03:59:23 | tromp_: | normal siphash is siphash 24, 2 rounds of one kind and 4 rounds of another kind |
| 04:01:06 | tromp_: | for extra mixing power, some applications use siphash-4-8 |
| 04:02:40 | tromp_: | so cuckoo can use a weaker siphash than siphash-2-4, but i'd feel better about siphash-1-2 than a single round of AES |
| 04:03:07 | bramm: | Are siphash-1-2 and AES about the same amount of CPU? Why 1-2 specifically? |
| 04:03:42 | tromp_: | just sticking with the ratio siphash-n-2n |
| 04:03:52 | tromp_: | doing half the work of siphash-2-4 |
| 04:04:32 | tromp_: | i don't know offhand how 1round AES compares with siphash-1-2 |
| 04:06:02 | tromp_: | but siphsah is designed for hash tables, which is really how it's used in cuckoo cycle |
| 04:06:38 | bramm: | I'd be curious to hear DJB's thoughts on reduced round siphash, in particular for that use |
| 04:07:52 | tromp_: | i asked him by email |
| 04:08:11 | tromp_: | it bounced:( |
| 04:08:32 | bramm: | huh, what was the reason for the bounce? |
| 04:09:30 | tromp_: | : |
| 04:09:31 | tromp_: | I have not received confirmation that this message is not bulk mail. |
| 04:09:33 | tromp_: | I'm not going to try again; this message has been in the queue too long. |
| 04:09:54 | bramm: | Huh, I've successfully corresponded with him before. Will try later. |
| 04:11:53 | tromp_: | AES is unnecessarily wide |
| 04:12:50 | tromp_: | i know someone who was trying to exploit the limited width of siphash to compute 4 of them in parallel with AVX |
| 04:13:02 | tromp_: | that might speed up cuckoo a bit |
| 04:13:51 | bramm: | cuckoo should be mostly waiting for memory |
| 04:14:39 | bramm: | Hence the wanting to speed up the hashing. If it was mostly waiting for CPU then there wouldn't be much point in speeding up the CPU |
| 04:14:40 | tromp_: | yes, but once a thread is waiting for memory, you need another thread to compute the next siphash |
| 04:14:56 | tromp_: | the memory subsystem can handle many pending memory accesses |
| 04:15:55 | tromp_: | for cuckoo, hyperthreading beyond a factor of 2 (like on some sparc cpus) could be very beneficial |
| 04:17:32 | bramm: | Presumably custom hardware should be able to do that so the more that COTS hardware can do it the better |
| 04:19:15 | tromp_: | i'd love to try cuckoo on an intel xeon phi |
| 04:19:38 | tromp_: | my former academic institution has one, but it invariably crashes on cuckoo:( |
| 04:21:20 | tromp_: | gotta run; talk to you later... |
| 04:21:25 | bramm: | laters |
| 09:05:16 | weber.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: andy-logbot Baz___ davejh69 Transisto gues kgk samson2 wallet42 Starduster_ warptangent coiner zibbo_ luny cletus11 andytoshi paveljanik prodatalab ryanxcharles [7] op_null Graet woah webdeli Dr-G3 pi07r ebfull prepost d4de go1111111 SDCDev adlai eristisk ybit jgarzik Meeh_ atgreen bramm bosma nsh starsoccer instagibbs Shiftos tacotime PaulCape_ DoctorBTC Emcy NikolaiToryzin nsh- stonecoldpat koshii waxwing shesek btcdrak fenn roconnor__ mappum |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: hashtag_ tromp Guest45626 K1773R ahmed_ artifexd btc__ hguux_ LarsLarsen nubbins` nuke1989 iddo c0rw|sleep nanotube dansmith_ kanzure Luke-Jr spinza Flyer33 devrandom arowser1 SubCreative Anduck rfreeman_w null_radix grandmaster Nightwolf mortale hollandais AdrianG gwillen livegnik BananaLotus @ChanServ burcin coutts wizkid057 Dyaheon bbrittain forrestv nickler mr_burdell tromp_ Krellan poggy comboy mmozeiko lnovy Taek optimator_ [\\\] |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away Fistful_of_Coins gmaxwell kinlo so [d__d] espes BigBitz otoburb wumpus EasyAt jaromil helo Keefe Iriez huseby phedny midnightmagic coryfields BrainOverfl0w warren pigeons asoltys gribble smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow lechuga_ gazab a5m0 BlueMatt fluffypony MRL-Relay azariah4 Muis kumavis HM jbenet Alanius sipa Grishnakh Cory sl01 phantomcircuit |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: JonTitor gavinandresen michagogo harrigan sneak isis LaptopZZ bobke Eliel_ s1w lclc jaekwon Pan0ram1x HaltingState Hunger- Graftec jaekwon_ mkarrer epscy berndj |
| 09:05:16 | weber.freenode.net: | [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp |
| 09:44:27 | c0rw|sleep: | c0rw|sleep is now known as c0rw|away |
| 10:36:16 | lclc: | lclc is now known as lclc_bnc |
| 10:37:27 | lclc_bnc: | lclc_bnc is now known as lclc |
| 10:49:57 | wallet421: | wallet421 is now known as wallet42 |
| 10:56:40 | samson2: | samson2 is now known as samson_ |
| 11:54:01 | tobyai: | tobyai has left #bitcoin-wizards |
| 12:10:20 | op_null: | mildly interesting, there's an altcoin that has decided to make mining non outsourceable partly by padding the whole block out to the maximum size and then hashing the whole thing. lets see how that works out for them. |
| 12:11:27 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 12:12:25 | op_null: | they did some mildly interesting stuff by modifying OP_CHECKSIG to do public key recovery from transactions, and then bundled it all up with X11 super secure hashing :P |
| 12:12:36 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 12:14:33 | fluffypony: | lol X11 |
| 12:14:36 | Luke-Jr: | op_null: non-outsourcable, eh? what happens when I just use a midstate? |
| 12:15:32 | op_null: | Luke-Jr: eh, there's other bits too like having the coinbase transaction pubkey sign the block. here's a malware-free overview of it, anyway. https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fspreadcoin.net%2Ffiles%2FSpreadCoin-WhitePaper.pdf |
| 12:21:08 | Luke-Jr: | op_null: what stops the pool from signing after a solution is found? |
| 12:21:08 | Luke-Jr: | I don't see that in there |
| 12:23:51 | op_null: | Luke-Jr: I think that hashing stuff is done, and then the PoW is done on top of it. I couldn't quite work it out either. I presented it as humour not anything else. |
| 12:24:44 | Luke-Jr: | s/interesting/funny/ <.< |
| 12:25:25 | op_null: | good point. |
| 12:25:49 | op_null: | as soon as you see "X11" though you know it's a joke. |
| 12:28:37 | lnovyz: | lnovyz is now known as lnovy |
| 12:39:16 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 12:46:35 | nubbins`: | gross, had a buyer for my genesis block newspaper, now he's gone missing ;/ |
| 14:15:19 | lclc: | lclc is now known as lclc_bnc |
| 14:35:27 | lclc_bnc: | lclc_bnc is now known as lclc |
| 16:08:16 | lclc: | lclc is now known as lclc_bnc |
| 16:28:39 | lclc_bnc: | lclc_bnc is now known as lclc |
| 17:00:24 | bramm: | gmaxwell, A number of those things look like serious antipatterns from my experience with programming, but crypto/security code is a bit special. It seems a bit nuts to be writing servers which are supposed to be secure in C though. |
| 17:03:24 | tromp_: | what language would be less nuts, bramm? |
| 17:06:00 | sipa: | well there is one advantage that lower-level languages have which is relevant (not that i disagree that there are dangers too), namely tight control over resources (in particular, languages with strong reliance on garbage collection are really hard to reason about) |
| 17:06:32 | sipa: | you don't want to have perfectly ok average case memory usage, and then some attack on the network which does nothing more than blow up the memory usage of every node in the system |
| 17:07:38 | bramm: | tromp_, python |
| 17:07:52 | bramm: | or java |
| 17:09:18 | tromp_: | i thought you were gonna say Rust |
| 17:09:42 | sipa: | Rust seems a very hopeful combination between safety guarantees and resource guarantees |
| 17:09:42 | bramm: | I'm not familiar with rust |
| 17:09:56 | sipa: | but i'm not very familiar with it, and it seem not very mature yet either |
| 17:14:47 | bramm: | Python has ref counted garbage collection with mark and sweep as a back-stop. In practice it's rare for it to behave any differently than it would if you wrote the same thing in C++11, and in cases where it does the mark and sweep is probably saving your ass from a bug |
| 17:16:31 | sipa: | using c++11 naively with standard containers is indeed not that much better (it'll copy data structures all over the place, allocate where you don't expect things, and if you're using shared_ptr or equivalents it's really just refcounting anyway) |
| 17:18:15 | tacotime: | ehm, haven't there been a lot of memory expansion ddos attacks on bitcoind though? eg getutxos |
| 17:19:22 | tacotime: | or maybe i misread and you weren't antagonising gc-rich (hehe) languages |
| 17:19:46 | bramm: | Yes the modern approach is to use a lot of either ref counted pointers or unique pointers, for the same practical software development reasons you have in higher level languages |
| 17:20:39 | sipa: | tacotime: bitcoin is by no means perfect wrt to guaranteeing resource limits |
| 17:21:09 | sipa: | i'm just making the general observation that using higher-level languages make it generally harder to reason about resources |
| 17:21:18 | sipa: | and c++ is higher-level in this regard :) |
| 17:21:19 | bramm: | You do have the nice feature of higher level languages that the crypto can be kept *very* encapsulated in a library. Perhaps it would be a good idea to have all handling of private crypto stuff happen in the library. Unfortunately you can't really help but have private keys be put into a string once in a while. |
| 17:21:59 | bramm: | ref counting is fairly good as far as resource usage goes, it doesn't make any fundamentally new edge cases like mark and sweep does |
| 17:22:58 | sipa: | well, the ultimate defense (but hardly optimal) against resource usage attacks is making the worst case equal to the average case |
| 17:23:23 | sipa: | and every optimization that doesn't actually improve the worst case doesn't actually help |
| 17:24:24 | sipa: | at least without making the attacker costlier |
| 17:24:32 | andytoshi: | most of the crypto is used in consensus code, we really really need that to be explicit |
| 17:26:04 | gmaxwell: | tacotime: kinda weird that you cite an example of code we rejected there. |
| 17:26:09 | andytoshi: | (and actually C++ is not explicit enough, its weak typing has caused eg the SIGHASH_SINGLE bug) |
| 17:26:28 | tacotime: | gmaxwell: ah, didn't realize that didn't make it to master |
| 17:26:31 | sipa: | andytoshi: that's just sloppy programming; returning an error code as a hash is just totally broken |
| 17:26:52 | sipa: | tacotime: it was, but never in a release (and it was controversial from the start...) |
| 17:27:04 | andytoshi: | sipa: sure, i'm just saying "totally broken" intersect "compiles" could be be a smaller set |
| 17:27:06 | gmaxwell: | tacotime: it was merged by mistake for a couple hours until people woke up. |
| 17:27:25 | sipa: | yeah, the person who merged it wasn't aware of some ongoing discussion about it still |
| 17:27:48 | sipa: | though that discussion was not about the resource usage problems of it, so maybe not all that relevant |
| 17:31:28 | gmaxwell: | Well, sort of circularly: it hadn't been reviewed because people had stopped on the architectural issues. |
| 17:34:24 | bramm: | How cleanly specced is the bitcoin protocol? |
| 17:34:56 | bramm: | Parsing is the #1 place where security problems come in, and sloppy formats are the #1 cause of parsing problems |
| 17:35:22 | sipa: | bramm: the p2p protocol is pretty well documented, but the consensus rules can't really be specified |
| 17:35:28 | gmaxwell: | We've never had a single issue related to that as far as I recall. The p2p protocol itself is pretty trivial. |
| 17:36:08 | bramm: | Not sure what you mean by 'consensus rules' |
| 17:36:26 | andytoshi: | bramm: almost everything in the block and transaction formats are fixed-width, there is a wiki page somewhere with everything explicitly written out |
| 17:36:30 | sipa: | bramm: the rules that determine which block is valid |
| 17:37:11 | sipa: | bramm: because even if we had a full specification that everyone agreed on that the consensus rules should be, if we would find that actual implementations on the network didn't follow that document... we'd need to update the document, because the alternative is requiring _everyone_ to change their software |
| 17:37:17 | bramm: | Fixed width has its advantaged and disadvantages. It works great as long as the practical values stay within range. |
| 17:37:28 | gmaxwell: | The cryptographic validation of the correctness of blocks. By "can't be specified", pieter means that basically every attribute of the validation down to a single bit is generally completely normative. Which doesn't lead to human comprehensible specification. |
| 17:37:51 | bramm: | 'normative'? |
| 17:37:51 | andytoshi: | bramm: https://en.bitcoin.it/wiki/Protocol_specification ... parsing is one thing that is very well-specced |
| 17:38:10 | sipa: | bramm: every node must independently come to the exact same conclusion about which block is valid or not |
| 17:38:13 | bramm: | I view block validation as part of the spec. |
| 17:38:16 | gmaxwell: | bramm: every system must perform an identical or at least indistinguishable computation or the network forks. |
| 17:38:31 | sipa: | you have no idea (really!) how nearly impossible that is from an engineering perspective |
| 17:38:49 | bramm: | Yes, that's something where I'd expect the de facto spec of what the standard codebase does to be the only thing which matters. |
| 17:39:13 | sipa: | rigfht, but the point is that such a spec can only be descriptive, and not prescriptive |
| 17:39:25 | sipa: | if the code was found to not match the document, the document would need to be updated |
| 17:39:29 | andytoshi: | https://download.wpsoftware.net/bitcoin/alts.pdf sections 6.0 and 6.1 talk a little bit about this |
| 17:39:37 | bramm: | Correct. Maybe you could explain that to the w3c |
| 17:39:38 | sipa: | because consistency is more important than correctness |
| 17:40:12 | sipa: | (well, excluding totally crazy bugs that would allow stealing money probably...) |
| 17:40:15 | gmaxwell: | It is not acceptable to be too permissive or too restrictive in almost any way. No hidden behavior additional or inconsistent limit is permitted, no hidden limit. You cannot refuse to handle something permitted becaue you don't have enough memory or something. etc. Nonsensible garbage and 'error' cases need to be handled all exactly the same. |
| 17:40:18 | andytoshi: | lol i should make an alt with html transactions |
| 17:40:34 | sipa: | andytoshi: use JSONx |
| 17:41:00 | sipa: | bramm: we have had the network fork due to a default limit on the number of simultaneous locks bdb could hold |
| 17:41:11 | gmaxwell: | yadda yadda. Consensus systems have a higher set of annoying requirements over mearly distributed systems which can fail to interoperate but usually don't need to be completely lockstep and interop failures don't usually result in large scale meltdowns. |
| 17:41:37 | sipa: | bramm: when a new version switched to a different database engine, a fork occurred because old nodes didn't accept some block that did particularly many updates to the database |
| 17:41:43 | gmaxwell: | sipa: even the limited wouldn't have been so bad, if it were determinstic in how it was enforced. :) |
| 17:42:33 | gmaxwell: | (if we'd known that it was even hittable; ... number of locks bdb used depended on the layout of the data on disk) |
| 17:42:40 | sipa: | i don't think anyone even expected that number of locks to be effectively part of the network's consensus rules |
| 17:42:50 | bramm: | Yes, disagreements about how big updates are allowed to be is an issue. Relatedly there's the very interesting limitation that each block can only be a megabyte. |
| 17:43:04 | sipa: | that's a very important limitation :) |
| 17:43:23 | sipa: | and it's a well-known rule too, unlike that bdb issue |
| 17:43:29 | bramm: | It cuts both ways |
| 17:43:44 | gmaxwell: | bramm: but not just updates, there are relatively few behaviors which cannot be turned into a network split if there is even the smallest difference. |
| 17:43:59 | bramm: | The lesson about bdb seems to be don't use bdb. They've been working on that thing for decades and still don't have really basic simple functionality working right. |
| 17:44:19 | sipa: | bramm: the block size limit sets a compromise between scalability of transaction volume and scalability of running a full node |
| 17:44:25 | gmaxwell: | bramm: missing the point there, the forking event was triggered by _elimiating_ bdb. |
| 17:45:03 | bramm: | gmaxwell, Oh you mean the non-bdb nodes had more permissive acceptance criteria? |
| 17:45:05 | sipa: | bramm: a system with infinite transaction volume but only a google-size datacenter can validate is not more useful than the current banking system; a system which doesn't allow anyone but a big national banks to do transactions isn't more useful either |
| 17:45:24 | bramm: | sipa, I didn't say it's bad, I said it cuts both ways |
| 17:45:31 | bramm: | I understand the reasoning |
| 17:45:35 | sipa: | bramm: yes, i agree; just clarifying |
| 17:45:38 | gmaxwell: | Effectively fixing the 'bug' of BDB's mystical locking insanity, (where you could use 2x the locks expected from your transaction depending on the disk layout) made the fixed nodes (more) inconsistent with the rest of the network. |
| 17:46:12 | bramm: | gmaxwell, still triggered by weird implicit stuff in bdb. You want all limitations to be explicit rather than implicit. |
| 17:46:19 | sipa: | bramm: fully agree there |
| 17:46:34 | sipa: | (which is why we're happy to not use bdb in consensus code anymore :p) |
| 17:46:45 | gmaxwell: | bramm: yes agreed, the point I was making was that BDB was bad and stupid and implicit, ... but the 'fixed' version was faulty. |
| 17:47:05 | sipa: | right; the new version was at fault for not mimicking the existing rules of the system |
| 17:47:17 | bramm: | Well yes, once the implicit behavior is part of the de facto spec you have a real problem on your hands. |
| 17:47:17 | sipa: | and the old version was buggy because it didn't do what people expected it to do |
| 17:47:24 | gmaxwell: | and in particular, doing so in an uncontrolled way. |
| 17:47:38 | sipa: | we've used such implicit things before in a positive way too |
| 17:47:58 | sipa: | for example compressed public keys were not known when satoshi designed the system, but every node accepted them, so we could just start using them |
| 17:48:11 | gmaxwell: | bramm: sadly thats always the case. There is always some implicit behavior, though you do say 'such' ... indeed, thats a pretty bad example. |
| 17:48:18 | bramm: | What's a compressed public key? |
| 17:48:35 | sipa: | one which only encodes the x coordinate of the elliptic curve point, and uses 33 bytes |
| 17:48:44 | sipa: | instead of encoding the x and y coordinates, for 65 bytes |
| 17:48:54 | gmaxwell: | * gmaxwell contines to hate the description 'compressed public key' considering the compression consists of a bit test and truncation. |
| 17:49:16 | bramm: | doesn't that make transactions bigger, because they have to include the missing information? |
| 17:49:23 | sipa: | there is no missing information |
| 17:49:24 | gmaxwell: | No, there is nothing missing. |
| 17:49:30 | sipa: | you can compute the y coordinate from the x coordinate |
| 17:49:41 | Alanius: | how about the sign of the y coordinate? |
| 17:49:44 | gmaxwell: | The x coordinate alone is sufficient (well, with one additional bit, which is provided) |
| 17:49:52 | sipa: | Alanius: that's why it's 33 and not 32 bytes :) |
| 17:51:57 | bramm: | Very strange that the 'compressed' version wasn't how it was done to begin with |
| 17:52:23 | sipa: | it wasn't how openssl encodes keys by default; that's all |
| 17:52:32 | sipa: | satoshi seems to just have used whatever openssl gave him |
| 17:52:40 | lclc: | lclc is now known as lclc_bnc |
| 17:53:54 | bramm: | sipa, Which leads to the question of why openssl does that, which probably has the answer 'because openssl' |
| 17:54:02 | gmaxwell: | Well lots of people are unaware of it. Most of the time EC math is written out using the full x/y. Handling compressed points does require some more code. Also in some cases there were until recently patent considerations (which were themselves insane, considering that the first publication on ECC mentioned that you could send X only) |
| 17:54:27 | sipa: | bramm: there's also a reason why we're trying to get rid of the openssl dependency in consensus code :) |
| 17:54:38 | gmaxwell: | bramm: many protocols require x,y. As an example, the OpenPGP spec for ECC (with the nist curves) prohibits point compression. |
| 17:55:16 | bramm: | gmaxwell, pgp is another example of something which one might not necessarily want to emulate |
| 17:56:01 | bramm: | sipa, the received wisdom on openssl seems to be that the insides are a greater horror than you imagine, if when you take into account that they're a greater horror than you imagine. |
| 17:56:07 | gmaxwell: | Yea, sure. Just pointing out the landscape. |
| 17:56:27 | sipa: | bramm: believe me, i disliked openssl before it was uncool :p |
| 17:57:03 | gmaxwell: | Agreed on openssl not being lovely (and we're long on the record of being unhappy with it); the burried headline is that most software is awful and full of holes. |
| 17:57:41 | gmaxwell: | As I mentioned in that bct thread; I don't consider my own software to be well tested until I've found a novel toolchain or system library bug. |
| 17:58:00 | gmaxwell: | Which I never fail to find. |
| 17:58:05 | bramm: | In bitcoin, when a utxo is locked on a preimage, does it specify which hash algorithm must be used beforehand? |
| 17:58:30 | gmaxwell: | the scriptpubkey specifies the hash algorithim used. |
| 17:58:40 | bramm: | Oh good |
| 17:58:50 | Alanius: | if it didn't ... you could just design a really bad hash function that produces the desired result |
| 17:59:10 | bramm: | so probably reasonable for interoperability is to support sha256 and sha3, also with specifying which hash function |
| 18:00:02 | gmaxwell: | the scriptPubKey is literally a bit of program for our hobbled forth like stack machine which must return true for the spend to be permitted, so hash preimage locking is a bit of code that does something like "OP_RIPEMD160 OP_EQUALVERIFY" |
| 18:00:07 | bramm: | Alanius, I'm thinking about the atomic transactions protocol. If different currencies supported different secure hash algorithms for the preimage, that would lead to a trivial and horrible attack |
| 18:02:25 | bramm: | Back on the subject of how the acceptance criteria has to be *exactly* the same |
| 18:02:53 | bramm: | Also the accepted lengths of the preimage string need to be the same |
| 18:04:13 | gmaxwell: | or tested, if there is an oppturnity for differences. |
| 18:05:57 | gmaxwell: | e.g. OP_SIZE 20 OP_LESSTHANOREQUAL OP_VERIFY OP_RIPEMD160 OP_EQUALVERIFY |
| 18:06:26 | tacotime: | are there dangers to point compression? |
| 18:08:27 | gmaxwell: | it's a bijection. The dangers are that you implement handling it wrong (dangers that exist everwhere), and until recently that you might get harassed by certicom patent trolling in some applications. (though, their patent was far narrower than 'point compression' and likely invalid in any case) |
| 18:09:16 | tacotime: | ah |
| 18:09:51 | gmaxwell: | assuming you need the x,y in the verifier, it's slower than not. Well: even if you have the alternative of doing your processing with x only, that ends up being slower than decompressing and working with the full coordinates. |
| 18:11:33 | tacotime: | well, pubkeys inclusion in scripts could be eliminated anyway if you just use the hash and signature to regenerate the full pubkey. but maybe that also has inherent dangers. |
| 18:12:55 | tacotime: | i'm guessing it's also probably more expensive than even decompressing the compressed key. |
| 18:13:16 | gmaxwell: | tacotime: There is a recently published patent application in that space (as in during 2012), it may well be invalid; but presumption of validity and all that. |
| 18:13:45 | bramm: | My approach to patent trolls is to tell them 'I fucked your mother and she sucked' |
| 18:13:46 | gmaxwell: | (oh sorry 2013) |
| 18:14:12 | gmaxwell: | In any case, it's a consideration. |
| 18:14:28 | gmaxwell: | tacotime: yes, and also requires some additional bits for the recover, and is also even easier to get wrong. |
| 18:14:44 | bramm: | As a general rule, you should always assume that anything you do is in principle already covered by some patent troll but that patent is invalid |
| 18:14:52 | tacotime: | gmaxwell: yeah, i figured the latter, heh. |
| 18:15:53 | gmaxwell: | bramm: there is a difference between the undifferentiated mass of everything being patented and stuff which is actively enforced, though. (I just mention that the patent is potentially invalid because the technique was published a long time ago, but I didn't do enough review to see what they were claiming for priority) |
| 18:15:53 | tacotime: | i guess end of the day the savings aren't huge in terms of space either, it's just num_transactions * constant |
| 18:16:52 | gmaxwell: | the certicom ecc stuff is somewhat notorious for good reason, even if you can successfully tell them to bugger off; dealing with it has a cost which is a consideration. |
| 18:17:10 | kanzure: | i wrote up some thoughts about a unique method of patent reform, https://groups.google.com/d/msg/openmanufacturing/vS4ju1VqXb0/jD_TZ8U47b4J |
| 18:19:07 | bramm: | When do the certicom ecc patents run out? |
| 18:19:42 | gmaxwell: | constantly. |
| 18:20:15 | kanzure: | in the department of weird stuff with reorgs, would it be helpful to have schemes where old/deep private keys are revealed (if the public address only had outputs specifically for the purposes of the current payment), such that anyone with a "stake" in having that transaction existing could sign (in the event of a reorg) the original transaction chain back into existence? |
| 18:20:34 | kanzure: | *in the event of a reorg and other scenarios of course |
| 18:20:42 | kanzure: | (since there's no way to make something reorg-only. that's not what i'm suggesting.) |
| 18:21:03 | gmaxwell: | I mean they have hundreds of patents, most are completely uninteresting over weird curves that sane people wouldn't use (well.. mostly targeting smartcard stuff that trades off security for power, not totally insane). They have patents expiring all the time. There are quite a few more interesting ones expiring this year +/-. |
| 18:22:29 | gmaxwell: | EC in general is pretty solid patent wise. See the beautiful IETF foundations of EC RFC... |
| 18:23:12 | kanzure: | instead of giving a signed transaction, you would give the private keys to the outputs, and then a signed transaction can be made from those outputs (as long as the outputs total up to the correct/intended balance). really what needs to be preserved/secured is the destination of the payment- since the outputs are being spent anyway, you shouldn't care that someone else can sign a new transaction from those outputs to whatever address. |
| 18:23:24 | kanzure: | there's probably something impossible about this that i am overlooking |
| 18:23:49 | kanzure: | *from those outputs to that one address(es) |
| 18:24:14 | gmaxwell: | kanzure: yes that can be done, though it potentially results in finger pointing when a recipent decides to pass along keys instead of re-transacting an output. |
| 18:24:29 | gmaxwell: | and, of coure, if someone reuse an address ... poof gone. |
| 18:24:54 | kanzure: | well my interest here is something like a concern with not being able to rely on everyone in the history of bitcoin transactions to re-sign their transactions in the event of a catastrophic reorg |
| 18:25:02 | gmaxwell: | It also demands a private channel between sender and reciever which is reasonable but bitcoin has made people lazy; and so they're overly depending on the consensus network for that purpoe. |
| 18:25:06 | gmaxwell: | er purpose. |
| 18:25:20 | kanzure: | instead of relying on people in the past who were involved in the transaction tree to sign things, i should be able to sign it myself based on my cumulative knowledge of uh.. private keys.. or some sort of restricted private key... or something.. |
| 18:25:33 | kanzure: | right, i agree this would totes require a private channel of some kind |
| 18:26:09 | gmaxwell: | kanzure: I don't think thats reasonable in any case, I mean, ideally private keys should be staying inside HSMs. You're not going to successfully get people to reissue transactions in some huge reorg, they may not be able to do so. |
| 18:26:52 | kanzure: | exactly, but people who have recently received payments may be able to be motivated to try to re-sign old transactions if they have the capability to do so |
| 18:27:08 | kanzure: | your transaction tree may have involved some dead guy what now. etc. |
| 18:28:12 | gmaxwell: | kanzure: yea sure, but it also may involve people who just refuse, judgement proof unfindable, and already recieved theirs. And having to keep keys _online_ to accomidate that is a constant security evil against a case which presumably can only happen if the system has already failed. |
| 18:28:15 | kanzure: | communicating private keys would be bad because that just means any alternative transaction can be signed, which isn't the point |
| 18:29:43 | kanzure: | so there might be some construct that would allow this behavior without being an actual private key |
| 18:30:43 | kanzure: | txin would probably have to be modified so that it's not just txid and vout. |
| 18:35:07 | kanzure: | anyway using this other construct would mean that massive reorgs would not be detrimental |
| 18:35:14 | kanzure: | and would not imply total system failure (if adopted) |
| 18:38:29 | andytoshi: | kanzure: what exactly would the key be restricted to? signing transactions whose output sets are the same as the original? |
| 18:39:22 | kanzure: | as long as txin is (txid, vout) that's not going to work |
| 18:40:27 | kanzure: | i don't know, have there been any proposals for more elaborate structs for txin? |
| 18:40:29 | andytoshi: | kanzure: it's not obvious to me what would work here, but i suspect that if you come up with something concrete you can do it by signing different parts of the tx with different keys, and having all keys within a transaction sign each other |
| 18:41:19 | kanzure: | when anything is changed in the transaction tree/history, txid changes, so txin becomes invalid, and allowing anyone to sign for any txid is obviously broken |
| 18:41:35 | andytoshi: | right |
| 18:41:37 | andytoshi: | in case of a reorg, the need to re-sign actually reflects the fact that the owner of the old coins needs to sign off on the new history, i.e. this is something that actually conceptually requires reauthorization |
| 18:41:54 | andytoshi: | i think |
| 18:42:05 | kanzure: | i am not sue if that is universally true. there may be a way to sign something that says "i am committing to this particular history and i am okay with any other competing history that says the same thing" |
| 18:42:31 | kanzure: | it is some sort of collaborative agreement about the direction of future-history or something (in concept at least) (not necessarily in current implementation) |
| 18:43:42 | kanzure: | i agree that in some alternative histories there may be transactions that disappear or appear that change your solvency or something |
| 18:43:53 | kanzure: | but if you only use this certain class of transactions, then you may be protected from that? |
| 18:45:58 | andytoshi: | would the ability to reference outputs by scriptpubkey cover it? |
| 18:46:20 | andytoshi: | there is some problem with that (other than the uniqueness requirement it puts on scriptpubkeys) that i never can remember.. |
| 18:48:54 | kanzure: | possibly |
| 18:49:08 | andytoshi: | iirc i said at some point here that if i had an alt i would reference outputs that way, and somebody said "oh no, [bad thing] would happen" |
| 18:49:21 | kanzure: | i suspect a good solution will come out of further elucidation of "the need to re-sign actually reflects the fact that the owner of the old coins needs to sign off on the new history" and other properties or requirements of what the hell a transaction actually means |
| 18:50:00 | andytoshi: | yeah, absolutely. that's not something i can do off the top of my head (at least not while i'm doing other crypto afk :P) |
| 19:04:27 | kanzure: | really the main thing you care aobut is preserving the ability of others that receive your bitcoin to continue to spend your bitcoin however they please in the future or however they already have chosen to spend it, to the extent that the system also preserves your ability to do the same. |
| 19:04:35 | kanzure: | *about |
| 19:28:31 | instagibbs: | new arxiv paper from Cornell guy on mining as a prisoner's dilemma: http://arxiv.org/pdf/1411.7099v2.pdf |
| 19:28:50 | instagibbs: | new-ish |
| 19:40:55 | Aquent2: | Aquent2 is now known as Aquent |
| 19:49:01 | gavinandresen: | instagibbs: executive summary of that paper is: anybody-can-join-anonymously mining pools are probably doomed. Not a terrible thing, in my opinion, it might drive more solo mining or more smaller ‘trusted circle of people’ pools. |
| 19:49:58 | gavinandresen: | … if it drives people to ‘cloud hashing’ then that’s bad, but I think we’re just about due for a bunch more big disastrous cloud hashing fails. |
| 19:50:10 | instagibbs: | let us hope |
| 19:51:43 | gavinandresen: | also: Loi Luu has a paper under submission on the same subject; see https://twitter.com/gavinandresen/status/537247892252413952 |
| 19:53:22 | bramm: | I don't know how many of you are in the bay area, but the weather out there SUCKS |
| 19:54:28 | tromp_: | i'll swap your bay area weather for my long island weather |
| 19:54:35 | instagibbs: | gavinandresen: interesting. Ghash is <20% these days, if you believe the numbers. Wonder how widespread the share stealing is today. |
| 19:55:30 | gavinandresen: | I’m headed to the bay area for a few days in a couple of weeks, I expect you to make it nice and warm and sunny by then. |
| 19:56:07 | instagibbs: | I'll swap too. East Coast has been disgusting all week |
| 19:56:09 | lechuga_: | there is no happy medium here |
| 19:57:36 | bramm: | gavinandresen, It is winter, and it's northern california, so it probably won't be sunny |
| 19:58:37 | gavinandresen: | bramm: summer is the foggy season in san francisco, winter was usually nice (i was in silicon valley from ’88 to ’96) |
| 20:02:01 | zooko: | Things are cold but dry and sunny, here in Colorado. |
| 20:03:30 | bramm: | tromp_, I claim California priviledge :-) |
| 20:11:25 | bramm: | Is it reasonable to call atomic transfers 'smart transactions'? |
| 20:19:08 | bramm: | They seem to be called that in the literature, so it would seem reasonable for a cryptocurrency to say it 'supports smart transactions' if it supports atomic transfers. |
| 20:21:00 | bramm: | Much as that might piss off the ethereum people |
| 20:36:04 | nsh-: | i thought the bar for a smart transaction was the evaluation of at least one non-ledger input |
| 20:36:24 | nsh-: | or non-monetary input |
| 20:38:55 | nsh-: | nsh- is now known as bnsh |
| 20:45:26 | bramm: | bnsh, I don't know what that means |
| 20:45:55 | bramm: | And doesn't a hash pre-image count as a 'non-ledger input'? |
| 20:46:16 | bnsh: | * bnsh reads more context |
| 20:46:22 | bnsh: | bnsh is now known as nsh |
| 20:47:24 | jgarzik: | 'smart transaction' seems to be a new term. 'smart contract' and 'smart property' are known, and a bitcoin transaction is most often a smart contract in its entirety (at least until more advanced smart contract protocols appear) |
| 20:47:38 | nsh: | yeah, so an atomic transfer would be smart because it depend on some information not derived from previous txouts or signatures of private keys |
| 20:48:21 | nsh: | (but i'm not trying to suggest my vague understanding is a good working definition or anything) |
| 20:50:39 | bramm: | nsh, atomic transfers involve the revealing of a hash preimage |
| 20:50:45 | nsh: | * nsh nods |
| 20:53:04 | bramm: | And truth be known, atomic transfers may be the overwhelming bulk of smart transactions people might actually want |
| 20:56:00 | nsh: | well, people have a hard time wanting things of which they can't conceive |
| 20:56:07 | nsh: | but even still, very useful |
| 21:00:00 | bramm: | I'm hazy on what the problem is with transaction malleability. As long as a double-spend is prevented, where's the problem? |
| 21:01:22 | lechuga_: | crappy impls get confused |
| 21:01:37 | bramm: | Define 'crappy' and 'confused' |
| 21:01:38 | lechuga_: | is my observation |
| 21:01:56 | bramm: | I mean, as long as it's clear which utxo is used... |
| 21:02:15 | lechuga_: | so i guess the gox exampel is a good one |
| 21:02:42 | lechuga_: | iirc they had an api endpoint which would show u 'stuck' txs |
| 21:02:53 | bramm: | I heard something about malleability in regards to gox, which might have been complete bullshit |
| 21:03:01 | bramm: | What is a 'stuck' transaction? |
| 21:03:17 | lechuga_: | not accepted by the network |
| 21:03:23 | kanzure: | mtgox could have easily been using txid as an id, but whether or not this caused mtgox's demise is another matter |
| 21:03:28 | lechuga_: | im really hazy as to what the root issue was |
| 21:03:40 | lechuga_: | in nay case someone observed what the issue was |
| 21:03:40 | andytoshi: | lechuga_: the gox story was bullshit, but i have a writeup from when we believed it was true.. |
| 21:03:41 | lechuga_: | any* |
| 21:03:53 | andytoshi: | lechuga_: https://download.wpsoftware.net/bitcoin/malleability-faq.pdf |
| 21:04:05 | lechuga_: | and recreated tha txs such that they were now relayble but had different hashes |
| 21:04:10 | lechuga_: | the* |
| 21:04:21 | lechuga_: | and presumably peopel were already refunded for their 'stuck' txs |
| 21:04:23 | kanzure: | bramm: one of the biggest problems with transaction malleability is that most bitcoin implementations (all of them) do not automatically re-create transactions that have become invalidated by a mutated transaction |
| 21:04:24 | lechuga_: | and now got double-paid out |
| 21:04:46 | lechuga_: | andytoshi: nice thx |
| 21:05:29 | kanzure: | any accepted mutant transaction will invalidate any other transactions that relied on the previous txid |
| 21:05:46 | lechuga_: | right and that |
| 21:05:47 | kanzure: | (because transactions reference prior outputs by txid) |
| 21:07:12 | bramm: | kanzure, but doesn't that only apply if the history gets reworked? |
| 21:07:27 | kanzure: | there are also other weirdo philosophical issues like "if a transaction history tree is practically identical to a prior transaction history tree, but the first origin transaction now has an extra input or extra output, should all of the transactions further in the tree be considered different now?" |
| 21:07:33 | bramm: | gox most likely fell for the 'oops we accidentally your whole balance' attack |
| 21:07:49 | kanzure: | transaction malleability applies during reorgs and even prior to inclusion in a block |
| 21:08:15 | jgarzik: | gox blamed malleability. that claim is suspect. |
| 21:08:24 | bramm: | Well you probably shouldn't do transactions based on older transactions which aren't very deep |
| 21:08:27 | kanzure: | also, arguably malleability is not a protocol bug. |
| 21:08:34 | lechuga_: | yeah pls dont take my retelling of that story to imply it is factual |
| 21:08:56 | kanzure: | bramm: even the transactions you do on your own are malleable by others (even if they are not the signer) |
| 21:09:12 | lechuga_: | but it's an interesting example even if fictitious |
| 21:09:20 | bramm: | Okay, I've put the malleability FAQ on my list of shit to read |
| 21:09:26 | lechuga_: | heh |
| 21:09:27 | bramm: | kanzure, I can see how that's a problem, true |
| 21:09:27 | kanzure: | the only way to guarantee a transaction is never mutated is to never broadcast a transaction and never relay the transaction to anyone, ever |
| 21:09:52 | bramm: | I'm out for the day - going without my computer until this evening, laters everybody |
| 21:10:48 | kanzure: | * kanzure checks that kanzure is not full of crap, https://download.wpsoftware.net/bitcoin/malleability-faq.pdf |
| 21:11:15 | kanzure: | "Therefore, malleating a transaction cannot reroute funds or invalidate |
| 21:11:24 | kanzure: | er, they can certainly invalidate future transactions |
| 21:11:42 | kanzure: | or i should say, dependent-future transactions... |
| 21:13:53 | andytoshi: | kanzure: so, the surrounding context of that document was that i had been sleeping 3 hours a day for about ten days, ever since the gox claims came out, explaining this stuff on irc |
| 21:14:29 | andytoshi: | and there was the usual irc burnout, plus i was really angry at them, and some people i knew had been screwed, and things were really emotionally charged |
| 21:14:39 | andytoshi: | so correctness is not guaranteed :) |
| 21:15:02 | andytoshi: | but the specific claim "malleating a tx cannot invalidate it" is right, it can't invalidate the tx itself |
| 21:15:27 | andytoshi: | well, that's not quite true, with SIGHASH flags you can make a tx which can be broken after the fact.. |
| 21:15:37 | kanzure: | hrmm the way that transaction chains are structured or the transaction tree or whatever is sorta unfortunate, but an alternative is not obvious |
| 21:17:14 | kanzure: | txin could reference a prior signaturehash instead of a prior txid? |
| 21:17:55 | kanzure: | oh, order of outputs can change hmm. |
| 21:19:53 | kanzure: | each output should be referenced by transaction signaturehash + output amount. nobody cares about the exact order... |
| 21:20:32 | kanzure: | oh.. that still doesn't work. |
| 22:12:14 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 23:44:12 | c0rw|awa_: | c0rw|awa_ is now known as c0rw1n |
| 23:53:51 | nullbyte_: | nullbyte_ is now known as Guest46653 |