00:16:44Luke-Jr:nsh: ?
00:16:57nsh:nm
00:18:29propumpkin:propumpkin is now known as copumpkin
03:25:47justanotheruser:justanotheruser is now known as just[dead]
03:43:43just[dead]:just[dead] is now known as justanotheruser
04:13:50amiller:maaku, do you have any thoughts about the compact spv proof stuff i wrote
04:14:46amiller:i have been thinking about what i need to fix with it, i have a few problems with my definition, one of them i pointed out in the forum thread, another is probably implied but technically needs to be fixed
04:16:06amiller:i'm a little stuck, too, i don't really know how to make it so that an attacker can't make honest guys have to deal with pretty big proofs.
04:17:18amiller:anyway i guess i'm especially wondering if this makes it any easier to clarify what your approach (which as i understand it is based on having miners select arbitrarily which back links to include) gets
04:21:01roidster:roidster is now known as Guest41191
05:29:30maaku:amiller: you need a >51% attack in order to come up with an actual chain with long proofs
05:29:53amiller:no, honest nodes will still build on the long proofs
05:29:55justanotheruser:maaku: not true
05:30:15amiller:i mean, the attacker has to throw out half of his work
05:30:28justanotheruser:You can fork the blockchain successfully with 10% of the hashrate
05:30:30amiller:so at most you could have like 25% long
05:30:53maaku:justanotheruser: not sure what you're talking about
05:30:59amiller:justanotheruser, i dont know what you're talking about, and anyway i think it's off topic becausei 'm asking about vey specific thin
05:31:45maaku:amiller: so the attacker is throwing out half of his work and still having a longer chain. so really it's a 67% attack
05:31:53amiller:it's not about haing a longer chain
05:32:09amiller:it's about adding value=1 proofs that aren't easily "skippable" to the honest chain
05:32:30maaku:well i qualified with "actual chain"
05:32:31justanotheruser:maaku: you can revert 6 blocks with 10% of the network with P=0.0002428
05:32:40amiller:basically there's no way an attacker can do that.
05:32:41maaku:justanotheruser: way off topic
05:32:43amiller:okay so yeah you're right
05:32:59justanotheruser:maaku: probably should read the scrollback then :p
05:33:03amiller:okay, so, now i no longer thing there's so much of a concern
05:33:24maaku:and yeah, the getting-fed-infinite-1-diff-blocks attack is still a problem, but such is the case with bitcoin currently
05:33:35maaku:(the solution for now is checkpoints, which is ugly, but works)
05:35:30maaku:amiller: well there certainly is a way an attacker can do that - with a 67% attack - but this is an spv proof
05:35:59maaku:falling apart when an attacker is >51% is perfectly fine
05:36:10amiller:maaku, right
05:36:32amiller:so, my scheme's great as is.
05:37:33maaku:maybe. i think the fact that you can build off any random high-pow block and insert your own back-links could be a problem
05:37:47maaku:but i haven't had a chance to sit down with pencil and paper and work out an exploit
05:38:36maaku:it may be application-specific too (I'm thinking about this in terms of pegging, whereas I think you are concerned with SPV/headers-first synchronization)
05:39:30maaku:also, implicitly, you are thinking about interactive protocols whereas pegging is necessarily non-interactive (bitcoin nodes have no clue what is going on in the side chain except what they are told through spv proofs)
06:07:11justanotheruser:justanotheruser is now known as just[dead]
06:08:36just[dead]:just[dead] is now known as justanotheruser
11:30:41nsh_:nsh_ is now known as nsh
13:39:10justanotheruser:justanotheruser is now known as just[dead]
14:13:06imperiusIII:imperiusIII is now known as imperiusIII_lawl
15:40:29jgarzik:FYI petertodd, https://github.com/jgarzik/bitcoin/tree/bare-multisig
16:32:50zooko`:zooko` is now known as zooko
17:08:32petertodd:jgarzik: I think you should apologise in that thread for suggesting that I was trying to damage counterparty to aid mastercoin
17:08:56petertodd:jgarzik: second, it should be my name on that patch when it goes to pull-req to be clear who suggested it (given the context)
17:11:37tacotime:Is it dangerous to remove sequence numbers from bitcoin txs when hardforking? Or limiting in any way?
17:11:55tacotime:I'm not sure if they're planned to have useful applications in the near future.
17:15:57phantomcircuit:tacotime, a word of advice, if you dont understand it, dont touch it
17:16:05petertodd:phantomcircuit: +1
17:16:36imperiusIII_lawl:if i use that advice id never get laid :P
17:16:45zooko:* zooko laughs
17:16:47tacotime:Okay. They just were taking up space, but I guess it's not that much (4 bytes).
17:16:49tacotime:haha
17:16:49petertodd:imperiusIII_lawl: we can make an exception for that
17:17:19petertodd:tacotime: have you read my nodes on how codeseparator should have worked? it's related to nSequence actually
17:17:23petertodd:*notes
17:17:38tacotime:No, but I'd like to as I'm working on scripting for my fork right now.
17:17:52maaku:well, nSequence isn't incentive safe
17:17:59maaku:i'm considering removing it in my hard-fork
17:18:26petertodd:tacotime: it's on bitcointalk, search for CODESEPARATOR, tl;dr: is satoshi's original scriptSig+scriptPubKey concatenation desgin was on the right path, but flawed
17:18:29petertodd:maaku: ?
17:18:41tacotime:petertodd, can do, thanks
17:19:35maaku:petertodd: if i'm a miner, why should I respect high-sequence transactions?
17:19:48petertodd:maaku: oh, that, yeah, that's all zeroconf bullshit
17:20:19petertodd:maaku: I've tried very hard to forget about that design mistake :P
17:30:11amiller:so maaku to respond to the two things you said about the compact spv proofs.... about interactive vs noninteractive, 1) any random interactive prover/verifier protocol is made interactive by using hashes, as long as the verifier doesn't have "private" random choices - no where is private state needed for verifier, 2) there is not even any randomization in the verifier routine, so it is absolutely explicitly noninteractive
17:31:46amiller:b) yeah application specific maybe. the application i always had in mind was letting miners choose whatever difficulty target they want. i think that's closer to the 1:1 pegging app than the headers first synchronization
17:32:45amiller:if i mentioned headers first synchronization it was just because at the time i didn't think anyone had the patience to hear about weirder applications, but now it's a little better.
17:34:27imperiusIII_lawl:is it possible to use bitcoin to play a game of chess between two pseudonymous players?
17:35:13tromp__:you can play an even better game, https://github.com/zack-bitcoin/CryptGo
17:35:13petertodd:imperiusIII_lawl: yes, it is also possible to use tor - what specifically do you want bitcoin for?
17:35:14amiller:imperiusIII_lawl, i love that example, i've been thinking about that for years now.
17:35:16amiller:i don't think so
17:35:35amiller:at least not with the kind of security you'd want, like that neither player can walk away from the table
17:35:42tacotime:Are timelock tx actually kind of dangerous? For instance, if I were to make a timelocked transaction with 1000 BTC in fees for 400,000 blocks from now, and in the future that's billions of dollars, wouldn't all miners in the network be incentivized to try to mine the block at that height themselves?
17:36:25petertodd:tacotime: they sure would be, but that's an issue with tx fees in gernal
17:36:48amiller:petertodd, imperiusIII_lawl, obviously the best goal is to play a game of chess where the winner gets a prize, and there is no way to force the game not to end (say each player has a 1 day time limit)
17:37:16imperiusIII_lawl:do you think you can create a game of chess on the blockchain, such that, if someone resigns or doesnt make a move, or loses, they lose bitcoin
17:37:23imperiusIII_lawl:and if they win they gain bitcoins
17:37:24maaku:tacotime: if that actually happened I'm sure you'd have double-spent the coins by then
17:37:34petertodd:imperiusIII_lawl: sounds possible to me
17:37:42amiller:petertodd, imperiusIII_lawl, how?
17:38:24maaku:amiller: I guess I was reading your posts wrong. I thought your system requires some sort of interactive verification for probabalistic assurance that the proof is valid
17:38:37imperiusIII_lawl:yeh... how :P
17:38:38petertodd:amiller: have a script evaluate the moves of the game, along with a timelock provision (obviously tricky to do with the existing scripting, to say the least)
17:38:57amiller:is there a simplest op code you could add to make it possible?
17:39:08amiller:i think you would need a completely different system where you acn refer to a tx's txouts in the verification script
17:39:14imperiusIII_lawl:if we can use the blockchain to do chess tournaments, that could be revolutionary
17:39:14petertodd:amiller: maybe even you can use a multisig-based protocol via that nash-equilibrium thing people were using for exchanges
17:39:16amiller:if you think there's a simpler way please let me know i'd be really interested in this
17:39:29amiller:uh that nash equilibrium thing is nonsense and that is introducing a trusted party
17:39:31maaku:whereas I know with the system we described you don't know connectivity but at least you are certain faking it would require more work than actually doing it
17:39:51maaku:I'm not sure if that property holds true of the original hash-value highway
17:39:56petertodd:amiller: OP_X86 :P but seriously, being able to get data left in the txout of a previous tx would work - you'd basically have a txout per move
17:40:16amiller:maaku, okay well no where in my scheme (i provided psuedocode and actual code) does the verifier need to make a random choice
17:41:09jgarzik:petertodd, that's fair. I updated my branch.
17:41:10amiller:maaku, my security statement says that faking it can't get you more than negligibly more work than actually doing it, imo it's easier to attack the definition than the scheme
17:42:33maaku:amiller: I need to understand that better. I *think* you can fake a very high-work proof with minimal effort, if the high-value pow doesn't cover its commitments
17:42:47petertodd:jgarzik: not quite - I suggested it because of the sigops issue, and re: data storage that is only due to UTXO bloat - I think data storage in the chain otherwise is a good thing to enable
17:45:06petertodd:jgarzik: oh, and you made it a miner flag, which doesn't even address my concerns there
17:49:04jgarzik:petertodd, would you like me to take your name off of it, then?
17:49:24petertodd:jgarzik: yes, sorry for the trouble
17:51:45petertodd:jgarzik: if it were a "get rid of checkmultisig thing" to fix sigops, I'd want to be upfront that I suggested that knowing full well it'd cause problems for projects using it, but equally, your patch comes from a motivation that I don't agree with, and more importantly fails to address the actual DoS attack I am worried about
18:23:09Ademan:is PoS algorithm discussion on topic here?
18:25:08petertodd:Ademan: yes
18:25:16tacotime:I talk about it a lot and no one yells at me. :P
18:25:27tacotime:brb
18:26:40sipa:agree, on topic
18:26:49sipa:(still, broken imho)
18:27:25Ademan:someone mentioned "slasher" which I recalled thinking was broken, but I didn't recall why, so I'm rereading and probably will end up with questions
18:28:07sipa:i know of no pure-PoS scheme which doesn't suffer from the nothing-at-stake problem
18:28:57petertodd:sipa: I do, but it suffers from the "invokes a magical jam-free network" problem :P
18:29:03sipa:right
18:29:26jgarzik:heh
18:29:45petertodd:Ademan: speaking of, i highly recommend figuring out what I mean by that before thinking you understand PoS algorithms
18:29:49Ademan:petertodd: how so? just assuming that nodes will always receive the "correct" block before any "duplicate stakes" ?
18:30:40Ademan:or rather than saying "correct" just assuming that if I'm minting, everyone receives the same minted block first?
18:31:05petertodd:Ademan: I gotta go and get some work done, but it's more subtle than that. also, read proof-of-publication: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html before you think you understand PoW
18:31:17jgarzik:petertodd, https://bitcointalk.org/index.php?topic=395761.msg5822898#msg5822898
18:32:13petertodd:jgarzik: thanks, that's absolutely fine (don't think I meant to say you were guilty of serious wrongdoing or anything)
18:33:10petertodd:Ademan: and ask yourself, if you can assume things about who receives what blocks in what order, do you actually need PoW or PoS?
18:33:13petertodd:later
18:41:18Ademan:heh, "proof of publication" refers to mastercoin as parasitic. That's accurate, but I'm not sure if it's intentionally negative heh.
19:01:18rdponticelli:rdponticelli has left #bitcoin-wizards
19:16:38just[dead]:just[dead] is now known as justanotheruser
21:44:57wallet421:wallet421 is now known as wallet42
22:07:12jgarzik:Past 2 years worth of blocks, as sorted by script type discovered in each transaction output
22:07:15jgarzik:unknown 1645
22:07:15jgarzik:pubkey 468069
22:07:15jgarzik:pubkeyhash 78402307
22:07:15jgarzik:multisig 29422
22:07:15jgarzik:scripthash 20561
22:07:16jgarzik:---
22:07:18jgarzik:105121 blocks scanned
22:18:50phantomcircuit:jgarzik, that's more outside of pubkeyhash than i expected
22:19:00jgarzik:a lot more pubkey than I expected
22:19:56phantomcircuit:jgarzik, i would assume those are all very early
22:20:28jgarzik:phantomcircuit, "past 2 years"
22:20:37phantomcircuit:oh right
22:20:39phantomcircuit:huh that is weird
22:21:33jgarzik:well, most recent ~730 days (2 years) worth of blocks to be more specific.
22:21:42jgarzik:didn't bother with dates, just last N blocks
22:22:15Ademan:is pubkeyhash more or less secure? I could see it argued that the hash further obscures the private key, preventing discovery, but on the other hand hashing adds collisions
22:23:48jgarzik:Ademan, you must reveal the pubkey to redeem
22:24:18Ademan:ah right... oops
22:25:24Ademan:but on the other hand you don't reveal the pubkey until you spend, after which point it can't be double spent (assuming any hypothetical pubkey->private technique takes time... which seems safe...)
22:26:33K1773R:Ademan: thats not correct, if someone reveals his pubkey, you "could" double spend it aslongs the original tx hasnt been confirmed (1 confirmation)
22:26:44K1773R:s/aslongs/aslong/
22:26:56Ademan:K1773R: right, which is why I said "assuming the pubkey->private technique takes time"
22:27:19K1773R:sry, i missed that part. answered too quickly
22:27:37Ademan:np, I didn't word it particularly well either
22:27:44Ademan:that couldn't have helped haha
22:28:15tacotime:I think the complexity of cracking an ecdsa pubkey is 2^128 bruteforce operations, and the search space of RIPEMD is 2^160. But you need to do the ECDSA bruteforce anyway and then hash on top if you're looking to break it from the hash standpoint.
22:28:31tacotime:So they should be pretty similar in security.
22:29:00tacotime:(If my numbers are off, correct me, this is off the top of my head)
22:29:26tacotime:Well, RIPEMD-160 of course
22:29:31enodios:enodios has left #bitcoin-wizards
22:32:58tacotime:I think RIPEMD-160 has collision resistance problems though, so you might expose yourself that way.
22:34:47tacotime:http://link.springer.com/chapter/10.1007%2F11836810_8 "...we present an analytical attack on a round-reduced variant of the RIPEMD-160 hash function.""
22:39:18tacotime:But we're not using round reduced, so, *shrug*
22:41:45phantomcircuit:tacotime, the ecdsa variant we use is 256 bits
22:42:07phantomcircuit:pubkeyhash is certainly more practically secure
22:42:32phantomcircuit:even a fairly serious break wouldn't be enough to generate a false signature in the time between broadcast and inclusion in a block
22:43:19Luke-Jr:tacotime: cracking an ECDSA private key need not be bruteforced, though
22:44:47Luke-Jr:so wtf, is Counterparty just a Freimarkets wannabe?
22:44:58tacotime:Luke-Jr, right, there were some attacks iirc
22:45:32tacotime:Uhh it was a proof of burn thing where you got counterparty coins for destroying your bitcoins
22:45:43tacotime:and then the rest is kind of ??? to me
22:46:29tacotime:Apparently whatever implementation they originally had was broken too and 60 BTC of counterparty coins were stolen from an exchange
22:47:16Luke-Jr:lol
22:47:31midnightmagic:whoah
22:47:50Luke-Jr:"You also have people who understand this level of computer science, but still keep their wallet.dat file in plain text on a Windows box, ready for reaping by malware or DDoS."
22:47:52Luke-Jr:lol
22:48:21tacotime:https://bitcointalk.org/index.php?topic=395761.msg5291437#msg5291437
22:48:39tacotime:haha
23:01:02Ademan:tacotime: haha WOW
23:15:21jgarzik:A little bit more granularity...
23:15:26jgarzik:---
23:15:26jgarzik:multisig 29422
23:15:26jgarzik:op_drop 19
23:15:26jgarzik:op_return 798
23:15:28jgarzik:pubkey 468069
23:15:30jgarzik:pubkeyhash 78402307
23:15:32jgarzik:scripthash 20561
23:15:34jgarzik:unknown 828
23:15:36jgarzik:---
23:15:38jgarzik:1-of-1 901
23:15:40jgarzik:1-of-2 11541
23:15:42jgarzik:1-of-3 16923
23:15:44jgarzik:16-of-16 1
23:15:46jgarzik:2-of-16 1
23:15:48jgarzik:2-of-2 23
23:15:50jgarzik:2-of-3 30
23:15:52jgarzik:3-of-3 2
23:15:54jgarzik:---
23:15:58jgarzik:105121 blocks scanned
23:16:24justanotheruser:jgarzik: can you ge thte sum of op_return? I'm interested in how many coins have been destroyed
23:16:45Ademan:justanotheruser: I assume most op_return coins would be 0 value... wouldn't they?
23:17:02jgarzik:That's my presumption, but it is theoretically possible to be non-zero
23:19:42Ademan:jgarzik: how are you developing these stats? This seems like it'd be a pain via jsonrpc (can you even query transactions that aren't yours?)
23:21:12jgarzik:Ademan, linear scan of raw binary blocks, last 2 years worth
23:21:12justanotheruser:Ademan: well if I want to do a proof of burn they wouldn't
23:21:19maaku:i've seen a lot of ignorance on OP_RETURN. I would not be surprised to find many destroyed coins
23:31:08Ademan:probably a dumb question, but can a block contain any set of valid transactions, or do all referenced coins need to be already confirmed? (say I have two transactions A and B, B spends A's output, A is valid but unconfirmed, can A and B be mined in the same block?)
23:36:18maaku:Ademan: yes, so long as B comes after A
23:36:47maaku:by the time B is encountered during validation, A is already processed and treated as confirmed
23:36:57maaku:Ademan: also, #bitcoin-dev
23:37:28midnightmagic:maaku: oh, can't B enter the orphan tx pool to wait for validation via A?
23:38:13sipa:midnightmagic: #bitcoin-dev
23:38:22sipa:jgarzik: #bitcoin-dev