|* maaku runs
|dexX7_ is now known as dexX7
|* sipa run
|posita has left #bitcoin-wizards
|posita has left #bitcoin-wizards
|Pan0ram1x is now known as Guest21473
| [05:18:11] phantomcircuit: you're in the bay area?
|petertodd: Shared Coin has been doing the bad mixes as far back as Nov 2013 e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b
|dsnrk: I was thinking about it this morning, and it may be the system never worked, it's just that it looked like it worked if your specific satoshi-precision vout value happened to match one they already had unspent
|dsnrk: I only did testing by hand, so I wouldn't be surprised if the "random" numbers I picked weren't actually all that random...
|petertodd: may also be that they prepopulated their txout sent and it decayed over time.
|gmaxwell: maybe, although they get a lot of users so I'd be surprised if running out was an issue
|dsnrk: of course, I was first testing shared coin before it was even publicly released - that's pre november
|gmaxwell: they do delay by a block it seems.
|petertodd: they show an example transaction in October and it was broken as well.
|( 72316782bf48d0cd232b888a7b9ea03f88ba79fac28273cd2aa1804683235412 )
|dsnrk: yeah, probably just bad luck on my part, and not very thorough testing
|dsnrk: at least the people doing round numbers sends were being protected - I wonder what % of people that ends up being?
|I don't for a second blame you in that.
|by spends identified by reddit users were fairly round 0.015 BTC each
|well there is the fact that their own funds are identifyable-ish, but at least that was known
|dsnrk: yeah, doesn't take many bits of uniqueness to break the algorithm :(
|gmaxwell: an early bug was that their funds were compressed keys and customer funds uncompressed :(
|their server seems to keep logs of all the private keys used for their spends, there's a function for dumping all the private keys to disk as they are being used. it's likely they have enough logs at this point to expose eveyr send made by the service, even if users couldn't do it as trivially.
|These things at least we knew.
|dsnrk: that's why I've always told people having the source code for the service isn't as useful as you'd think
|gmaxwell: it's implied in their pitch that they don't keep logs "no requirement to keep any logs"
|dsnrk: so what happens if you send funds to an older address?
|petertodd: I'm half tempted to write a crawler to try and expose all of the coinjoin transactions made by them. I decided that's information I don't want to know though. you can identify them as being from bc.i by using the IP addresses they publish.
|dsnrk: well, identifying the transactions isn't very hard even without ip addr info...
|petertodd: one of theirs or a temporary user ones in the CJ?
|dsnrk: oen of their addresses - if they're keeping private keys they'll probably spend the funds
|petertodd: what fingerprint? currently I've got the number of outputs and inputs and the sizes involved, that there's a chain of minimum 1 block apart, and that only a small portion of the outputs carry from TX > TX. are there any other tells?
|oh and all the public keys are uncompressed.
|dsnrk: that's incorrect, some of the keys are compressed
|dsnrk: anyway, there aren't that many people doing transactions like that - just linking them all together is probably pretty close
|but anyway, identifying bc.i cj transactions in general isn't too much of a privacy issue - identifying input and output links is the issue
|petertodd: that's interesting. some of the ones in the early SC are uncompressed, the ones in my later example are all uncompressed.
|dsnrk: oh, maybe they finally fixed that bug fully?
|I didn't notice that change in the repo, but I could have overlooked it
|but yes, coinjoins aren't meant to be secret. the only reason it's an issue here is that you can easily deanonymise them once you find them.
|heck you can do them in real time.
|yeah. also having all those extra inputs and outputs adds little to nothing to the privacy, and just makes it harder to notice it's broken
|come to think of it, it'll also reduce privacy by increasing the velocity of their funds, making them more distinguishable from customer funds
|justanotheruser is now known as bystander
|bystander is now known as justanotheruser
|petertodd: I hasn't thought of that. the coin-age of their mixes is actually ridiculously slow. for mine it took minutes for them to be spent again. that's probably the best fingerprint of all if you were going to automate it.
|Pan0ram1x_ is now known as Pan0ram1x
|execut3 is now known as shesek
|nshsome is now known as [nsh]
|posita1 has left #bitcoin-wizards
|gmaxwell: so how much do you think can realistically be accomplished with snarks that only support hand-crafted circuits? any idea how complicated a circuit to do the core of the EC signature verify is? i mean using your scheme that moves the bulk of it out of the snark
|hearn: my scheme results in only needing a point add inside the snark for the verify ... so a lot smaller than a full verify. though I haven't thought through what the most efficient construction would be for a point add over a differently sized larg arithmetic circuit.
|Probably the easiest semi-useful thing to implement is a hash tree membership query. "This UXTO is a member of blockchain X"
|yeah, that's what i thought. the released code is _very_ basic. you get templates for: AND, OR, NAND, summing (not a gate), toggles, bit-packing and unpacking, demuxing, one or two other things. and that's about it.
|i guess a circuit for SHA256 is the first step
|[BNC]dansmith is now known as dansmith_btc
|phantomcircuit: I thought you were in the UK for some reason. you going to any of the meetups?
|maaku is now known as Guest84338
|mr_burde_ is now known as mr_burdell
|Guest84338 is now known as maaku
| [16:54:12] phantomcircuit: I thought you were in the UK for some reason. you going to any of the meetups?
|i havent' been in the uk for a while now
|ah well i hope we have a chance to run into each other
|i'm in san jose and don't often go to the meetups, but if there were wizards there i might
|maaku, where abouts in san jose?
|maaku, that's mountain view not san jose :P
|i'm willow glen, but yes the meetup is mountain view i think
|there's also one in SF, but I never make it that far
|sunnyvale, but it's on tuesdays when I usually have other things to do.
|it moved from hacker dojo?
|sipa when are more header-first patches expected?
|we need this technology for miniblockchain project
|some info here http://bitfreak.info/mbc-wiki/index.php?title=Main_Page
|it's similar to ultimate blockchain compression
|Pretty troubling that the page there appears to make no mention of security assumptions.
|some page has a list of attacks
|jonpry: that white paper seems to be very confused.
|yeah i know
|it's also out of date. the real implementation looks not to much like it
|users always have the option of not pruning the chain and not running from a pruned chain so there are no security implications in that case
|also if you only prune behind checkpoints there are no practical attacks
|jonpry: a "checkpoint" in that sense seems to represent a point of trust in the consensus system.. but in bitcoin a "checkpoint" has nothing to do with trust or consensus
|i'm updating my alts.pdf to merge in the PoS stuff and elaborate on distributed consensus issues. it'll be done in under an hour, i encourage you to read it
|oh, i don't mean actually done, i just mean the distributed consensus section will be done
|i mean checkpoint in bitcoin sense. it's simply a point which a user chooses to not accept forks behind
|it doesn't matter is users choose the same point or if it is a correct point. it's just their choice
|jonpry: sipa and I are hoping to remove those as part of the headers first change.
|They cause severe misunderstandings about the security model, and headers first largely removes the actual use of them.
|They're only not a massive violation of the security model when— like now— they largely do nothing.
|If you're talking about nodes that never retrive the history at all, thats a pretty substantial difference. (since it means that a short term burst of hashpower could basically violate any rule of the system)
|they have real implications for pruning system. once somebody chooses a fixed point in the chain it becomes possible to remove all tx data prior to that point without problem
|Thats a misunderstanding of pruning.
|We have pruning almost completely implement in bitcoin core and there is absolutely no impact on the security model, and no need for checkpoints.
|jonpry: what attack do you believe checkpoints prevent?
|jonpry: As I said, you misunderstand it.
|pretty sure i don't
|the fundamental problem is that you have to download the UTXO set at some point in time
|jonpry: no, you download the blockchain— you do not, however, have to store it.
|Since you produced the utxo set yourself there is no change in the security model.
|we do not download block chain
|then how do you verify it?
|the set is hashed into the block headers
|and we have elaborate system to provide proofs of partial UTXO sets
|Doing that is a non-trivial reduction in the security model.
|it's all the same if you only prune behind checkpoints
|(not that it doesn't have uses, I mean— I proposed this back in 2011)
|it's completely not
|This is part of why we're going to remove them in bitcoin core, since they seem to inspire this kind of very severe misunderstanding of the security model.
|its all a matter of scale. like say you issue a checkpoint every millenium for part of the tree that is 500 years old
|jonpry: if you do things like that you are just left trusting people to give you valid data— in the design of bitcoin we work very hard to avoid having any third party trust. Miners are only trusted to provide ordering, the fact that it's viable to do this is— in part— because they're not able to do much while violating that trust.
|i'm telling you that the only security violation is the same as using checkpoints
|jonpry: you are wrong
|you have not seen the code or know the scheme so how do you know?
|because you are badly confused and the chances of you getting it right without understanding are zero
|jonpry: you've asserted this, then linked me to a page which makes no concrete claims about security at all, and which linked a whitepaper where the author clearly had a fairly poor understanding of Bitcoin.
|So I'm skeptical, but happy to see—
|i don't have time to explain it all. when the code comes out people will have a lot of fun analyzing it
|Well I guess there is nothing to discuss then; if you're nagging sipa for something as trivial as the headers first code I suspect you're not likely to ever implement anything at all.
|i actually have it working
|just the process of a new node syncing is not done. but local pruning works
|jonpry: But in any case, I'm on the record saying that I am very skeptical about the security claims that you're making. If you want to go tell people there is no issue, okay— but with notice that sounds more like fraud than ignorance.
|i am just getting paid to write the code. i have no interest in the coins success
|Yea, thats clear enough.
|and if it helps the guy insists on doing it in a way that is not secure so no such claims will be made
|Thats better. :)
|but what is interesting is that it is secure under same assumptions as checkpoints
|jonpry: in future, sipa is available on #bitcoin-dev and it's much less likely that we'll assume you're a researcher if you ask there ;)
|If you go ask him about this in there you'll cause him to leave the channel.
|I suggest you do not.
|i don't understand the problem. i am working on semi difficult problems and have solved some things. i asked about some code you guys are working on and its turning into a flame war
|the proof of security is simple
|checkpoint is a block which is asserted by the user to be good right
|jonpry: you showed up on a low-volume research channel making false claims and demanding free code which you are going to turn around and charge somebody for
|jonpry: The security model is not the same because the design undermines the assumptions that make checkpoints even remotely tolerable (though we consider them unfortunate and want to remove them even considering that)
|block contains hash of UTXO set. it's infeasible to provide a UTXO set with same hash. so therefore the user by choosing a checkpoint has chosen a UTXO set
|assuming that set can be found. no further problem arise
|jonpry: Bitcoin core still verifies all the data, a checkpoint that e.g. invents a billion coins out of thin air.
|yes the code cannot verify a checkpoint. but even bitcoin cannot verify a checkpoint is part of most work chain
|jonpry: yes, in fact— it can and does. Assuming the user is not partitioned from the most work chain.
|if another most work chain is found with fork point before the newest checkpoint it will be ignored
|it allows the user to choose an alternate view of reality
|which is arguably less extreme than what MBC offers, but i claim its just as bad
|Yes, indeed, but also noisly logs it as an error condition. And we're publically committed to never creating one near or in competition in the reference)
|* gmaxwell is reminded of 'It is difficult to get a man to understand something, when his salary depends upon his not understanding it'
|jonpry: it's completely transparent and still audited by the user.
|we could have the same rules of creating checkpoint
|so the security is very clearly not the same, since the software cannot check any of its correctness.
|"and still audited by the user." // talking about checkpoints ?
|the thing is that i don't think it is better. it is just different and better/worse is a matter of philisophy
|because I have yet to see a normal user audit them
|Apocalyptic: its audited by the software.
|(in fact, it looks like from the whitepaper that it can't even check the proof of work, which is pretty boggling)
|the coin is just a reference implementation for others to looks at afaik. i can't see what the argument could be for not writing it
|whitepaper is fubar
|and it does check proof of work
|jonpry: the whitepaper seems to indicate it doesn't (proof chains, and showing no headers in the past) but I believe you fixed that. :)
|the proof chain goes all the way back to genesis for one
|which i think is maybe not in the whitepaper
|jonpry: What does that accomplish? If the headers aren't know, then I can just make up anything there.
|(because they don't have difficulty— they're not costly to compute)
|i don't know. like i said, the headers are now stored. not sure what he was thinking when that was removed
|and we have difficulty it's just computed once a chain is connected
|something about saving 32bits
|jonpry: in any case, a non-transparent fixed blockchain state snapshot is a reduction in the security (requires greater assumptions about the honesty of the authors of them and the level of interest in users in verifying them, as Apocalyptic said he's never seen a user manually verify anything). Perhaps thats fine. .. at the same time, as I said, we also have tenative plans to remove or at least drastically reduce checkpoints in the ...
|... reference software as part of headers first.
|I don't see any great problem with it existing, I do hope people are cautious with the claims about it.
|i'm pretty sure that people will just store all history until some point in the future
|Considering the terrible state of mining centeralization shifting more trust on to miners— e.g. with unverified utxo schemes— concerns me greatly. Esp since like a lot of security is's kind of a lemon market, I can make less secure software that works fine until it doesn't.
|the block won't verify if the utxo set is no good
|Generally I hope that people eventually advance the ZKP stuff until we can use it to give people signtures that prove utxo correct, but thats not viable yet (too expensive to compute the proof).
|jonpry: I can mine a bogus block and give it to you, if you're not verifying anything you can't reject it.
|but all nodes verify utxo
|if /all/ nodes verified it, there wouldn't be a point in having it. :)
|obviously we have some difference in model of what is happening
|we use UTXO set to sync nodes at some point in the past. checkpoint or whatever. once node has that. they can apply transactions from an incoming block to the set. rehash it and verify the block
|jonpry, not all nodes verify the UTXO, that is specifically what an SPV node is
|jonpry: right, now I can give you a utxo that has an extra fake output that gives me a billion bitcoins. Then later I can give you a block that spends it. You'll have no way of knowing this was completely bogus.
|the utxoset with fake output wouldn't be accepted by other nodes so it would shortly become orphaned
|jonpry: sure. Who cares? you're bankrupt now, because I just deposited a zillion coins that never existed and then withdraw all your other coins (as an example).
|i'm not sure if SPV nodes are required in miniblockchain since we are talking about orders of magnitude in reduction of the amount of data to be stored and difficulty of verifying blocks
|maybe SPV nodes don't work
|jonpry: storage reduction can be achieved without any of that.
|everything that works in bitcoin is probably not going to work in MBC
|SPV is a reduced security model— explicitly so. Which is fine and useful.
|you could require huge depth merkle proofs for SPV
|You can run bitcoind today with about 1gb storage... go remove the test for the blocks being there and simply delete the old blocks. So long as nothing tries to fetch the history from you (e.g. you don't have inbound or use history fetching RPCs) it works fine, verifies all new blocks, etc.
|we can sync without downloading all that history. just need history back to checkpoint and utxo set
|he does have a point about checkpoints and just shipping with the utxo upto that point
|gmaxwell: Remember when we had the argument about new-users needing to have trust in tendermint or proof-of-stake algorithms? I said even new bitcoin users require trust, and you countered that they don't. I think we were both right… new bitcoin users can download a trusted copy of the client and wait indefinitely before connecting to the network for the first time. So trust is required in acquisition of the program or algori
|"needing to have trust in PoS algorithm" // for bitcoin ?
|no, altcoins that rely on pure PoS.
|I thought it was a consensus that PoS is fundamentally broken since it allows to mine multiple chains at the same time
|that's been true of existing pure PoS algorithms, but tendermint overcomes that. come to #tendermint if you want to discuss it though.
|it's still contentious here and it turns into a flamewar, which nobody wants on bitcoin-wizards.
|gmaxwell has left #bitcoin-wizards
|diesel__ is now known as Dizzle
|andrew is now known as justanotheruser
|samson2 is now known as samson_
|i have a couple questions about bytecoin's ringsigs: (a) is escrow or any sort of multisig possible, (b) does the utxoset just grow super fast because you can't tell which exact outputs are spent?
|maaku is now known as Guest40907
|pangpang is now known as pen_
|ok, page 14 of https://cryptonote.org/whitepaper.pdf explains that multisig is possible, though it's not clear if it interacts well with the ringsigs