01:07:20 | bosma_: | bosma_ is now known as bosma |
01:25:32 | sneak: | a |
01:30:35 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
02:22:54 | andytoshi: | gmaxwell: sipa: certainly, hopefully this week |
02:49:28 | Luke-Jr: | http://i.imgur.com/lO0n3eC.png lol ☺ |
02:57:53 | zooko: | Hee hee! |
03:13:47 | rusty: | gmaxwell: OK, so server sim seems to hit a steady state where it can only answer every second query after about 3000 queries (for 1 corrupt block in 100000), using an "xor 1,2,4,...2^n" psuedo-random function seeded by the query params. So it works. |
03:14:33 | rusty: | gmaxwell: my next question is what if it outright lies; unless replies are signed you can't prove it (though you can tell people and they can replicate the query, but I worry about gaming in that case) |
03:21:50 | lechuga_: | lol@Luke-jr |
03:36:51 | gmaxwell: | amiller: do you know if anyone has published on this simplified concept about hardening random transcript auding with locally decodable codes? It's the same fundimental thing that makes PCP theorem work, really, but it has some immediate applications to things like certificate transparency. (e.g. there have been people who wanted to do DNSSEC inside CT and were immedately blown off by the working group because CT is only really ... |
03:36:57 | gmaxwell: | ... viable because auditing everything is cheap) |
04:08:56 | amiller: | gmaxwell, i don't know of anything on it. when i looked into locally decodable codes i got hung up because they're not easy to verify that the encoding is done correctly |
04:09:01 | amiller: | that may or may not matter in this case |
06:27:32 | benten_: | benten_ has left #bitcoin-wizards |
06:28:46 | [Tristan]: | [Tristan] is now known as Guest45626 |
07:13:22 | lclc_bnc: | lclc_bnc is now known as lclc |
07:32:45 | gmaxwell: | somewhat amusing, I was asked to be on a panel at some local conference... it fit in my schedule so I agreed; ... looking at the schedule of events, all the "bitcoin" sessions are all altcoin people. :( http://www.futureofmoney.com/schedule |
07:35:54 | op_null: | your forehead is going to be sore after that one. |
07:36:28 | wallet421: | wallet421 is now known as wallet42 |
07:36:45 | op_null: | "Faster Payments" |
07:37:31 | gmaxwell: | I feel kinda dumb for agreeing now. Many of these conferences are basically 99% altcoin pumping; I asked who else they were asking to be on my panel and it was free of that, so I agreed... probably should have checked further first. Oh well. |
08:09:29 | gwillen: | gmaxwell: sounds actually vaguely interesting........ not $700 of interesting |
08:12:41 | fluffypony: | what is up with these conference attendee fees |
08:13:05 | phantomcircuit: | gmaxwell, that's funny |
08:13:05 | fluffypony: | I was going to go to Money 20/20 when we were in Vegas |
08:13:07 | fluffypony: | but the fees were insane |
08:13:13 | phantomcircuit: | i went to that in 2011 i think |
08:13:18 | phantomcircuit: | it was all |
08:13:22 | phantomcircuit: | MOBILE PAYMENTS!!! |
08:13:39 | phantomcircuit: | and charlie shrem hecking some guy from citi bank |
08:13:49 | fluffypony: | lol |
08:14:00 | phantomcircuit: | it was also not $700 |
08:14:08 | fluffypony: | yeah it was like $2000 |
08:14:16 | fluffypony: | well this Future of Money conference just looks like a shilling platform for Stellar |
08:14:18 | fluffypony: | so there's that |
08:14:18 | phantomcircuit: | lol no way i would have paid that |
08:14:22 | phantomcircuit: | it was like $110 or something |
08:14:55 | fluffypony: | http://money2020.com/register |
08:15:02 | fluffypony: | "The fee for general admission to Money20/20 is $2,950. We do not offer any exhibit hall-only or partial attendance rates." |
08:18:11 | phantomcircuit: | yeah it was $240 |
08:19:12 | phantomcircuit: | fluffypony, i remember seeing that and thinking |
08:19:15 | phantomcircuit: | "who the fuck pays that" |
08:19:20 | phantomcircuit: | but apparently it was packed |
08:19:24 | fluffypony: | lol |
08:19:30 | phantomcircuit: | soooo they must have given away a ton of free tickets |
08:20:24 | phantomcircuit: | gmaxwell, you think they would let me in free if you insisted that i was your assistant and was 1000% necessary |
09:01:12 | c0rw|sleep: | c0rw|sleep is now known as c0rw|away |
09:05:13 | asimov.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:13 | asimov.freenode.net: | Users on #bitcoin-wizards: andy-logbot damethos hashtag_ jtimon nsh PaulCapestany op_null SDCDev wallet42 gues warptangent tacotime tromp Guest45626 coiner fenn coinheavy woah d4de TheSeven Dr-G2 ryanxcharles K1773R rusty ahmed_ artifexd btc__ hguux_ dgenr8 LarsLarsen webdeli_ Shiftos hashtagg_ bitbumper nubbins` nuke1989 Baz___ iddo Transisto c0rw|away prodatalab nanotube dansmith_ kanzure Luke-Jr NikolaiToryzin Emcy_ bosma spinza shesek adlai roconnor_ go1111111 |
09:05:13 | asimov.freenode.net: | Users on #bitcoin-wizards: Flyer33 atgreen devrandom samson_ arowser1 SubCreative Starduster Anduck PRab maaku_ rfreeman_w null_radix grandmaster Meeh waxwing Nightwolf jgarzik mortale koshii hollandais berndj epscy zibbo mkarrer jaekwon_ Graftec Hunger- HaltingState luny Pan0ram1x jaekwon lclc s1w Eliel_ bobke LaptopZZ isis btcdrak sneak harrigan michagogo gavinandresen JonTitor ebfull phantomcircuit sl01 Cory Grishnakh sipa DoctorBTC Alanius jbenet HM kumavis mappum |
09:05:13 | asimov.freenode.net: | Users on #bitcoin-wizards: Muis azariah4 MRL-Relay fluffypony BlueMatt a5m0 kgk gazab AdrianG yoleaux gwillen livegnik BananaLotus Myagui @ChanServ burcin coutts wizkid057 Dyaheon bbrittain forrestv nickler mr_burdell Logicwax tromp_ Krellan poggy pi07r_ comboy mmozeiko lnovy Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away Fistful_of_Coins gmaxwell kinlo so [d__d] espes BigBitz otoburb wumpus EasyAt starsoccer jaromil helo |
09:05:13 | asimov.freenode.net: | Users on #bitcoin-wizards: Keefe Iriez huseby phedny midnightmagic coryfields andytoshi BrainOverfl0w warren asoltys gribble Graet smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow lechuga_ pigeons |
10:36:58 | Myagui: | Myagui has left #bitcoin-wizards |
14:11:45 | andytoshi: | usually speakers can bring a guest, surely he can write #bitcoin-wizards? |
14:43:29 | kanzure: | huh that's very interesting. i was emailing zisk for a few months, had no idea he was that focused on altcoins. |
15:00:25 | gmaxwell: | In any case, if there is anyone listed there that any of you want to dispatch me to talk to; feel free to request. |
15:05:42 | stonecoldpat: | the summit doesnt look that bad, at least there is a cocktail party afterwards (y) |
15:15:47 | Profreid_: | Profreid_ is now known as Profreid |
15:30:19 | gmaxwell: | ohh... someone on libpbc mailing list talking about implementing non-interactive forward security for openpgp. |
17:19:05 | pigeons: | i went to money2020 last year courtesy of a company quite similar to stellar and any talks about bitcoin typed things seemed to be atteded by lots of compliance officers complaining about all the "loopholes" and banks saying you coudnt scale it enough for their needs |
17:19:32 | pigeons: | not many interesting technical talks at all, more like a place to meet traditional financial service company contacts |
17:20:37 | pigeons: | everyone loves m-pesa though, cause there seems to be some good "control" over it |
17:28:47 | lclc: | lclc is now known as lclc_bnc |
19:39:14 | gmaxwell: | "They're hacking the ram on registers, in ten years drones are going to be shooting lasers to steal your identity." |
20:06:39 | Dizzle_: | Dizzle_ is now known as Dizzle |
20:34:15 | jgarzik: | ram on registers, that makes no sense |
20:35:12 | c0rw|away: | c0rw|away is now known as c0rw1n |
20:35:16 | jgarzik: | registers are more fundamental than ram |
20:35:22 | jgarzik: | but anyway, cute quote ;p |
20:42:30 | instagibbs: | jgarzik: registers at shops, not registers on CPUs :P |
20:43:07 | sipa: | ha |
20:50:54 | super3: | hello |
20:57:23 | starsoccer: | starsoccer is now known as Guest32679 |
20:57:49 | Guest32679: | Guest32679 is now known as starsoccer |
22:38:54 | bramm: | Hey everybody |
22:39:04 | bramm: | I have questions about this, if anybody can help me: https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 |
22:39:41 | bramm: | Hey web deli |
22:43:44 | andytoshi: | hi bramm, probably a few peoople can help you ... i adapted that post for the sidechains wp, iirc it was pretty hard to read (hence my writing out the protocol in full in the whitepaper) |
22:44:21 | bramm: | andytoshi, I have some really dumb questions about it |
22:45:00 | andytoshi: | bramm: i can help, i'm eating tho so will be slow |
22:45:14 | bramm: | Like, what does it mean to pay from a transaction? Isn't a transaction a thing that goes through or not? And won't the result of the transaction be money going from A to B or vice versa? |
22:47:58 | andytoshi: | ah, right, that was the kinda thing that made me go "huh?" i believe "TX1 pays from TX2" means one of TX1's inputs is one of TX2's outputs |
22:49:14 | bosma_: | bosma_ is now known as bosma |
22:51:03 | bramm: | So what you're calling O1 in the whitepaper is a special coin |
22:51:15 | andytoshi: | yeah |
22:51:30 | andytoshi: | (where "coin" means "unspent output", which is not really standard lingo outside of here and -dev) |
22:53:54 | bramm: | I'm not sure what you mean by that subtlety |
22:54:52 | bramm: | In any case, it appears to be that there are two things this needs beyond the spend ability of coins being based on sets keys to sign them. It needs to be able to use a pre-image as one of the 'signatures', and it needs to be able to use it being a certain time as one of the 'signatures'. |
22:54:58 | bramm: | How does this 'lock time' thing work? |
22:55:35 | andytoshi: | that's right ... bitcoin has a full script system to support both hash preimages and ECDSA keys (see https://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf for a high level overview and also what i mean by "unspent outputs") |
22:55:55 | andytoshi: | the locktime thing is weird in that it's outside of script ... |
22:56:21 | andytoshi: | ... it's a field on the transaction itself which declares how long the blockchain has to be before it can be included |
22:56:33 | andytoshi: | so you can create transactions that aren't valid yet, but definitely will be in the future |
22:57:01 | bramm: | So it's by generation number or block number or however people refer to that in bit coin? |
22:57:04 | andytoshi: | typically as "undo" transactions in case of a stalled protocol (where successful protocol completion spends one of the locked tx's inputs, invalidating it forever), or as deposits |
22:57:21 | sipa: | bramm: it's a block height or unix timestamp |
22:57:58 | sipa: | the reason (presumably) for not making it part of the scripting logic itself, is because transactions shouldn't become invalid once they are valid - that can lead to fungibility problems |
22:57:58 | bramm: | sipa, Thanks, 'block height' is the term I was looking for |
22:58:31 | sipa: | right, i guess that's bitcoin specific terminology; depth is how many blocks a transaction has on top, height is how far from the genesis block it is |
22:58:51 | bramm: | I don't know what you mean 'on top' |
22:59:12 | NewLiberty: | subsequent = on top |
22:59:23 | sipa: | genesis <------N blocks----> block with your transaction <----- M blocks----> the current active best chain tip |
22:59:31 | sipa: | N is the height, M is the depth |
22:59:36 | bramm: | Ah, I see |
22:59:55 | bramm: | This is mixing analogies in a horrible way |
23:00:00 | andytoshi: | :) |
23:00:03 | bramm: | But I'll use consistent terminology |
23:00:13 | NewLiberty: | It is easy to think about for a child playing with blocks, harder for programmers |
23:00:16 | sipa: | you have to see the blockchain as a stack, i guess, growing from low to high |
23:00:43 | bramm: | Oh, so 'depth' means 'how buried it is' |
23:00:47 | sipa: | bingo |
23:05:35 | cbeams: | andytoshi: your bitcoin-faq is a pleasure to read. thank you. |
23:07:09 | bramm: | Oh, so 'unspent outputs' basically means 'coins' |
23:07:28 | bramm: | andytoshi, Isn't it really a directed acyclic graph instead of a tree? |
23:09:11 | sipa: | bramm: sorry, what is a DAG instead of a tree (missing some context here)? |
23:09:41 | andytoshi: | bramm: yup, oops, did i say "tree" without even a footnote or something? |
23:09:49 | andytoshi: | "DAG" is too technical for that faq, but i should have mentioned it.. |
23:09:51 | bramm: | sipa, Oh sorry, from andytoshi's bit coin FAQ, he describes there being a tree of transactions |
23:10:22 | bramm: | andytoshi, Yeah there's no footnote about it being a DAG |
23:10:50 | bramm: | What happens when an output is partially spent? |
23:11:09 | midnightmagic: | bramm: it depends on how the transaction is formed. |
23:11:24 | midnightmagic: | bramm: If you have 5 btc input, and output 2.5 btc, the rest can be collected as fees by the miner |
23:11:42 | sipa: | bramm: there is no such thing as partial spending |
23:11:48 | sipa: | a coin is created once, and spent entirely once |
23:12:00 | bramm: | Ah, gotcha |
23:12:24 | sipa: | which is why bitcoin transaction have the concept of 'change'; a new output that goes back to an address of the spender |
23:12:33 | bramm: | So if you send something to a public key, you aren't sending to an account, you're making a new coin which just happens to use that public key |
23:12:40 | sipa: | for privacy reasons, it should be a fresh address, and made to look similar to the other outputs |
23:12:42 | midnightmagic: | sipa: you might call a partial spend an input which isn't satisfied by the output + fees collected by miners.. but I think what I did might be the only instance of that happening |
23:12:49 | roasbeef: | a transaction destroys input coins and creates new ones |
23:13:01 | andytoshi: | lol "chains (actually trees)" i'll add another parens "(actually directed acyclic graphs)" |
23:13:16 | sipa: | right: bitcoin transactions 'melt' coins and produce new ones from it, with potentially different amounts, and different owners |
23:13:33 | sipa: | only the amount created cannot exceed the amount destroyed |
23:13:43 | bramm: | How do people find out about their new coins? |
23:14:03 | sipa: | wallets that watch the blockchain/p2p net |
23:18:08 | bramm: | So do wallets ask for any new outputs for their own keys? |
23:18:56 | bramm: | Does that go for both directions, both spending and receiving? |
23:19:12 | midnightmagic: | bramm: the code itself only verifies(ied?) that the outputs are not > total input amounts. It is possible to destroy bitcoins if the spender's output amounts are less than input amounts *and* the miner doesn't pay himself the overage as fees in the coinbase. I did this, for example, in block 124724 by underpaying myself by (the fees of the transaction + 0.00000001) which means the fees and that one satoshi are destroyed |
23:19:15 | sipa: | every full node sees every transaction, so if the wallet is connected to a full node, there is no problem |
23:19:32 | sipa: | bramm: for lighter node, see BIP 37 |
23:19:39 | sipa: | it uses a bloom-filter based approach |
23:19:40 | AdrianG: | what are the odds of the bitcoin foundation (or some other corp) finally hiring full time test engineers to work on the bitcoin core? |
23:19:52 | sipa: | AdrianG: #bitcoin or #bitcoin-dev |
23:23:40 | bramm: | There's a fair amount of transactional overhead in support of (partial) anonymity |
23:25:00 | bramm: | An unfortunate disadvantage to payments going to keys rather than accounts is that if I post my account info I can't just re-key it later, I have to update my pub key information |
23:25:38 | sipa: | right, which is why many people believe that it shouldn't be called 'an address', but rather an 'invoice id' or something |
23:25:52 | sipa: | address implies persistence, which is bad for privacy |
23:26:20 | sipa: | schemes like BIP32 or the payment protocol or stealth transactions add some infrastructure to not reuse keys |
23:26:30 | sipa: | without complicating things for the user |
23:34:09 | lechuga_: | bramm: planning a project? :) |
23:34:22 | bramm: | lechuga_, Obviously I'm working on something, but I'm not saying what right now |
23:35:32 | lechuga_: | nod |
23:36:27 | lechuga_: | awesome that u are |
23:36:28 | bramm: | There are a number of features involving multiple keys which are nice to have which are also horrible for privacy |
23:37:00 | bramm: | I have a feeling if I came in here asking these dumb questions under an assumed name people would be being a lot less patient with me |
23:37:17 | lechuga_: | not an entirely incorrect instinct |
23:37:31 | lechuga_: | creator of bittorrent gets a pass |
23:37:47 | sipa: | bramm: you may be right :) |
23:39:16 | bramm: | It's nice that there's this channel for this sort of discussion though. I found it by accident when someone on twitter mentioned it tangentially in response to something I said |
23:39:21 | andytoshi: | bramm: please don't try it ;) |
23:41:00 | sipa: | tbh, much of the previous discussion belongs in #bitcoin or #bitcoin-dev |
23:41:23 | andytoshi: | fwiw while some of your questions would probably be redirected to #bitcoin, the fact that you react to explanations and update your understanding makes patience worthwhile |
23:42:02 | andytoshi: | if you were just arguing, i expectt no amount celebrity status would help you |
23:43:11 | bramm: | Can lock times have a maximum in addition to a minimum? |
23:43:49 | sipa: | no, only a minimum |
23:43:52 | sipa: | 23:57:58 < sipa> the reason (presumably) for not making it part of the scripting logic itself, is because transactions shouldn't become invalid once they are valid - that can lead to fungibility problems |
23:44:06 | andytoshi: | bramm: no, this would be dangerous because if a reorg happened which bumped a transaction out of a block, that tx could become forever invalidated |
23:44:28 | bramm: | andytoshi, I appreciate that people are being patient with me. And yeah, I could take some of these questions to #bitcoin, or preface everything with 'how about X?' rather than asking questions first, but since people aren't getting mad at me I'm keeping discussion all in the same channel and going in and out of new proposals, trying to not say anything completely asinine by asking questions first |
23:44:29 | andytoshi: | right now transactions can't be forever invalidated, even in a reorg, except by deliberate action by its spender |
23:45:00 | bramm: | What is this transaction 'validation' thing? |
23:45:00 | andytoshi: | bramm: it's cool, i think we'd all like to be more patient but it gets abused easily by people who just want to argue or grind axes |
23:45:50 | andytoshi: | bramm: presumably you don't want to wreck your reputation, hence more patience than somebody with no reputation whatsoever |
23:45:54 | gavinandresen: | … if you’re thinking of using a DHT to implement a proof of stake system then you’ll see how quick we get annoyed…. |
23:46:04 | sipa: | using rainbow tables |
23:46:34 | lechuga_: | lol |
23:46:45 | andytoshi: | bramm: a transaction is either valid or not ... it is valid if it is well-formed, the signatures validate, etc, and also if all of its inputs are unspent outputs |
23:47:11 | sipa: | < gmaxwell> Someday I'm going to get myself invited to some conference with the president, and while he's talking about some middle east conflict thing— I'm going to ask if they've considered using a DHT. |
23:47:19 | andytoshi: | bramm: so you can invalidate a transaction by spending one of its inputs ... but you have to do this deliberately by creating a conflicting tx and exploiting a reorg to get it into the blockchain |
23:47:38 | bramm: | gavinandresen, If any of you would like to ask me questions about DHTs I'd be happy to answer. The sort of thing you just made a joke about makes no sense to me, which is probably the point. |
23:48:05 | sipa: | bramm: you have no idea how many people have suggested that bitcoin should use DHTs :) |
23:48:26 | andytoshi: | bramm: the joke is, there was a long period when people would come here saying "why not replace the blockchain with a DHT?" without any concept of what a blockchain does or what a DHT does |
23:48:53 | bramm: | DHTs actually work a lot better than I expected. We've got the BitTorrent one working very robustly *for peer finding* |
23:49:11 | sipa: | right, there would be no problem using it for peer finding in bitcoin either |
23:49:25 | bramm: | andytoshi, Yeah that isn't even a properly formed question. 'Why not replace an apple with a quaternion?' |
23:49:39 | sipa: | or even for doing fetching of historic blocks |
23:49:49 | sipa: | but for anything that has DoS risk or consensus risk... |
23:50:34 | bramm: | fetching historic blocks wouldn't be a good use of DHTs either |
23:51:16 | phantomcircuit: | sipa, bestest quote ever |
23:51:50 | phantomcircuit: | sipa, it's relatively easy to censor a dht |
23:52:00 | sipa: | bramm: right, sure |
23:52:02 | bramm: | phantomcircuit, It's a lot harder than you think |
23:52:17 | bramm: | phantomcircuit, Although a lot of it has to do with what you mean by 'censor' |
23:52:18 | sipa: | it's just that initial sync isn't very vulnerable |
23:52:24 | phantomcircuit: | bramm, it's relatively easy to censor a dht if you've got a giant botnet |
23:52:49 | sipa: | at worst, it goes slow or not at all - but that won't split the network or cause any loss of money |
23:53:02 | phantomcircuit: | afaict the only reason the bittorrent dht survives is because nobody with the ability to launch a massive sybil attack wants to |
23:53:07 | bramm: | phantomcircuit, If your botnet has many more IP addresses than the DHT you can pull it off, but for the BitTorrent DHT that's a really huge botnet |
23:53:17 | sipa: | how many nodes does it have? |
23:53:26 | bramm: | I think somewhere around 30 million |
23:53:29 | sipa: | wow |
23:54:22 | bramm: | phantomcircuit, There are similar attacks on bit coin with occupying peer slots, there are countermeasures for those as well but for the most part it seems that nobody wants to do the attacks |
23:55:11 | phantomcircuit: | bramm, iirc you can abuse connection timeout issues to rapidly cycle node ids |
23:55:26 | phantomcircuit: | you probably know more about it than me though :P |
23:55:32 | bramm: | phantomcircuit, We tied them to IP address in the BitTorrent DHT |
23:55:41 | phantomcircuit: | ah ok then |
23:55:58 | phantomcircuit: | yeah rapidly cycling node ids was an issue in gnutella |
23:56:20 | bramm: | There were attacks going on before that, but they mostly seemed to be collecting info and weren't super sophisticated |
23:58:50 | bramm: | I think a very sophisticated attacker could really mess things up with a botnet of around 100,000 IPs. That would be a very sophisticated attack though, and that isn't a terribly small botnet either. |
23:59:13 | sipa: | we have had bitcoin mining botnets of that size... |
23:59:18 | phantomcircuit: | bramm, if you just need unique ips 100k is tiny |
23:59:20 | sipa: | (a loong time ago) |
23:59:22 | midnightmagic: | DHT has been endlessly suggested as a replacement for the *seeding* mechanism, which used to be IRC /whois discovery, now DNS seeders. Or they would suggest using a DHT for block storage. Or suggest a DHT for virtually every other aspect of the p2p protocol. Mostly for peer discovery because they erroneously presume properties about a DHT which aren't valid in bitcoin. |
23:59:28 | phantomcircuit: | last year someone broke into ~3m routers |
23:59:37 | phantomcircuit: | and proceeded to basically scan the entire internet using them |