00:00:04bramm:phantomcircuit, That was a very sophisticated attacker
00:00:49phantomcircuit:bramm, it really wasnt
00:01:16bramm:phantomcircuit, You might be giving a bit much credit to unsophisticated attackers :-)
00:01:19phantomcircuit:it was just someone who was bored and not afraid of jail
00:01:48midnightmagic: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:06phantomcircuit:afaict they just abused a published exploit in tp link routers that basically was just default snmp permissions being set wrong
00:02:07bramm: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:41phantomcircuit:the scanning the internet bit was maybe sophisticated
00:02:45phantomcircuit:the breaking in? not so much
00:03:00midnightmagic:i don't recall anybody seriously suggesting a dht even just for block propagation
00:03:36bramm: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:01sipa:optimizing for latency makes sense, but isn't a 100% win either
00:04:37midnightmagic:bramm: that would likely fail the connectivity benefits of a randomized peer selection
00:04:38sipa: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:12bramm:midnightmagic, It can do better than random actually, but also requires a fair number of connections
00:06:05phantomcircuit: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:15bramm: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:24midnightmagic:bramm: The benefit of a strong, unpredictable connectivity graph are more important than latency
00:06:43sipa:well, latency matters for scaling
00:06:46phantomcircuit:bramm, uh ok maybe your definition of sophisticated is different then mine
00:07:14sipa:yeah, i don't think anyone here was too worried about script kiddies
00:08:44bramm: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:23bramm:I just turned off spelling 'correction', sorry about that.
00:12:51midnightmagic: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:59phantomcircuit:bramm, peer selection for the p2p protocol is actually more similar to relay selection in tor
00:13:14phantomcircuit:which they haven't gotten right either :/
00:24:39bramm:I suppose peer selection it bit coin has two separate goals: anonymity and connectivity. Unfortunately these are in direct conflict :-P
00:25:20sipa:if you're not running a wallet, there is little privacy to lose or gain
00:25:39sipa:as a miner perhaps you don't want to be attackable, and being unknown helps
00:25:59sipa:also, there is connectivity and latency
00:26:00phantomcircuit:sipa, yeah i was thinking there should be guard nodes which are long lived that receive wallet transaction broadcasts
00:26:07sipa:which are also in conflict with eachother
00:26:22phantomcircuit:and another group of nodes which are cycled on staggered schedules
00:26:30sipa:latency matters, because it correlates directly with block propagation speed
00:28:12bramm: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:35bramm:And when you're sending stuff out first send to a random peer and then to your lowest latency peers
00:29:40phantomcircuit:bramm, you basically never want to send wallet txs to low latency peers actually
00:30:07phantomcircuit:not without significant forethought
00:30:12midnightmagic:i thought block chain consensus is still convergent up to absurd maximums and out past the moon
00:30:45phantomcircuit:midnightmagic, convergent yes, but with stupid high latency links you might end up with lots of tiny reorgs
00:31:34bramm:So is there anything other than signatures, locktime, and preimages which a coin can be contingent on?
00:33:46dgenr8:bramm: the coin's script can define intricate requirements for spending it
00:33:52Eliel_:it's possible to require the spending transaction to provide data that hashes to a specific hash.
00:33:54lechuga_: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:16lechuga_:unless specified by the output's script
00:34:18Eliel_:but yes, it's scriptable so, a lot of things are possible
00:34:24midnightmagic:who was it who appeared to do some actual calculations for blockchain convergence.. amiller I think? or andytoshi?
00:34:25dgenr8:bramm: have you looked at the bitcoin "payment channel" work?
00:34:38bramm:dgenr8, no, got a link?
00:34:42dgenr8:bramm: https://bitcointalk.org/index.php?topic=244656.0
00:34:45sipa:midnightmagic: convergence isn't enough; if there's a 40% forking rate, you're giving a 40% advantage to a collusion attacker
00:34:55bramm:Presumably the sidechains stuff adds all kinds of new possible contingencies
00:35:26amiller:midnightmagic, i never computed anything
00:36:01sipa:amiller did come with the auto-adjusting block rate, to basically aim for (iirc) 50% forking rate
00:36:20midnightmagic: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:42bramm:What is this 'forking rate'?
00:36:51amiller:rate of stale blocks
00:36:54sipa:bramm: how many mined blocks don't end up in the active best chain
00:37:42sipa:because the finder of the following block hasn't seen the previous one yet
00:38:14bramm: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:39:10sipa:as long as the ratio is large between them, that rule holds pretty well
00:39:37bramm: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:37sipa:if it's smaller you need to take the actual interblock interval distribution into account
00:39:54sipa:but as i said: just convergence isn't enough
00:40:04sipa:because it assumes no attackers
00:40:30bramm:I think 10 minutes between blocks is a bit excessive
00:40:43sipa:maybe it could have been 1-2 minutes
00:40:58bramm:2 minutes is already quite conservative
00:41:00phantomcircuit:except that would give larger miners an advantage
00:41:00sipa: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:09bramm:Not that 10 minutes is particularly problematic
00:41:32sipa:and therefore doesn't suffer from the forking rate that is the result of the distance/propagation delay between miners
00:41:52bramm:Right, large miners can keep their own forks and force a reorg with some reliability
00:41:58sipa:right now i think there is like 1-2%?
00:42:07bramm:The lack of credit for partials is a bit of a problem here
00:42:37sipa: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:00sipa:credit for partials?
00:46:59andytoshi:midnightmagic: i didn't do those calculations either
00:48:26midnightmagic::-/ was it just an eyeballing/estimate based on 10 minutes of speed-of-light from the surface of the earth then?
00:50:14midnightmagic:gmaxwell stop making yourself useful and stand in as my offloaded memory
00:52:07midnightmagic:.. 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:20bramm: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:32sipa:what are partials?
00:52:36bramm:or some variant thereof, there are a few different ways it could be set up with different tradeoffs
00:52:54bramm: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:05sipa:ah, right
00:53:08bramm:And also reinforces the validity of whatever you were mining off of
00:53:10sipa:p2pool shares, bacially
00:53:13dgenr8:bramm: see asic-faq question 5
00:53:58bramm:dgenr8, Do you mean proofs of stake or something else?
00:54:21amiller:"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:47dgenr8:no credit for partials = a "progress-free" PoW
00:54:57amiller:not really
00:54:58bramm:amiller, I'm not sure what you mean by 'nonoutsourceable' but I think I agree with you
00:55:13amiller:bramm: see http://cs.umd.edu/~amiller/nonoutsourceable.pdf
00:55:39bramm:Okay, that goes on my list of stuff to read
00:56:12bramm: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:06bramm:I sometimes get pulled away by a meatspace DOS attack. It typically starts with DADDY I'M HUNGRY
00:59:38nsh:and then your child summons a million tiny zombies?
01:00:09nsh:because that is probably not considered normal development behaviour before adolescence at least
01:00:14nsh:oh, my bad, you didn't actually say DDoS
01:00:25nsh:* nsh returns to cave
01:02:22andytoshi:midnightmagic: my guess is maaku
01:02:47andytoshi:it's also possible that gmaxwell or i did it, i'm sure i remember talking about it
01:21:35c0rw1n:c0rw1n is now known as c0rw|sleep
01:47:30PRab_:PRab_ is now known as PRab
01:55:30super3:amiller: you around?
02:01:28bramm: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:09PRab_:PRab_ is now known as PRab
02:12:52instagibbs_: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:33instagibbs_: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:04instagibbs_:66 particularly
02:22:20phantomcircuit:instagibbs_, that's a pretty large conditional
02:23:38instagibbs_:*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:40phantomcircuit:and the effect is actually very small
02:27:46instagibbs_: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:41bramm:What are the main practical incentives for mining pools?
02:30:09phantomcircuit:bramm, reduced variability in reward
02:30:47phantomcircuit:mining by yourself is unlikely to ever return a reward until you approach significant mining size
02:30:52instagibbs_:that, and with "hosted mining" you don't actually have to run anything
02:31:01instagibbs_:or run a full node...
02:31:16instagibbs_:but casting those aside, what phantomcircuit said
02:36:58amiller:super3, hi
02:37:49super3:how have you been?
02:38:18amiller:bramm, yeah so 'nonoutsourceable' raises the distrust *against* pooling, having p2pool shares "integrated" into the official rules reduces the incentive *for* pooling...
02:38:47amiller:the story for anti-hosted-mining is a lot sketchier :/
02:39:01amiller:busting up pools without also busting up hosted mining seems like a net negative, pools seem lesser of two evils
02:39:10amiller:super3, good! thanks, what you up to?
02:39:39super3:seeing how many hard drives it takes to get to the moon
02:40:28bramm:What do you mean by 'hosted mining', and what's the problem with it?
02:40:52phantomcircuit:bramm, you pay me money, i buy hw and runt he hw for you
02:41:02amiller:hosted mining is roughly when someone pays a large corporation to run some mining rig in a data center somewhere
02:41:14phantomcircuit:effectively i control which transaction your money pays to mine
02:41:28amiller:due to economies of scale, orgs like this can offer better deals the more consolidated they are
02:41:32bramm:I don't see how hosted mining is a problem, or avoidable. Practically everything is hosted services these days.
02:41:54amiller:hosted mining is a consolidation of power
02:42:05super3:i mean my main thing about nonoutsourceable is that it would be impossible to integrate into bitcoin
02:42:06bramm: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:08amiller:someone could go blackmail the administrator of that organization
02:42:12bramm:Like memory. Cuckoo might help.
02:42:37phantomcircuit:amiller, otoh individuals who are bad at calculating costs might not realize what the economies of scale really are
02:42:44amiller: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:49phantomcircuit:(this has been an issue selling people contracts recently)
02:42:52amiller:cuckoo removes the incentive by reducing the benefits of consolidation
02:43:20amiller: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:43phantomcircuit:amiller, kind of doubt it
02:43:55phantomcircuit:virtually nobody asks for proof of anything
02:44:01amiller:phantomcircuit, yeah, well, you and apparently everyone else, i haven't had an easy time getting any traction for this
02:44:12phantomcircuit:nearly everybody just calculates expected returns and compares with actual return
02:44:15amiller:the pessimistic view is that everyone is already totally trusting of big organizations
02:44:34amiller:phantomcircuit, yes okay, so, there is an implicit assumption there about how things *already* work, and i propose to change that.
02:44:44amiller:right now, there is no super jackpot
02:44:49instagibbs_: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:51amiller:you get the 25 btc every 10 minutes, that's the only lotto game there is
02:45:06rusty:amiller: or they are happy with the exposure being limited to the time it takes them to xfer out their profits?
02:45:11super3:not because of technical reasons, but existing miners will just reject it
02:45:18amiller:suppose you got 20 btc every 10 minutes most of the time, but *sometimes* you win a 10000 btc jackpot
02:46:01instagibbs_:amiller you have a dumping ground for lotto-style mining thoughts? or are they just rattling around
02:46:07rusty:amiller: ah, so you're trying to use that to change the trust dynamics. Interesting idea...
02:47:03amiller: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:18phantomcircuit:amiller, oh right
02:47:22phantomcircuit:yeah that might change things
02:47:41amiller: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:27instagibbs_:im interested because I'm quite doubtful of long-term PoW if people are actually mining at cost
02:53:45amiller:if the economics of this are anything like state lottos, then people will be mining at less -than-cost
02:54:08instagibbs_:*assuming you mean -EV*
02:54:17bramm:When are rewards going to drop by half again?
02:54:20instagibbs_:I read that post a long time ago
02:56:14bramm:I wish it was sooner. It will be interesting to see what happens on the next drop
02:57:06kanzure:block 420000
02:57:16kanzure:best to measure time by number of blocks rather than 2016
02:58:30bramm:What block number is it on now?
02:58:48bramm:I wonder how many miners are going to wonder why their revenues suddenly dropped by half
02:59:10kanzure:current blockheight is approximately 332650 depending on who you are
02:59:17kanzure:or rather, depending on which nodes you know
02:59:26kanzure:(because 332651 is out there)
03:16:27bramm:So that's early 2016 probably
03:18:31phantomcircuit:amiller, its not enough of a lottery for that really
03:19:53amiller:not now it isn't :/
03:19:55bramm:I have a question about the atomic transactions protocol
03:20:12amiller:bramm, the tiernolan one?
03:20:18bramm:amiller, yes that one
03:20:43amiller:i know that one, i want to help!
03:20:58bramm: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:00kyletorpey:kyletorpey has left #bitcoin-wizards
03:26:15amiller:you can't make a "coin" (an unspent transaction output) unlockable
03:27:12amiller: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:05bramm:Ah, that's what I suspected
03:31:18bramm:So transactions can be time-locked but coins can't?
03:31:49bramm:I hope I'm not irritating everybody by saying 'coin' instead of 'unspent output'. It's just shorter.
03:33:12bramm:Okay I can use that. Is utxo short for something?
03:33:19lechuga_:unspent transaction output
03:33:25tromp_:unspent transaction output
03:33:52tromp_:just as short as coin!
03:34:35lechuga_:doubt any1 really annoyed by 'coin' tho
03:37:14lechuga_:re: OP_CHECKLOCKTIMEVERIFY, see also: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
03:37:31amiller: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:01amiller:bramm, exactly, a transaction can be timelocked but a utxo can't
03:56:31bramm:tromp_, I have a question about cuckoo
03:56:34op_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:37tromp_:yes, bramm?
03:58:00bramm:tromp_, Does it need something as strong as siphash? Could it use something weaker like, say, a single round of AES?
03:58:33bramm:Or is a single round of AES about the same as siphash?
03:58:37tromp_:i tried with reduced rounds, even down to siphash11, and couldn't see any effect on cycle length distribution
03:58:52bramm:What is siphash11?
03:59:23tromp_:normal siphash is siphash 24, 2 rounds of one kind and 4 rounds of another kind
04:01:06tromp_:for extra mixing power, some applications use siphash-4-8
04:02:40tromp_: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:07bramm:Are siphash-1-2 and AES about the same amount of CPU? Why 1-2 specifically?
04:03:42tromp_:just sticking with the ratio siphash-n-2n
04:03:52tromp_:doing half the work of siphash-2-4
04:04:32tromp_:i don't know offhand how 1round AES compares with siphash-1-2
04:06:02tromp_:but siphsah is designed for hash tables, which is really how it's used in cuckoo cycle
04:06:38bramm:I'd be curious to hear DJB's thoughts on reduced round siphash, in particular for that use
04:07:52tromp_:i asked him by email
04:08:11tromp_:it bounced:(
04:08:32bramm:huh, what was the reason for the bounce?
04:09:31tromp_:I have not received confirmation that this message is not bulk mail.
04:09:33tromp_:I'm not going to try again; this message has been in the queue too long.
04:09:54bramm:Huh, I've successfully corresponded with him before. Will try later.
04:11:53tromp_:AES is unnecessarily wide
04:12:50tromp_:i know someone who was trying to exploit the limited width of siphash to compute 4 of them in parallel with AVX
04:13:02tromp_:that might speed up cuckoo a bit
04:13:51bramm:cuckoo should be mostly waiting for memory
04:14:39bramm: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:40tromp_:yes, but once a thread is waiting for memory, you need another thread to compute the next siphash
04:14:56tromp_:the memory subsystem can handle many pending memory accesses
04:15:55tromp_:for cuckoo, hyperthreading beyond a factor of 2 (like on some sparc cpus) could be very beneficial
04:17:32bramm:Presumably custom hardware should be able to do that so the more that COTS hardware can do it the better
04:19:15tromp_:i'd love to try cuckoo on an intel xeon phi
04:19:38tromp_:my former academic institution has one, but it invariably crashes on cuckoo:(
04:21:20tromp_:gotta run; talk to you later...
09:05:16weber.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:16weber.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:16weber.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:16weber.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:16weber.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:16weber.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:27c0rw|sleep:c0rw|sleep is now known as c0rw|away
10:36:16lclc:lclc is now known as lclc_bnc
10:37:27lclc_bnc:lclc_bnc is now known as lclc
10:49:57wallet421:wallet421 is now known as wallet42
10:56:40samson2:samson2 is now known as samson_
11:54:01tobyai:tobyai has left #bitcoin-wizards
12:10:20op_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:27zz_lnovy:zz_lnovy is now known as lnovy
12:12:25op_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:36zz_lnovy:zz_lnovy is now known as lnovy
12:14:33fluffypony:lol X11
12:14:36Luke-Jr:op_null: non-outsourcable, eh? what happens when I just use a midstate?
12:15:32op_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:08Luke-Jr:op_null: what stops the pool from signing after a solution is found?
12:21:08Luke-Jr:I don't see that in there
12:23:51op_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:44Luke-Jr:s/interesting/funny/ <.<
12:25:25op_null:good point.
12:25:49op_null:as soon as you see "X11" though you know it's a joke.
12:28:37lnovyz:lnovyz is now known as lnovy
12:39:16zz_lnovy:zz_lnovy is now known as lnovy
12:46:35nubbins`:gross, had a buyer for my genesis block newspaper, now he's gone missing ;/
14:15:19lclc:lclc is now known as lclc_bnc
14:35:27lclc_bnc:lclc_bnc is now known as lclc
16:08:16lclc:lclc is now known as lclc_bnc
16:28:39lclc_bnc:lclc_bnc is now known as lclc
17:00:24bramm: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:24tromp_:what language would be less nuts, bramm?
17:06:00sipa: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:32sipa: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:38bramm:tromp_, python
17:07:52bramm:or java
17:09:18tromp_:i thought you were gonna say Rust
17:09:42sipa:Rust seems a very hopeful combination between safety guarantees and resource guarantees
17:09:42bramm:I'm not familiar with rust
17:09:56sipa:but i'm not very familiar with it, and it seem not very mature yet either
17:14:47bramm: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:31sipa: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:15tacotime:ehm, haven't there been a lot of memory expansion ddos attacks on bitcoind though? eg getutxos
17:19:22tacotime:or maybe i misread and you weren't antagonising gc-rich (hehe) languages
17:19:46bramm: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:39sipa:tacotime: bitcoin is by no means perfect wrt to guaranteeing resource limits
17:21:09sipa:i'm just making the general observation that using higher-level languages make it generally harder to reason about resources
17:21:18sipa:and c++ is higher-level in this regard :)
17:21:19bramm: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:59bramm: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:58sipa:well, the ultimate defense (but hardly optimal) against resource usage attacks is making the worst case equal to the average case
17:23:23sipa:and every optimization that doesn't actually improve the worst case doesn't actually help
17:24:24sipa:at least without making the attacker costlier
17:24:32andytoshi:most of the crypto is used in consensus code, we really really need that to be explicit
17:26:04gmaxwell:tacotime: kinda weird that you cite an example of code we rejected there.
17:26:09andytoshi:(and actually C++ is not explicit enough, its weak typing has caused eg the SIGHASH_SINGLE bug)
17:26:28tacotime:gmaxwell: ah, didn't realize that didn't make it to master
17:26:31sipa:andytoshi: that's just sloppy programming; returning an error code as a hash is just totally broken
17:26:52sipa:tacotime: it was, but never in a release (and it was controversial from the start...)
17:27:04andytoshi:sipa: sure, i'm just saying "totally broken" intersect "compiles" could be be a smaller set
17:27:06gmaxwell:tacotime: it was merged by mistake for a couple hours until people woke up.
17:27:25sipa:yeah, the person who merged it wasn't aware of some ongoing discussion about it still
17:27:48sipa:though that discussion was not about the resource usage problems of it, so maybe not all that relevant
17:31:28gmaxwell:Well, sort of circularly: it hadn't been reviewed because people had stopped on the architectural issues.
17:34:24bramm:How cleanly specced is the bitcoin protocol?
17:34:56bramm:Parsing is the #1 place where security problems come in, and sloppy formats are the #1 cause of parsing problems
17:35:22sipa:bramm: the p2p protocol is pretty well documented, but the consensus rules can't really be specified
17:35:28gmaxwell:We've never had a single issue related to that as far as I recall. The p2p protocol itself is pretty trivial.
17:36:08bramm:Not sure what you mean by 'consensus rules'
17:36:26andytoshi: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:30sipa:bramm: the rules that determine which block is valid
17:37:11sipa: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:17bramm:Fixed width has its advantaged and disadvantages. It works great as long as the practical values stay within range.
17:37:28gmaxwell: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:51andytoshi:bramm: https://en.bitcoin.it/wiki/Protocol_specification ... parsing is one thing that is very well-specced
17:38:10sipa:bramm: every node must independently come to the exact same conclusion about which block is valid or not
17:38:13bramm:I view block validation as part of the spec.
17:38:16gmaxwell:bramm: every system must perform an identical or at least indistinguishable computation or the network forks.
17:38:31sipa:you have no idea (really!) how nearly impossible that is from an engineering perspective
17:38:49bramm: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:13sipa:rigfht, but the point is that such a spec can only be descriptive, and not prescriptive
17:39:25sipa:if the code was found to not match the document, the document would need to be updated
17:39:29andytoshi:https://download.wpsoftware.net/bitcoin/alts.pdf sections 6.0 and 6.1 talk a little bit about this
17:39:37bramm:Correct. Maybe you could explain that to the w3c
17:39:38sipa:because consistency is more important than correctness
17:40:12sipa:(well, excluding totally crazy bugs that would allow stealing money probably...)
17:40:15gmaxwell: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:18andytoshi:lol i should make an alt with html transactions
17:40:34sipa:andytoshi: use JSONx
17:41:00sipa:bramm: we have had the network fork due to a default limit on the number of simultaneous locks bdb could hold
17:41:11gmaxwell: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:37sipa: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:43gmaxwell:sipa: even the limited wouldn't have been so bad, if it were determinstic in how it was enforced. :)
17:42:33gmaxwell:(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:40sipa:i don't think anyone even expected that number of locks to be effectively part of the network's consensus rules
17:42:50bramm: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:04sipa:that's a very important limitation :)
17:43:23sipa:and it's a well-known rule too, unlike that bdb issue
17:43:29bramm:It cuts both ways
17:43:44gmaxwell: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:59bramm: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:19sipa:bramm: the block size limit sets a compromise between scalability of transaction volume and scalability of running a full node
17:44:25gmaxwell:bramm: missing the point there, the forking event was triggered by _elimiating_ bdb.
17:45:03bramm:gmaxwell, Oh you mean the non-bdb nodes had more permissive acceptance criteria?
17:45:05sipa: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:24bramm:sipa, I didn't say it's bad, I said it cuts both ways
17:45:31bramm:I understand the reasoning
17:45:35sipa:bramm: yes, i agree; just clarifying
17:45:38gmaxwell: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:12bramm:gmaxwell, still triggered by weird implicit stuff in bdb. You want all limitations to be explicit rather than implicit.
17:46:19sipa:bramm: fully agree there
17:46:34sipa:(which is why we're happy to not use bdb in consensus code anymore :p)
17:46:45gmaxwell: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:05sipa:right; the new version was at fault for not mimicking the existing rules of the system
17:47:17bramm:Well yes, once the implicit behavior is part of the de facto spec you have a real problem on your hands.
17:47:17sipa:and the old version was buggy because it didn't do what people expected it to do
17:47:24gmaxwell:and in particular, doing so in an uncontrolled way.
17:47:38sipa:we've used such implicit things before in a positive way too
17:47:58sipa: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:11gmaxwell: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:18bramm:What's a compressed public key?
17:48:35sipa:one which only encodes the x coordinate of the elliptic curve point, and uses 33 bytes
17:48:44sipa:instead of encoding the x and y coordinates, for 65 bytes
17:48:54gmaxwell:* gmaxwell contines to hate the description 'compressed public key' considering the compression consists of a bit test and truncation.
17:49:16bramm:doesn't that make transactions bigger, because they have to include the missing information?
17:49:23sipa:there is no missing information
17:49:24gmaxwell:No, there is nothing missing.
17:49:30sipa:you can compute the y coordinate from the x coordinate
17:49:41Alanius:how about the sign of the y coordinate?
17:49:44gmaxwell:The x coordinate alone is sufficient (well, with one additional bit, which is provided)
17:49:52sipa:Alanius: that's why it's 33 and not 32 bytes :)
17:51:57bramm:Very strange that the 'compressed' version wasn't how it was done to begin with
17:52:23sipa:it wasn't how openssl encodes keys by default; that's all
17:52:32sipa:satoshi seems to just have used whatever openssl gave him
17:52:40lclc:lclc is now known as lclc_bnc
17:53:54bramm:sipa, Which leads to the question of why openssl does that, which probably has the answer 'because openssl'
17:54:02gmaxwell: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:27sipa:bramm: there's also a reason why we're trying to get rid of the openssl dependency in consensus code :)
17:54:38gmaxwell:bramm: many protocols require x,y. As an example, the OpenPGP spec for ECC (with the nist curves) prohibits point compression.
17:55:16bramm:gmaxwell, pgp is another example of something which one might not necessarily want to emulate
17:56:01bramm: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:07gmaxwell:Yea, sure. Just pointing out the landscape.
17:56:27sipa:bramm: believe me, i disliked openssl before it was uncool :p
17:57:03gmaxwell: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:41gmaxwell: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:00gmaxwell:Which I never fail to find.
17:58:05bramm:In bitcoin, when a utxo is locked on a preimage, does it specify which hash algorithm must be used beforehand?
17:58:30gmaxwell:the scriptpubkey specifies the hash algorithim used.
17:58:40bramm:Oh good
17:58:50Alanius:if it didn't ... you could just design a really bad hash function that produces the desired result
17:59:10bramm:so probably reasonable for interoperability is to support sha256 and sha3, also with specifying which hash function
18:00:02gmaxwell: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:07bramm: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:25bramm:Back on the subject of how the acceptance criteria has to be *exactly* the same
18:02:53bramm:Also the accepted lengths of the preimage string need to be the same
18:04:13gmaxwell:or tested, if there is an oppturnity for differences.
18:06:26tacotime:are there dangers to point compression?
18:08:27gmaxwell: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:51gmaxwell: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:33tacotime: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:55tacotime:i'm guessing it's also probably more expensive than even decompressing the compressed key.
18:13:16gmaxwell: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:45bramm:My approach to patent trolls is to tell them 'I fucked your mother and she sucked'
18:13:46gmaxwell:(oh sorry 2013)
18:14:12gmaxwell:In any case, it's a consideration.
18:14:28gmaxwell:tacotime: yes, and also requires some additional bits for the recover, and is also even easier to get wrong.
18:14:44bramm: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:52tacotime:gmaxwell: yeah, i figured the latter, heh.
18:15:53gmaxwell: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:53tacotime:i guess end of the day the savings aren't huge in terms of space either, it's just num_transactions * constant
18:16:52gmaxwell: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:10kanzure:i wrote up some thoughts about a unique method of patent reform, https://groups.google.com/d/msg/openmanufacturing/vS4ju1VqXb0/jD_TZ8U47b4J
18:19:07bramm:When do the certicom ecc patents run out?
18:20:15kanzure: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:34kanzure:*in the event of a reorg and other scenarios of course
18:20:42kanzure:(since there's no way to make something reorg-only. that's not what i'm suggesting.)
18:21:03gmaxwell: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:29gmaxwell:EC in general is pretty solid patent wise. See the beautiful IETF foundations of EC RFC...
18:23:12kanzure: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:24kanzure:there's probably something impossible about this that i am overlooking
18:23:49kanzure:*from those outputs to that one address(es)
18:24:14gmaxwell: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:29gmaxwell:and, of coure, if someone reuse an address ... poof gone.
18:24:54kanzure: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:02gmaxwell: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:06gmaxwell:er purpose.
18:25:20kanzure: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:33kanzure:right, i agree this would totes require a private channel of some kind
18:26:09gmaxwell: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:52kanzure: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:08kanzure:your transaction tree may have involved some dead guy what now. etc.
18:28:12gmaxwell: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:15kanzure:communicating private keys would be bad because that just means any alternative transaction can be signed, which isn't the point
18:29:43kanzure:so there might be some construct that would allow this behavior without being an actual private key
18:30:43kanzure:txin would probably have to be modified so that it's not just txid and vout.
18:35:07kanzure:anyway using this other construct would mean that massive reorgs would not be detrimental
18:35:14kanzure:and would not imply total system failure (if adopted)
18:38:29andytoshi:kanzure: what exactly would the key be restricted to? signing transactions whose output sets are the same as the original?
18:39:22kanzure:as long as txin is (txid, vout) that's not going to work
18:40:27kanzure:i don't know, have there been any proposals for more elaborate structs for txin?
18:40:29andytoshi: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:19kanzure: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:37andytoshi: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:54andytoshi:i think
18:42:05kanzure: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:31kanzure: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:42kanzure:i agree that in some alternative histories there may be transactions that disappear or appear that change your solvency or something
18:43:53kanzure:but if you only use this certain class of transactions, then you may be protected from that?
18:45:58andytoshi:would the ability to reference outputs by scriptpubkey cover it?
18:46:20andytoshi:there is some problem with that (other than the uniqueness requirement it puts on scriptpubkeys) that i never can remember..
18:49:08andytoshi: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:21kanzure: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:00andytoshi: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:27kanzure: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:28:31instagibbs:new arxiv paper from Cornell guy on mining as a prisoner's dilemma: http://arxiv.org/pdf/1411.7099v2.pdf
19:40:55Aquent2:Aquent2 is now known as Aquent
19:49:01gavinandresen: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:58gavinandresen:… 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:10instagibbs:let us hope
19:51:43gavinandresen:also: Loi Luu has a paper under submission on the same subject; see https://twitter.com/gavinandresen/status/537247892252413952
19:53:22bramm:I don't know how many of you are in the bay area, but the weather out there SUCKS
19:54:28tromp_:i'll swap your bay area weather for my long island weather
19:54:35instagibbs:gavinandresen: interesting. Ghash is <20% these days, if you believe the numbers. Wonder how widespread the share stealing is today.
19:55:30gavinandresen: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:07instagibbs:I'll swap too. East Coast has been disgusting all week
19:56:09lechuga_:there is no happy medium here
19:57:36bramm:gavinandresen, It is winter, and it's northern california, so it probably won't be sunny
19:58:37gavinandresen:bramm: summer is the foggy season in san francisco, winter was usually nice (i was in silicon valley from ’88 to ’96)
20:02:01zooko:Things are cold but dry and sunny, here in Colorado.
20:03:30bramm:tromp_, I claim California priviledge :-)
20:11:25bramm:Is it reasonable to call atomic transfers 'smart transactions'?
20:19:08bramm: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:00bramm:Much as that might piss off the ethereum people
20:36:04nsh-:i thought the bar for a smart transaction was the evaluation of at least one non-ledger input
20:36:24nsh-:or non-monetary input
20:38:55nsh-:nsh- is now known as bnsh
20:45:26bramm:bnsh, I don't know what that means
20:45:55bramm:And doesn't a hash pre-image count as a 'non-ledger input'?
20:46:16bnsh:* bnsh reads more context
20:46:22bnsh:bnsh is now known as nsh
20:47:24jgarzik:'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:38nsh: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:21nsh:(but i'm not trying to suggest my vague understanding is a good working definition or anything)
20:50:39bramm:nsh, atomic transfers involve the revealing of a hash preimage
20:50:45nsh:* nsh nods
20:53:04bramm:And truth be known, atomic transfers may be the overwhelming bulk of smart transactions people might actually want
20:56:00nsh:well, people have a hard time wanting things of which they can't conceive
20:56:07nsh:but even still, very useful
21:00:00bramm: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:22lechuga_:crappy impls get confused
21:01:37bramm:Define 'crappy' and 'confused'
21:01:38lechuga_:is my observation
21:01:56bramm:I mean, as long as it's clear which utxo is used...
21:02:15lechuga_:so i guess the gox exampel is a good one
21:02:42lechuga_:iirc they had an api endpoint which would show u 'stuck' txs
21:02:53bramm:I heard something about malleability in regards to gox, which might have been complete bullshit
21:03:01bramm:What is a 'stuck' transaction?
21:03:17lechuga_:not accepted by the network
21:03:23kanzure:mtgox could have easily been using txid as an id, but whether or not this caused mtgox's demise is another matter
21:03:28lechuga_:im really hazy as to what the root issue was
21:03:40lechuga_:in nay case someone observed what the issue was
21:03:40andytoshi:lechuga_: the gox story was bullshit, but i have a writeup from when we believed it was true..
21:03:53andytoshi:lechuga_: https://download.wpsoftware.net/bitcoin/malleability-faq.pdf
21:04:05lechuga_:and recreated tha txs such that they were now relayble but had different hashes
21:04:21lechuga_:and presumably peopel were already refunded for their 'stuck' txs
21:04:23kanzure: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:24lechuga_:and now got double-paid out
21:04:46lechuga_:andytoshi: nice thx
21:05:29kanzure:any accepted mutant transaction will invalidate any other transactions that relied on the previous txid
21:05:46lechuga_:right and that
21:05:47kanzure:(because transactions reference prior outputs by txid)
21:07:12bramm:kanzure, but doesn't that only apply if the history gets reworked?
21:07:27kanzure: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:33bramm:gox most likely fell for the 'oops we accidentally your whole balance' attack
21:07:49kanzure:transaction malleability applies during reorgs and even prior to inclusion in a block
21:08:15jgarzik:gox blamed malleability. that claim is suspect.
21:08:24bramm:Well you probably shouldn't do transactions based on older transactions which aren't very deep
21:08:27kanzure:also, arguably malleability is not a protocol bug.
21:08:34lechuga_:yeah pls dont take my retelling of that story to imply it is factual
21:08:56kanzure:bramm: even the transactions you do on your own are malleable by others (even if they are not the signer)
21:09:12lechuga_:but it's an interesting example even if fictitious
21:09:20bramm:Okay, I've put the malleability FAQ on my list of shit to read
21:09:27bramm:kanzure, I can see how that's a problem, true
21:09:27kanzure: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:52bramm:I'm out for the day - going without my computer until this evening, laters everybody
21:10:48kanzure:* kanzure checks that kanzure is not full of crap, https://download.wpsoftware.net/bitcoin/malleability-faq.pdf
21:11:15kanzure:"Therefore, malleating a transaction cannot reroute funds or invalidate
21:11:24kanzure:er, they can certainly invalidate future transactions
21:11:42kanzure:or i should say, dependent-future transactions...
21:13:53andytoshi: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:29andytoshi: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:39andytoshi:so correctness is not guaranteed :)
21:15:02andytoshi:but the specific claim "malleating a tx cannot invalidate it" is right, it can't invalidate the tx itself
21:15:27andytoshi:well, that's not quite true, with SIGHASH flags you can make a tx which can be broken after the fact..
21:15:37kanzure: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:14kanzure:txin could reference a prior signaturehash instead of a prior txid?
21:17:55kanzure:oh, order of outputs can change hmm.
21:19:53kanzure:each output should be referenced by transaction signaturehash + output amount. nobody cares about the exact order...
21:20:32kanzure:oh.. that still doesn't work.
22:12:14Dizzle__:Dizzle__ is now known as Dizzle
23:44:12c0rw|awa_:c0rw|awa_ is now known as c0rw1n
23:53:51nullbyte_:nullbyte_ is now known as Guest46653