| 01:10:55 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 01:16:15 | jaekwon: | http://jaekwon.com/2014/04/27/the-venetian-bankers-problem/ |
| 01:33:59 | gmaxwell: | "At every minute, ... does not propose in time" Who's minute? |
| 01:35:06 | jaekwon: | global time, e.g. 12:00'00'' |
| 01:35:28 | gmaxwell: | ... |
| 01:35:44 | andytoshi: | there isn't a global time because there are variable communication delays |
| 01:35:57 | jaekwon: | what time is it? |
| 01:36:07 | sipa: | it's 3:36 am |
| 01:36:15 | jaekwon: | yup, :36 for me too. |
| 01:36:27 | andytoshi: | do you want the clock on my IRC comp in vancouver or my laptop in austin? :) both are on my screen and they do not agree on the minute and second.. |
| 01:36:29 | amiller: | only :20 for me here |
| 01:36:42 | gmaxwell: | jaekwon: It really bodes poorly for you that you demonstrate that you do not understand distributed systems in your very first sentence. |
| 01:36:47 | amiller: | the notion of a global time, precise within some fixed bound, is inconsistent with the assumption of a partially synchronous network. |
| 01:36:49 | sipa: | gmaxwell: it took me over a minute to realize you probably mean "whose minute", and are not assuming minute is a person |
| 01:37:10 | jaekwon: | gmaxwell, care to explain? i'm sure i do understand it. |
| 01:38:23 | gmaxwell: | It's really clear to me that you do not, because you don't even understand why I'm basically blown away at your _lack_ of understanding starting in the very first sentence. Everything challenging bitcoin does can be reduced to the problem of precisely timing events in a way that all participants agree on. If you can do that you don't need anything else. |
| 01:38:50 | gmaxwell: | So when you're just taking for granted that systems agree on what time something happens without explaining how… |
| 01:39:13 | jaekwon: | amiller: not true. assumptions about the ability to know what global time it is, is not the same as assumptions about network synchrony. |
| 01:40:06 | jaekwon: | gmaxwell: you're wrong. the problem is ordering events, not timing them. i don't solve the problem of timing events. |
| 01:40:26 | gmaxwell: | If you time them precisely you've ordered them. |
| 01:41:47 | andytoshi: | jaekwon: can you make this work without ever saying "every minute" then? |
| 01:42:25 | amiller: | "The value of ∆ is assumed to be less than the unbonding period" this is by definition not a partially synchronous network, but a synchronous network |
| 01:42:50 | jaekwon: | andytoshi: it's possible. for example, i could use the algorithm as described in Dwork's paper. But when network conditions are good, those algorithms aren't as simple as this one. |
| 01:44:16 | jaekwon: | amiller: i understand, and that's a good point. but that's on the long timescale. what about the short timescale, when networks become slow e.g. a latency of 1 minute? |
| 01:44:16 | andytoshi: | but how can you tell when network conditions are good? individual nodes just see data in and data out, they can't even prove they aren't talking to a cartesian demon.. |
| 01:45:02 | amiller: | well sure, just go ahead and call that a synchronous network assumption then? |
| 01:45:22 | jaekwon: | amiller: in that case, the blockchain & fitness function still achieves synchrony due to the assumption that nodes eventually catch up. |
| 01:46:09 | amiller: | jaekwon, okay, that might be alright - it's still considered partially synchronous if you have a known bound, but you only need to assume it holds "sometimes" |
| 01:46:30 | jaekwon: | amiller: i could. but you see what i mean with the blockchain? for example, if we assume that the unbonding period is infinity, and validators still want to earn fees, then the algorithm still works. |
| 01:46:40 | jaekwon: | amiller: i understand. it's a great point. |
| 01:47:36 | jaekwon: | andytoshi: practically or theoretically? |
| 01:47:50 | andytoshi: | jaekwon: either one |
| 01:48:31 | jaekwon: | when network conditions are good, you'll see that validators are mostly achieving nearly unanimous consensus. |
| 01:49:44 | jaekwon: | gmaxwell: the network as a whole doesn't time any transaction precisely. |
| 01:50:34 | andytoshi: | jaekwon: bitcoin uses the blockchain as a timer, every PoW block is a heartbeat |
| 01:51:02 | stqism: | stqism is now known as sean\at\tox\dot\ |
| 01:51:20 | jaekwon: | kinda, but Bitcoin still adjusts the difficulty based on time. |
| 01:51:36 | jaekwon: | even bitcoin knows the time. |
| 01:51:43 | sean\at\tox\dot\: | sean\at\tox\dot\ is now known as sean\tox\im |
| 01:51:51 | andytoshi: | sure, but it doesn't depend at all on that being precise, it's just an attempt to map blocktime to human time reasonably well |
| 01:51:52 | amiller: | yes bitcoin relies on a synchronous network for that reason |
| 01:52:13 | jaekwon: | andytoshi: it just has to be precise enough. as in my algorithm. |
| 01:53:40 | jaekwon: | anyways, i could absolutely remove any notion of time, and then i'll have to define t the amount of byzantine voting power, make assumptions about how much are byzantine, etc. |
| 01:53:52 | sean\tox\im: | sean\tox\im is now known as stqism |
| 01:54:16 | gmaxwell: | jaekwon: bitcoin knows the time to within increadbly vague boundaries, however. And even there its an attack avenue. |
| 01:54:38 | gmaxwell: | (and it has a way of handling disagreements, so it's all well specified) |
| 01:54:46 | andytoshi: | i don't see how you can define those things in a sybil-resistant way or how any node can trust that the others have the same view of them.. |
| 01:54:56 | sipa: | bitcoin only assumes that block propagation time + clock jitter is less than 2 hours |
| 01:55:22 | sipa: | though if it goes over 10 minutes the rate of convergence will start to become dramatically slower |
| 01:55:45 | jaekwon: | you could assume the same and not require validators in my system to have an accurate time, only something within 2 hours. the algorithm would still work, and the network would reach consensus. |
| 01:56:25 | amiller: | jaekwon, there are still a few things missing too before i could dig in formally, such as what is the criteria for saying a consensus is reached, and for the incentives, at what point does a node get to enjoy the "utility" of having its fees, or for that matter what does it lose by having its money encumbered in a bond |
| 01:58:26 | gmaxwell: | jaekwon: then if its not a requirement you should describe like one, the first paragraph in the algorithim makes it sound like a requirement. Say your nodes are IID over 1 hour time. It sounds like they'd all end up announcing blocks and not accepting anyone elses. |
| 01:59:16 | jaekwon: | amiller: ah yeah. great points. consensus in the presence of network problems is a difficult one to define. would it be ok if i define consensus with the assumption that network issues have cleared up for a moment? |
| 02:00:02 | amiller: | i would be OK even if you just assumed the network was synchronous, since you are aiming for an incentive argument |
| 02:01:51 | amiller: | we don't even have an incentive compatibility proof for bitcoin assuming synchronous network, and the selfish mining paper is in fact a counterexample for large players |
| 02:02:04 | jaekwon: | if the network is synchronous and there are less than half byznatine voting power, consensus is achieved every minute, as more than half the nodes would sign each block, and they won't sign anything that conflicts. |
| 02:02:57 | jaekwon: | thus the currently winning blockchain will always remain the winning blockchain. |
| 02:04:05 | gmaxwell: | jaekwon: what is a node? |
| 02:04:10 | gmaxwell: | How is one admitted to this system? |
| 02:04:19 | gmaxwell: | Why prevents me from starting 10 septillion nodes? |
| 02:04:35 | amiller: | you have to deposit money into a bond in order to have "Voting power" |
| 02:04:55 | jaekwon: | gmaxwell: IID? |
| 02:05:11 | gmaxwell: | independant and identically distributed. |
| 02:06:17 | gmaxwell: | amiller: then it is similar/identical to zooko's proposal? Does he address the "existing miners just refuse to admit any bonds for new miners" issue? |
| 02:06:46 | amiller: | what justifies measuring the resilience of the network based on "voting power" |
| 02:06:52 | amiller: | when voting power is a decision individuals make? |
| 02:07:03 | amiller: | shouldn't it be "potential voting power" meaning like all the coins |
| 02:07:34 | jaekwon: | cool. by a node i mean a process in the gossip layer, like a bitcoin full node. one is admitted to the system by receiving coins to an address. |
| 02:07:50 | amiller: | in other words you need to hope that enough good or rational&small people are leaving their coins in these bonds rather than investing them in whatever people invest in |
| 02:08:44 | gmaxwell: | What purpose does putting the signatures in a hash tree serve? |
| 02:08:48 | jaekwon: | amiller: voting power… is the amount of coins you can lose by signing two blocks at the same height, or signing an invalid checkpoint. |
| 02:09:32 | jaekwon: | the justification of measuring resilience by voting power is in order to attain responsiveness. |
| 02:09:38 | jaekwon: | with a simple protocol. |
| 02:09:51 | jaekwon: | more complex protocols might do better. |
| 02:10:02 | jaekwon: | with any amount of byzantine voting power. |
| 02:10:32 | jaekwon: | gmaxwell: the signature in a merkle tree, is to be able to prove later that somebody signed an invalid checkpoint. |
| 02:10:39 | gmaxwell: | Gotcha. |
| 02:10:42 | amiller: | yes if its rational not to bother putting your coins in the voting power pool, in which case the rational users have their funds elsewhere, and then it's easy for a moderately wealthy attacker to obtain all the voting power |
| 02:11:16 | jaekwon: | i guess the same could be said for bitcoin mining? |
| 02:11:41 | jaekwon: | but yeah, good point. |
| 02:12:01 | gmaxwell: | So what happens when: The coin starts, it has some initial validators. Then later new validators join, and the original validators leave and get their coins back. They behaved honestly. Then they sell their coins. Then, they go and recover the prior state before they unbonded, and procede to simulate a complete replacement history for the network? |
| 02:12:02 | amiller: | yes that's true, IMO we don't have a good incentive compatibility argument for bitcoin mining either. |
| 02:13:08 | jaekwon: | gmaxwell: others during that time have presumably been signing the blockchain, or are you assuming everybody does this together? |
| 02:13:46 | jaekwon: | oh, all the original validators. got it. |
| 02:13:51 | gmaxwell: | jaekwon: Only a majority-of-days/years-gone by, who have since left the system. |
| 02:14:25 | gmaxwell: | (doesn't have to be all, just a majority (since thats what you require for progress right? a majorty? no?) at a particular point in (the now past time)) |
| 02:14:31 | jaekwon: | ah, i forgot to mention this assumption: |
| 02:15:24 | jaekwon: | that clients keep tabs on the state of the blockchain, with period less than the unbonding period. |
| 02:16:18 | jaekwon: | but uh, yeah. if all the bitcoin miners decide to fork the blockchain arbitrarily, i guess anything can happen. |
| 02:16:42 | jaekwon: | perhaps i should just add the assumption that nonbyzantine nodes don't do that. |
| 02:16:48 | gmaxwell: | It's not the same for bitcoin, you have to do work to replace the chain. |
| 02:17:16 | jaekwon: | good point. |
| 02:17:57 | jaekwon: | i've got nothing on that, gmaxwell, besides the usual handwaving, and potential some argument involving clients that keep up to tabs with the chain occasionally. |
| 02:18:04 | gmaxwell: | Vs. here where any majority-of-days-gone-by can just off and create a replacement chain, even after exiting the system completely. (This was why I'd abandoned an effort to majority secret-sharing signing to control p2pool funds for lower variance payout) |
| 02:18:08 | jaekwon: | *potentially |
| 02:19:08 | jaekwon: | say the unbonding period is a year. |
| 02:19:13 | gmaxwell: | By keep tabs you mean "don't allow long reorgs?" That usually leads to nasty attacks, but let me put that aside for a moment— what about a newly joining node? What prevents the network from splitting between new/offline and old/online nodes? going back to the attacks, usually what refusing to reorg means that if someone announces a reorg right at the tolerance threshold some nodes will take it some won't and it creates an ... |
| 02:19:19 | gmaxwell: | ... irreparable reorg. |
| 02:19:49 | gmaxwell: | In a system like what you're proposing there isn't any direct cost to such an attack eaither, just need to get some old signers (who've left the system) to cooperate. |
| 02:21:18 | gmaxwell: | in any case I think there is a place for these kinds of majority system, but I'm not sure if the anonymous bonding-within-the-system part can be made really compelling, since there is always a 'free' attack after the period is up. |
| 02:22:33 | jaekwon: | yup. it's a problem that i can't solve, except that if such a thing were to happen, it would be detectable. |
| 02:22:50 | amiller: | detectable by someone who was online, but you couldn't prove it to someone who just joined. |
| 02:23:29 | gmaxwell: | well you couldn't prove to them which side was lying. |
| 02:23:36 | jaekwon: | hmmm |
| 02:23:49 | amiller: | the idea of requiring synchronous communication between participants, but needing to be convincing after the fact to someone who was asleep for a while, seems like a natural and important property of bitcoin, but it's not one that i think shows up in any dist. sys. models. |
| 02:24:23 | jaekwon: | well, how does a bitcoin user know that the blockchain is the right one? there's assumptions about information delivery. |
| 02:24:31 | jaekwon: | for a new user, i mean. |
| 02:25:10 | jaekwon: | a new user will eventually see that there is a better chain, for instance. |
| 02:26:17 | jaekwon: | similarly, a new user in my protocol may detect that there was in fact a lot of validators that unbonded in an altchain, while they weren't unbonded in the wrong "mainchain". |
| 02:27:04 | jaekwon: | as for proving which side is lying... |
| 02:27:30 | jaekwon: | i'd have to think more about it. perhaps it's not doable in the general case. |
| 02:27:38 | gmaxwell: | jaekwon: Bitcoin knows which blockchain is the right one because it has more total work in it. |
| 02:27:46 | gmaxwell: | So at least you can talk about the costs in an attack. |
| 02:28:26 | gmaxwell: | and the attacker has to outbase all miners, vs attackers being able to have been a majority at any more and then create an indistinguishable future history. |
| 02:28:26 | jaekwon: | yeah, but a new user still needs to receive that better chain… what the new user receives a crappy chain initially? the argument would be that he eventually receives the better chain, yeah? |
| 02:28:40 | jaekwon: | *what if the new user receives ... |
| 02:29:10 | gmaxwell: | jaekwon: initially doesn't matter— he can't be paritioned entirely and forever, of course. (thats the other assumption) But I don't see the relation you're seeing there. |
| 02:29:19 | jaekwon: | i'd like to make a similar argument, that a new user will eventually receive information that points at strange events in altchains. in the worst case, prompts the user for action. |
| 02:29:36 | gmaxwell: | e.g. you can initially connect to a malicious node, get a bad history, and you'll simply replace it when you get data with more work later. |
| 02:29:50 | jaekwon: | yup. as for proving which side is lying… let me think on that. thanks |
| 02:29:57 | gmaxwell: | jaekwon: but what action? I mean you can dispense with all this and just have the users pick blocks. :) |
| 02:30:05 | gmaxwell: | ok |
| 02:38:12 | jaekwon: | presumably these lying validators on the fake chain who have actually unbonded in the mainchain a long time ago, are still signing on the fake chain, otherwise who's doing the signing that the client sees? |
| 02:42:35 | jaekwon: | anyways, some portion of these lying validators that actually unbonded a while ago, it's easy to see that they're lying, as the user will eventually learn of the main chain, and included there is the unbonding transaction for the currently lying validators. |
| 02:45:03 | jaekwon: | of course these lying validators on the altchain could be new validators... |
| 02:48:23 | jaekwon: | but as new users receive new chain information, he gets information on the earliest date that each validator unbonded. this cross chain information could be used to measure the fitness of each chain… |
| 02:49:38 | jaekwon: | you won't see the fitness of the main chain decreased, because that would imply that still bonded validators have signed something that states that they've unbonded somewhere else. there should be a penalty for that! |
| 02:50:11 | jaekwon: | gmaxwell: so yeah. with cross-chain unbonding information, the user can eventually deduce the main chain. |
| 02:50:21 | amiller: | jaekwon, suppose a majority of the vote power disappears for a little while... surely the rest are going to move on at some point? |
| 02:50:53 | amiller: | if they do, and then that temporary majority reveal that they had been building a hidden chain |
| 02:51:12 | amiller: | then those others can't even rejoin the main chain without appearing to be dishonest and forfeiting their money |
| 02:52:11 | jaekwon: | dishonest? |
| 02:52:49 | jaekwon: | if the majority move onto a new chain, that is the main chain. they won't earn any fees unless it's public though. and even still, old validators can join this hidden chain. |
| 02:53:12 | jaekwon: | it's ok to jump chains. you just can't sign two at the same hight... |
| 02:54:08 | jaekwon: | amiller: oops, ignore my comment about not earning fees. that's only true if we make the transactions include the last seen blockchain hash. |
| 02:54:42 | amiller: | it still seems like if a byzantine majority even temporarily wields the votepower... it can do bad things for free |
| 02:55:11 | jaekwon: | uh, so for that, the transactions should be signed along with the last blockchain hash :) |
| 02:55:15 | jaekwon: | yeah. |
| 02:55:31 | amiller: | in that case then my previous comment holds |
| 02:55:52 | jaekwon: | which previous comment? |
| 02:58:22 | amiller: | either the minority loses all their money when the temporary majority reveals a larger side chain (because they made transactions or unbounded on that chain, and now it's no longer the main chain) or else members of majority can do double spends on that shorter chain too before switching over |
| 02:59:19 | jaekwon: | interesting |
| 02:59:32 | jaekwon: | the majority can't collude. |
| 02:59:38 | jaekwon: | otherwise your attack is possible. |
| 03:00:27 | amiller: | btw thank you, i like your scheme and description of it a lot, i think it's actually a pretty neat combination of ideas from ripple and pos and explained a lot more clearly than others. |
| 03:00:38 | jaekwon: | well that seems to put a dent on the optimal player thing. i could say optimal noncolluding nonmajority validators, but it doesnt' have quit the punch. |
| 03:00:56 | jaekwon: | thank you, amiller. |
| 03:00:57 | amiller: | i think trying to explain why we don't like it yet actually reveals a bunch of important things sort of missing from how we describe the model of bitcoin |
| 03:01:50 | jaekwon: | yeah, i understand. |
| 03:03:05 | amiller: | in bitcoin having an infinity of the hashpower only temporarily doesn't help at all |
| 03:03:28 | jaekwon: | ? |
| 03:03:34 | amiller: | modeling hashpower percentage "owned" as a constant is kind of not that meaningful imo |
| 03:03:39 | jaekwon: | you could construct a huge chain, couldn't you? |
| 03:03:45 | amiller: | only if you own that hashpower forever |
| 03:03:54 | jaekwon: | no, even temporarily. |
| 03:04:05 | jaekwon: | you'd just keep it secret and reveal it block by block. |
| 03:04:13 | amiller: | you could construct a huge chain but all you can do with a huge chain is rewind a bit |
| 03:04:29 | amiller: | i mean, it's still huge, but then it's used up |
| 03:05:11 | jaekwon: | i'm not sure where you're getting at with the percentage owned argument. |
| 03:05:28 | amiller: | the point is that if you temporarily have a majority of the hashpower in your scheme, you can always keep it |
| 03:05:44 | amiller: | votepower not hashpower |
| 03:06:11 | amiller: | whereas in bitcoin you still have to keep expending energy to use that hashpower |
| 03:07:35 | jaekwon: | but presumably there's a positive return on investment. |
| 03:07:44 | jaekwon: | so it's still net free. |
| 03:10:39 | amiller: | maybe, but it's even freer in your scheme |
| 03:11:04 | jaekwon: | at least it isn't wasteful? :) |
| 03:11:30 | jaekwon: | but i see what you mean. |
| 03:11:49 | jaekwon: | this might be an even bigger incentive for a majority to behave badly indefinitely. |
| 03:11:59 | amiller: | it's a salient difference is all, we don't have the incentive argument nailed down in either case |
| 03:12:06 | jaekwon: | +1. |
| 03:12:11 | andytoshi: | amiller: agreed on "we can't explain why we don't like it" suggesting we don't have a nice model of bitcoin, when i tried to articulate things i would usually start constructing elaborate attacks, but it seemed like there are some underlying principles i was missing |
| 03:12:57 | amiller: | btw jaekwon have you read my tech report http://tr.eecs.ucf.edu/78/ it basically summarizes the easy things we already know and gives background you're already familiar with, it stops short of anything about incentives though |
| 03:14:25 | jaekwon: | no, i haven't seen it, reading it now thanks! |
| 03:14:26 | amiller: | i kind of made up this thing about the "majority" of mining power having to be evident to other passive observers who aren't participating, but i didn't say anything about them being not-as-synchronous either, which is one of the two most interesting things that just came up in this discussion |
| 03:16:39 | jaekwon: | the thing about being between synchronous and partially synchronous? |
| 03:16:58 | amiller: | no that's not it |
| 03:17:19 | amiller: | it's about the participants being synchronous, but other observers on the network or people who come later not being synchronous |
| 03:17:28 | jaekwon: | ah yeah. |
| 03:17:39 | jaekwon: | what's the other important thing? |
| 03:18:03 | amiller: | "majority of power" being something that changes over time as a result of decisions made, rather than something timeless |
| 03:18:16 | jaekwon: | ah right |
| 03:30:31 | zzyzx: | zzyzx is now known as roidster |
| 03:31:02 | roidster: | roidster is now known as Guest19135 |
| 04:23:44 | gmaxwell: | 19:50 < jaekwon> gmaxwell: so yeah. with cross-chain unbonding information, the user can eventually deduce the main chain. |
| 04:23:51 | gmaxwell: | I don't follow your argument there. |
| 04:24:08 | gmaxwell: | Yes, you know the coins were unbound at some point, but they got unbound in both chains at some point. |
| 04:25:13 | gmaxwell: | e.g. the chain gets mined to height 1000 and then the unbounding time passes (lets say it's 1000 blocks for discussion), and a majority of the miners unbind in 1001, and their coins are released at height 2000. |
| 04:27:21 | gmaxwell: | In the mean time that majority goes and begins a secret for that starts with block 1001 where they don't unbined right away but continue and instead cycle out and replace themselves with new keys and by block 8000 they've all cycled out too and are mining along using new keys. Of course all these blocks just take a fraction of a second to compute. |
| 04:27:51 | gmaxwell: | Once their coins are freed at height 2000 on the real chain they can begin announcing their forged chain at any time to anyone they want. |
| 04:28:21 | gmaxwell: | Someone who recieves both will see that there are two chains where a bunch of old miners made a fork but they're all gone and outside of their penality period. |
| 04:28:33 | gmaxwell: | I don't see how you could distinguish the simulation. |
| 04:28:56 | gmaxwell: | (except via informal methods, like go ask people and hope they don't lie to you— or that they're even seperate people) |
| 04:30:34 | gmaxwell: | (I haven't yet considered the approach to answer why existing miners would let new ones join, if mining is a profitable activity... but I think the proposal is broken before reaching that problem) |
| 04:43:59 | jaekwon: | on the secret (bad) fork, the fitness of that chain should be reduced based on new evidence that the signers actually unlocked earlier on some other fork. so even if they sign from height 1001 onwards on the fork, the user doesn't add voting power from the validators when calculating the fitness |
| 04:45:18 | jaekwon: | so the question is, who else is signing on these two forks... |
| 04:45:50 | gmaxwell: | huh? they can even arrange it so they unlocked earlier on the fork. |
| 04:46:44 | jaekwon: | that's fine. if you unbond anywhere, you've unbonded everywhere. |
| 04:47:26 | jaekwon: | so what are the conditions that would cause a fork to be more fit than the mainchain now? |
| 04:49:49 | jaekwon: | *if you unbond anywhere, you've unbonded everywhere at the height: {for all forks: min(block height where you've unbonded)} |
| 04:50:13 | jaekwon: | that's because the evidence will eventually reach the user. |
| 04:50:22 | jaekwon: | because that's assumed :) |
| 04:51:22 | jaekwon: | Does that make sense? |
| 04:52:43 | jaekwon: | BTW, i'm not saying this is in the paper. I'm suggesting this as a fix given your feedback which is totally valid. |
| 04:52:50 | gmaxwell: | jaekwon: No it doesn't make sense. |
| 04:53:04 | jaekwon: | ok, which part? |
| 04:53:38 | gmaxwell: | I'm saying that the attackers can choose where they unbind. If you "unbined everywhere" I can unbind prematurely in the secret fork and then later when I release it ... invalidate the main chain since I had kept participating even though I was already unbound there. |
| 04:54:59 | jaekwon: | but your contributions to both chains would be identical. so the only way the main chain would become invalidated is if even more people were participating in your secret fork. |
| 04:55:42 | gmaxwell: | yes, a majority of the participants in some point in the past have joined me in the secret fork. |
| 04:56:18 | jaekwon: | cool. so… this is also not in the paper, but i want to modify it to say that users must sign transactions that include the blockhash. |
| 04:56:38 | jaekwon: | so the majority of participants in this case aren't actually earning any fees… which is weird. |
| 04:56:55 | jaekwon: | but uh, i assume in the paper that less than half the voting power is byzantine. |
| 04:57:13 | gmaxwell: | gah. |
| 04:57:18 | gmaxwell: | You are again irritating me. |
| 04:57:38 | gmaxwell: | There is a difference between half _now_ and no-historical-half. |
| 04:58:03 | gmaxwell: | Half now might have incentives, but people who were half in the past may have exited the system and have no incentives inside it anymore. |
| 04:58:27 | gmaxwell: | Consider the simple case where the system is initialize in the first block with a single verifier. |
| 04:59:24 | gmaxwell: | There is a public chain, where validators grow in later blocks. In secret he is constructing a parallel chain which many sham participants making sham transactions which looks a lot like the public chain but isn't. |
| 05:00:03 | gmaxwell: | at some point (his choice) the initial party leaves each of the chains (perhaps different, perhaps the same points). |
| 05:00:58 | gmaxwell: | And at some point he makes public the fork. As a newly introduced node who is not partitioned, you can tell something bad happened, but without trusting third parties how do you know which chain is the 'real' one? (and even if you intend to trust, what is the procedure that doesn't create attacks). |
| 05:03:45 | jaekwon: | Lets call these validators who unbonded in the main fork but are making a sham fork, liers. In the secret fork, as well as the main fork, after block 10001 where the unbonding happens, from thereon, neither fork will accumulate fitness from the liers. is that much agreed on? |
| 05:05:35 | gmaxwell: | jaekwon: I think you should probably address the fork at the beginning case, since its simpler. |
| 05:05:35 | jaekwon: | A new user joins the network, downloads blockchain data, including several forks, one of which is the main and also the sham one. |
| 05:05:52 | jaekwon: | oh |
| 05:06:23 | gmaxwell: | Sure and both the main and the sham one have some fitness from liers and fitness from an enormous amount of additional 'users' (which are all sybils on the sham, but you can't distingish that) |
| 05:06:48 | jaekwon: | how are they sybils? do they not have coins in that fork? |
| 05:07:40 | jaekwon: | can you remind me which line you are referring to, "the fork at the beginning case" argument? |
| 05:07:52 | gmaxwell: | 21:58 < gmaxwell> Consider the simple case where the system is initialize in the first block with a single verifier. |
| 05:07:57 | gmaxwell: | 21:59 < gmaxwell> There is a public chain, where validators grow in later blocks. In secret he is constructing a parallel chain which many sham participants making sham transactions which looks a lot like the public chain but isn't. |
| 05:08:58 | jaekwon: | right. ok. and these sham participants, are they validators? why do you call them shams? |
| 05:09:22 | jaekwon: | they can't be validators unless they have coins bonded as per the (sham) blockchain says. |
| 05:09:26 | gmaxwell: | Because they're not real people, they're just more pseudonymous identities that the attacker made up. Sure they're 'validators' in the fork. |
| 05:09:35 | gmaxwell: | yes, they bonded coins to them... in the fork |
| 05:11:27 | jaekwon: | ok. then unless he has more sham validators on the sham fork than there are on the main chain…. accounting for time of course so we're looking at the integral of validator voting power over time here... |
| 05:11:52 | gmaxwell: | he can have an arbritary number of sham validators, because they're just sybils. |
| 05:12:00 | jaekwon: | right. i meant, sham voting power. my bad. |
| 05:12:05 | gmaxwell: | They cost him nothing because they'er spending imaginary coins in the imaginary fork. |
| 05:12:08 | jaekwon: | where voting power is proportional to coins bonded. |
| 05:12:24 | gmaxwell: | He can have an arbitary amount of voting power in the fork. |
| 05:12:51 | jaekwon: | so let's assume that there is a total of 1M coins ever from beginning to the end of time. |
| 05:12:58 | gmaxwell: | He forked at the second block, and the first block was his, in the fork he owns all the coins and can have all the voting power. |
| 05:13:21 | gmaxwell: | And he maybe only decided to do this attack 10 years after the coin was launched. (for example) |
| 05:14:33 | jaekwon: | ok, good point. if you start off with somebody owning a majority of the coins, then the original owner can create arbitrary sham forks. |
| 05:16:09 | jaekwon: | at any time in the future. |
| 05:16:33 | gmaxwell: | That isn't why. :( |
| 05:18:02 | gmaxwell: | At any point any past majority (it's just simpliest with a single person start) can fork off from any point where they had a majority, and they'll own all coins created since the point of the fork plus any coins they owned before then. They can transfer their 'voting power' to other "people" (socks), and they can bring in more socks to also 'vote'. |
| 05:18:24 | gmaxwell: | The fundimental reason that a past majority can costlessly simulate an alternative network is that there is no cost in producing blocks. |
| 05:23:59 | jaekwon: | mmm so lets say that this majority fork happens on block 1001. |
| 05:27:26 | jaekwon: | that is, we're actually on block 3000, but @ block 1001 there was some majority and they get together today to create a sham fork. |
| 05:28:10 | gmaxwell: | be clear, the sham could be created at 3000 forking back to 1001 when back at 1001 they had no intention of being dishoest (heck perhaps they just lost control of their keys). |
| 05:28:31 | jaekwon: | right. |
| 05:30:14 | jaekwon: | just to be clear… how many of the validators at block 1001 are participating in this sham fork? the majority? |
| 05:30:59 | jaekwon: | i think worst case, the majority from 1001 participate, and they also have the majority of unbonded coins. |
| 05:32:32 | jaekwon: | yeah the new user has no way to know. |
| 05:35:25 | jaekwon: | then the only thing left that i can propose right now, maybe ever, is to say that users connect periodically to the network say every unbonding period/2. |
| 05:35:59 | jaekwon: | new users just have to know what they're joining :) |
| 05:48:18 | jaekwon: | that's a great point. thank you for clarifying despite being irritated. |
| 09:48:29 | [\\\\]: | [\\\\] is now known as [\\\] |
| 09:58:09 | pigeons: | pigeons is now known as Guest98794 |
| 10:24:34 | c0rw|sleep: | c0rw|sleep is now known as c0rw1n |
| 10:30:05 | pigeons: | pigeons is now known as Guest27507 |
| 10:38:29 | [\\\\]: | [\\\\] is now known as [\\\] |
| 10:49:03 | [\\\\]: | [\\\\] is now known as [\\\] |
| 12:50:22 | cr3pe: | cr3pe has left #bitcoin-wizards |
| 15:29:16 | cr3pe: | cr3pe has left #bitcoin-wizards |
| 15:44:56 | Guest27507: | Guest27507 is now known as pigeons |
| 16:21:23 | dexx: | dexx is now known as dexX7 |
| 16:45:30 | stephenreed: | In the super peer network I am designing, I would encrypt all communications between nodes. Is SSL/TLS not in bitcoin for a reason? |
| 16:46:47 | stephenreed: | For example, certificate authorities are centralized and X.509 certificates can be revoked. |
| 16:49:49 | stephenreed: | If that is the objection, then I would allow users to self-sign their own certificates and not enable checking for revoked certificates in the code. |
| 16:51:55 | gmaxwell: | Bitcoin does not have a strong need for encrypted communications— peers are untrusted. And TLS is an enormous attack surface and all remotely complete implmentations run into rather scarry remote vulnerabilties on a fairly regular basis (heartbleed is notable only that it got a lot of press, — no one mentioned the remote code execution vulnerability in NSS a few weeks earlier). Un authenticated TLS provides even less value than ... |
| 16:52:02 | gmaxwell: | ... centeralized TLS. |
| 16:52:08 | gmaxwell: | er. s/weeks/months. |
| 17:01:01 | andytoshi: | stephenreed: if you have trusted peers you can probably also use them as signing authorities. but i'd be surprised if you need encryption. notice that anything which is published does not need to be encrypted for example (which is why bitcoin has no need of encryption) |
| 17:04:00 | Aesthetic: | Aesthetic is now known as Logicwax |
| 17:04:07 | stephenreed: | My network scheme guarantees at most three hops from the originating wallet to the temporary mint. So why even let someone count transactions before they reach the public ledger? |
| 17:04:20 | nsh_: | temporary mint, you say... |
| 17:04:24 | nsh_: | nsh_ is now known as nsh |
| 17:04:55 | nsh: | * nsh smiles |
| 17:05:47 | stephenreed: | Here is the new project link: https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403 |
| 17:07:44 | stephenreed: | If you have a single mint there are many advantages and some notable problems go away. So I have a temporary mint whose new block is verified after the fact, with a consensus based repair if the mint misbehaves. |
| 17:07:51 | tacotime: | Skycoin published their PoS whitepaper today too: https://github.com/skycoin/whitepapers |
| 17:07:58 | tacotime: | Though I haven't read it extensively |
| 17:09:55 | petertodd: | tacotime: I see them using the term WoT like it's a machine-readable thing with well defined properties :/ |
| 17:11:23 | petertodd: | also, "the community" <- part of what makes bitcoin work is a way to define the community robustly... |
| 17:11:51 | petertodd: | stephenreed: don't get distracted with encryption for your project at this stage |
| 17:13:12 | tacotime: | yeeeeah, distributed timestamping via PoS also sounds kind of scary |
| 17:13:34 | stephenreed: | I previous research was for distributed artificial intelligence and I have a convenined Java library for TLS/SSL, certificate seriver, Chord-integration. OK - I see your point and will pull that stuff out of the code for now. |
| 17:14:22 | petertodd: | tacotime: always worth asking the question about how your PoS system is solving the "detect if I'm being jammed" problem |
| 17:15:22 | petertodd: | stephenreed: ^ |
| 17:16:11 | stephenreed: | Could you elaborate on the "detect if I'm being jammed" problem? |
| 17:17:22 | petertodd: | bitcoin requires a jam-free network to operate, however no such network exists, fortunately we can *detect* if we're being jammed by the fact that if we are blocks won't be getting created - the longer the interval between blocks the higher the probability you are being jammed |
| 17:21:43 | stephenreed: | petertodd: The super-peer network is hub and spoke from the super-peers out to the full nodes and to the SPV wallets beyond. See https://bitcointalk.org/index.php?topic=584719.msg6441624#msg6441624. More resistant to jamming, but I need a response to this attack. |
| 17:23:26 | petertodd: | what makes you think the resistance to jamming is what matters? |
| 17:23:49 | petertodd: | here's a basic question to ask: with stake, can I use that stake to get more stake? |
| 17:27:24 | stephenreed: | petertodd: I am ignorant of the jamming issue . The reward distribution algorithm is not yet designed. In principle, the current $500 million mining reward should be allocated so as to pay for the infrastructure each node requires to handle all the worlds financial transactions. |
| 17:28:44 | nsh: | spoiler: you will not be handling all the world's financial transactions. |
| 17:29:30 | stephenreed: | petertodd: In principle, the reward distribution should motivate full nodes to vote their stake, but should otherwise avoid the "rich get richer" problem. |
| 17:29:50 | nsh: | i would aim for a marginally less-ambitious goal of learning something useful about the intractability of distributed consensus systems while getting some useful and transferable programming experience :) |
| 17:29:59 | petertodd: | stephenreed: well, lets talk about where it matters: So if I obtain sufficient private keys to get a majority(?) of stake at *any* point in time, I can use that point in time to go forwards and construct a parallel blockchain. When you connect to my nodes serving up that chain, how do you distinguish my chain from the other chains out there? |
| 17:33:10 | petertodd: | in a real system this attack will be possible with less than a majority too, as you have to allow stakeholders to go offline |
| 17:40:22 | stephenreed: | petertodd: The temporary single mint enables the efficient maintenance of a single non-forking blockchain. Problems are detected after the fact by consensus of attached full nodes, and fixed by the next temporary mint, |
| 17:41:44 | stephenreed: | petertodd: I will prepare a white paper. |
| 17:41:58 | maaku: | stephenreed: what prevents me from minting all blocks via sock-puppets |
| 17:42:30 | petertodd: | stephenreed: specifically, minting all blocks that my node *knows about* via sock-puppets |
| 17:42:36 | stephenreed: | maaku: super peers are like todays pools. |
| 17:43:28 | petertodd: | IE, how do I sync my node and be sure I actually came to a state of consensus the same as everyone else? in bitcoin the real work done makes figuring out the cost to an attacker of faking that consensus well-defined; I don't see how in your system there is any cost at all |
| 17:45:38 | stephenreed: | petertodd: Your full node receives the new block from its single corresponding super-peer. Thanks - I need to figure out how that node can verify that it received the same block as every other full node. |
| 17:46:02 | petertodd: | stephenreed: yes, how do I know I have the right super-peer? |
| 17:46:21 | maaku: | stephenreed: not really my question. what prevents me / my super peer from using sock puppets and grinding blocks until the next block names a puppet node as the next signer |
| 17:47:19 | stephenreed: | petertodd: Thanks for giving me food for thought - off to lunch. |
| 18:21:08 | tromp_: | aren't we just shifting the problem from reaching consensus on the blockchain to reaching consensus on the set of eligable signers? |
| 18:28:35 | jgarzik: | tromp_, I think it's fair to say that some people would find that valuable. The key is to allow the option of doing that, without forcing a requirement down the throats of all. |
| 18:39:36 | maaku: | there are in fact applications where a fixed or nearly static and universal set of signing peers is acceptable |
| 18:39:48 | maaku: | e.g. interbank clearing protocols |
| 18:40:17 | maaku: | doesn't solve the same problem as bitcoin though -- but it would be nice if the two could interop, e.g. via a 2-way peg |
| 18:43:43 | wallet421: | wallet421 is now known as wallet42 |
| 18:50:01 | petertodd: | maaku: bitcoin already supports that you know |
| 18:50:25 | maaku: | petertodd: ? |
| 18:50:40 | gmaxwell: | just assign coins to a multisig and you can do a signing based 2 way peg right away. |
| 18:50:43 | petertodd: | maaku: witha fixed set of signers you can just use multisig obviously |
| 18:50:58 | gmaxwell: | Thats what I wanted to do with the private chain thing as a fast TTM way to demonstrate that kind of technology. |
| 18:51:19 | petertodd: | maaku: I wrote about that last year when I was talking about fidelity bonded banks and trusted ledgers |
| 18:51:59 | maaku: | petertodd: not what i meant. do a consensus-based fast private chain, and 2-way peg between it and mainchain |
| 18:52:10 | gmaxwell: | a downside is that multisig doesn't scale to a very large number of signers (e.g. 200 out of 2000)... though threshold signing can. |
| 18:52:18 | maaku: | with things like unilateral withdraw to make it safe to use |
| 18:52:35 | petertodd: | maaku: define unilateral withdraw |
| 18:52:47 | gmaxwell: | petertodd: if the signers stop signing you can still get funds out. |
| 18:52:55 | maaku: | petertodd: i can move coins out of the private chain without any cooperation from anyone |
| 18:53:04 | maaku: | (but if I try to do so fraudulently, people can stop me) |
| 18:53:51 | petertodd: | gmaxwell: right, which can be done by providing nLockTime'd transactions even now, and more advanced as we talked about last year w/ fraud proofs |
| 18:54:28 | maaku: | petertodd: we're talking about pegs |
| 18:54:37 | maaku: | i'm not sure what nlocktime'd transactions have to do with that |
| 18:55:07 | petertodd: | maaku: they're trusted signers - they can just as easily give people nLockTime'd transactions that take the coins out. more edge cases where it fails, but this stuff *can* be implemented right now |
| 18:55:56 | maaku: | petertodd: no, that defeats the whole point of a fast private chain as you'd have to double-spend every nlocked transaction on the main chain |
| 18:57:27 | gmaxwell: | It requires a 1:1 matching of trades, I believe. The problem is that you have to refresh the refund on the main chain any time the coins chains hands. (or at least within some small constant of it, if someone is willing to put up some float funds). |
| 18:57:27 | petertodd: | maaku: you realize that without putting a hash of the private chain state on the main chain there isn't a clear basis for how to resolve forks... the advantages compared to just giving nLockTime'd transactions aren't all that large |
| 18:57:57 | gmaxwell: | petertodd: huh forks? I think you're not following that maaku is talking about there. |
| 18:58:53 | maaku: | the setup is that you have some consensus system that is doing 10,000's of tps, or a private data center chain doing 1,000,000 tps, and bitcoin main chain doesn't know or care |
| 18:59:10 | petertodd: | gmaxwell: when you withdraw funds when the trusted signers unexpectedly get hit by a bus, you need the main chain to know what the longest private chain is, which is easy to solve by publishing a hash of it in the main chain, less reliable to solve by the "prove highest block number" stuff we talked about last year |
| 18:59:11 | maaku: | and at any time you can pull funds out using just your receipts |
| 18:59:54 | petertodd: | maaku: receipts == nLockTime'd transactions without a way to figure out how to invalidate receipts made invalid because an even longer chain was issued - like I say, you can get 90% of the solution already |
| 19:00:44 | gmaxwell: | I don't see why you're saying that. nlock requires a 1:1 matching in the normal, everything working case. |
| 19:01:01 | gmaxwell: | (which is fine for some applications— and should be developed— and not others) |
| 19:01:44 | maaku: | petertodd: a solution that scales 1:1 with bitcoin main chain. that works for some applications, not for others |
| 19:02:31 | petertodd: | gmaxwell: it doesn't require 1:1 transaction matching - the refund tx you give me to get my money back can return other people's money back at the same time, and you can arrange for the soonest nLockTime to be the longer chain |
| 19:03:24 | petertodd: | we did talk about all this stuff last year... |
| 19:03:34 | gmaxwell: | petertodd: Indeed, but then it has to all fail at once (only solves busses, not censorship). |
| 19:03:54 | petertodd: | gmaxwell: huh? |
| 19:04:21 | gmaxwell: | petertodd: say the private chain decides to freeze my funds. It keeps updating the refunds and just starts leaving me out. |
| 19:04:28 | gmaxwell: | Now I'm stuck. |
| 19:05:02 | gmaxwell: | maaku has a way to prevent that— where if the private chain won't process my transactions anymore, I can just claw them out, and it can only stop me by showing that I've doublespent. |
| 19:05:03 | petertodd: | gmaxwell: yeah, they're a trusted chain, tough. Like we discussed before, you deal with that stuff with fraud proofs - that's exactly what my trusted ledgers stuff was about. |
| 19:05:16 | gmaxwell: | petertodd: right and maakue has something stronger than that. |
| 19:05:23 | gmaxwell: | maaakkkewwwie. |
| 19:05:29 | gmaxwell: | :P sorry can't type today. |
| 19:05:51 | petertodd: | gmaxwell: what makes it stronger? |
| 19:06:12 | gmaxwell: | petertodd: that you can claw your funds out even if the trusted party goes bad (for you). |
| 19:06:21 | gmaxwell: | But without creating a doublespend risk. |
| 19:06:25 | petertodd: | gmaxwell: no, that's the goal, *why* is it stronger? |
| 19:06:48 | maaku: | gmaxwell: fyi jtimon adam3us and I came up with it, for credit purposes, and it was refined with discussions with you |
| 19:06:54 | petertodd: | gmaxwell: w/ trusted ledgers and a scripting system that doesn't suck that was the exact same idea |
| 19:06:55 | gmaxwell: | petertodd: Because its constructive security, not economic incentives. |
| 19:07:22 | petertodd: | maaku: when did you come up with it? |
| 19:07:47 | petertodd: | gmaxwell: you still haven't explained why it's constructive security |
| 19:07:50 | gmaxwell: | petertodd: I don't think we had the idea of the unilatteral clawbacks, but perhaps we did! |
| 19:08:21 | gmaxwell: | petertodd: because, if the trusted party tries to freeze your funds they will _fail_ instead of just lose their trust/bond/etc. |
| 19:09:31 | petertodd: | gmaxwell: yes, we did come up with that, I could dig up IRC logs... |
| 19:11:07 | maaku: | petertodd: mid-march I think? |
| 19:11:22 | gmaxwell: | well my memory sucks so I don't disbelieve you! :) I do think we had some pretty hard problems with it. wrt making sure that the state updates were actually available. In particuar the notion that the fund holder had to sign was novel to me (I think we were talking about chaum tokens?) |
| 19:11:54 | petertodd: | e.g. http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01786.html <- "Ensuring the bond can-not be collected by the ledger" talks about having the fraud proofs be used to trigger fund collection by the defrauded |
| 19:12:37 | gmaxwell: | petertodd: should go find the wizards log there. |
| 19:12:51 | gmaxwell: | but ideas are a dime a dozen. :P |
| 19:13:22 | petertodd: | gmaxwell: that's feb 25th - I joined wizards march 3rd |
| 19:13:34 | petertodd: | gmaxwell: good ideas aren't :P |
| 19:15:47 | maaku: | petertodd: yes but the (I think) innovative part was flipping it around, so you don't need a fraud proof to reclaim funds, but anyone can provide a fraud or reorg proof to stop you |
| 19:16:46 | maaku: | this isn't about preventing fraud (although it does accomplish that), so much as preventing server operators from shutting down and walking away with the funds |
| 19:17:46 | petertodd: | maaku: we'd already thought of that - fraud can be *not* allowing a withdrawl |
| 19:18:51 | petertodd: | that's actually where I first came up with the idea of proof-of-publication, when I realized how you needed to come to consensus about requests for withdrawl if fidelity bonds were going to work |
| 19:19:26 | gmaxwell: | petertodd: where did we discuss this then, I remember we had a long talk about this. |
| 19:26:42 | petertodd: | gmaxwell: looks to be private IRC communication, e.g. "05:26 I'm also worried bonded banks will need a namecoin-like for proving public visibility of fraud proofs. :( |
| 19:27:00 | petertodd: | (feb 21st 2013) |
| 19:29:26 | petertodd: | gmaxwell: ah, some of it was on -dev at least: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/02/27#l1361943499 |
| 19:29:32 | petertodd: | 01:38 < petertodd> Yes, withdrawal requests are the hardest part. For fidelity-bonded banks I was assuming that there would be a "public place" where anyone could post a fraud notice consisting of essentially "why won't you give my money back?" and whose rebuttle is "well, here is the transaction on the blockchain showing I did so" |
| 19:29:38 | petertodd: | 01:39 < petertodd> Fidelity-bonded ledgers could work the same way, although blockchain rules could equally allow specially marked transactions to pull that off in conjuction with transactions locked for a certain time. (IE, confirmed in chain, but with a scriptPubKey containing a "how many confirmations deep is this tx?" opcode. |
| 19:31:54 | adam3us: | petertodd: tree-chains how do you integrate a child into a parent or does the parent just override as it wishes. (seems like parent could override and hence double spend child transaction subset) |
| 19:32:57 | adam3us: | petertodd: which would seemingly make all but the parent irrelevant in terms of reliance on PoW and confirmations on PoW for transaction completion |
| 19:33:33 | petertodd: | adam3us: it's neither - a transaction output only exists on a specific part of the chain, so there's no question about overriding |
| 19:33:44 | petertodd: | e.g. specific path from root, including depth |
| 19:35:20 | adam3us: | petertodd: well what if two conflicting transactions (spending the same inputs) exist at parent and child level, I am presuming parent wins |
| 19:36:36 | petertodd: | adam3us: no, again, an input only exists on a specific part, so it's not a matter of "parent wins" |
| 19:37:37 | adam3us: | petertodd: if an input exists on LL where can it be spent? only in LL? |
| 19:37:38 | petertodd: | adam3us: either you use it where inputs/outputs are only marked spent at a specific level, or you define it that first mark *above* a specific level wins, however you must then prove the absence of a double-spend |
| 19:38:36 | petertodd: | adam3us: it can only be *marked* spent on LL, or if you define it as so, marked spent on LL and L, and . (top) |
| 19:39:14 | maaku: | petertodd: so say the parent reorgs the child? |
| 19:39:24 | petertodd: | adam3us: but after all, for you to accept my transaction, I must prove to you that it was *not* marked spent anywhere else whre it could have been marked spent, so the two statements are basically equal. (I expect we'll find that marked spent on just LL is the right solution) |
| 19:39:40 | petertodd: | maaku: of course, that's how you can casually order transactions securely |
| 19:41:28 | adam3us: | petertodd: if i allow a tx to be spent on LL it can be reorged / double spent with > 12.5% hash rate? |
| 19:42:28 | jtimon: | adam3us all childs are merged mined with their parent chain independently |
| 19:42:31 | adam3us: | petertodd: seems like it fragments the hash rate (because you said in your bitcoin-dev writeup that miners chose to mine ., L or LL etc and to only obtain the tx for their chosen subsets) |
| 19:42:55 | petertodd: | adam3us: no, because due to the parent can reorg child rule once you wait until the confirmations propagate up, you've got 51% security |
| 19:43:03 | adam3us: | jtimon: if its fully merge mined their is no scaling advantage because all nodes need all tx |
| 19:43:41 | jtimon: | no, you merge mine parent + child 1 or parent + child 2, but not both |
| 19:44:11 | petertodd: | jtimon: correctly, and constraining that is very important to prevent giving people an advantage |
| 19:44:30 | adam3us: | jtimon: if i mergemine the parent I have all tx, or i am mining something where i havent validated 1/2 of it |
| 19:45:36 | adam3us: | petertodd: but if i wait for confirmations to propagate up, parent can reorg child and all PoW except the root has not helped scaling nor security (probably hurt security because some of hashrate has been expended on children) |
| 19:45:58 | jtimon: | the parent is supposed to be empty I don't really understand the point of optionally allowing transactions in the parent, I guess is to prevent the different fractions of the UTXO from being isolated |
| 19:46:31 | adam3us: | jtimon: i think the way it is written in petertodd bitcoin-dev writeup the parent is not empty |
| 19:46:42 | petertodd: | adam3us: all PoW below a parent is being applied to the parent equally you know - a 12.5% attack would be a 12.5% attack against the whole chain, and thus not viable |
| 19:47:23 | petertodd: | jtimon: it's a security-scalability tradeoff, at some point you can do deep enough that the data just plain getting lost is possible because only one or two miners are even mining |
| 19:47:39 | adam3us: | petertodd: ok so if i mine LL that means I mine L and (.) just only validate LL? if so then I am mining blind on potentially invalid or conflicting statements in LR RL and RR |
| 19:48:06 | petertodd: | adam3us: you're not validating anything, you're proving data was published to some % of the total hashing power out there |
| 19:49:28 | jtimon: | so the user must validate the whole chain to know that his funds are valid? |
| 19:49:32 | petertodd: | adam3us: secondly, the statements can't conflict, it's a txin-commitments scheme where you specify the location of where the client-side validator would see a subsequent spend |
| 19:49:34 | adam3us: | petertodd: that implies full node semantics, like committed transactions. once such tx have some large history, scaling gets worse over time |
| 19:50:18 | petertodd: | adam3us: proof history can be pruned with good scaling you realize |
| 19:50:41 | adam3us: | petertodd: clearly i do not or i would not have said it :) so then you'll have to explain why you think this |
| 19:51:27 | adam3us: | petertodd: i think the side effect is similar to committed tx (it seems like a committed tx subset or variant in behavior) and there the utxo just grows and grows with no possibility for SPV consumable utxo compaction |
| 19:52:56 | petertodd: | adam3us: ok, so first of all you agree that in a token transfer system the totken proof sizes scale linearly right? |
| 19:53:11 | petertodd: | *token |
| 19:53:20 | adam3us: | petertodd: also if u record all the smaller PoWs going downwards the tree-chain history becomes much larger. and i think there is no particular reason for the parent to mine a given LL candidate, it could mine a different one (there being still the possibility for multiple candidates) |
| 19:54:01 | adam3us: | petertodd: thats a bit of a generic claim, but say with committed tx there is something linear yes, you have to prove each transfer |
| 19:55:07 | jtimon: | if absolutely nothing is validated, don't you also need the proof of the absence of a double-spend (the whole chain)? |
| 19:55:36 | petertodd: | adam3us: ok, so right there we can make a useful value transfer system. Now, if moving a token from one place to another has a known fee, at some point the sum of those fees is higher than the value of the token, which means you don't need to prove history going back that far! Thus we wind up with O(1) scaling, albeit with a relatively high k |
| 19:55:42 | petertodd: | jtimon: yes exactly |
| 19:56:41 | jtimon: | so, there's no SPV nodes |
| 19:58:48 | jtimon: | it seems like creating another problem, enabling 100GB/s scaling but require every node to download it all |
| 19:59:21 | petertodd: | Merging tokens - what Bitcoin does - is the next problem. Now if I have a transaction with two 1 BTC inputs, I can use a random beacon to chose which one of those inputs I'm going to prove. Now if I'm to fake the transaction and only actually spend one output, I have a 50:50 chance of success, a 1BTC gain if I succeed, a 1BTC loss if I win - I haven't actually come out ahead economically. |
| 19:59:42 | justanot1eruser: | So reading about maidsafecoin, it seems like it trusts the network to be honest about who has storage, bandwidth, etc. So I assume it is open to a sybil attack. |
| 20:00:30 | justanot1eruser: | http://www.safecoin.io/#about |
| 20:00:37 | petertodd: | justanot1eruser: a perfectly valid criticism based on what they've published publicly; privately they have some interesting possible solutions. (with a high chance of said solutions not working IMO) |
| 20:00:44 | justanot1eruser: | Not sure if you guys know anythinf about it yet |
| 20:02:05 | justanot1eruser: | petertodd: How could it work? You can't really prove that electricty went in a certain pattern across wires. You can have the people that saw the electricity (you, ISP, other party), but you need to invoke trust in one of the parties |
| 20:02:05 | petertodd: | jtimon: SPV is outsourcing validation to others - it's far from clear if that's a good idea. e.g. with side-chains miners can conspire to simply steal all the funds backing the side-chain and there's not much you can do about it |
| 20:02:45 | petertodd: | justanot1eruser: simple, you figure out how to invoke trust! that's not always impossible |
| 20:03:29 | jtimon: | that's assuming the full node serving you SPV proofs is participating in the conspiracy |
| 20:04:35 | petertodd: | jtimon: you're missing my point - with side-chains you prove to the blockchain/bitcoin consensus w/ SPV proofs, and if the conditions are met, the miners can essentially make the coins go anywhere they want them too. (modulo moon-math compact proofs) |
| 20:05:10 | justanot1eruser: | petertodd: Is their current PoW based on trust, or is it a hash? |
| 20:05:19 | jtimon: | oh, you're criticizing only 2-way peg, not SPV nodes in general? |
| 20:05:32 | justanot1eruser: | Is their current block generation based on PoR or PoW I mean |
| 20:05:41 | petertodd: | jtimon: yes, as an extreme example of why SPV can be dangerous |
| 20:06:58 | petertodd: | justanot1eruser: I don't actually know to be honest; what I did know is I've been asked to look at this PoR stuff on a *very* general level. Not to say I have a lot of faith in the project, but with stuff like trusted computing, auditing, WoT etc. it's not clear to me that it is impossible |
| 20:07:18 | justanot1eruser: | Okay, thanks |
| 20:08:02 | petertodd: | justanot1eruser: again, to be clear, I'm not saying Maidsafe itself is a good idea, I'm just saying what they're trying to do isn't as impossible as it looks. Same way Bitcoin showed that you don't actually need to solve Byzantian Consensus to have useful e-cash |
| 20:08:41 | jtimon: | petertodd so 2-way peg is vulnerable to 51% attacks, that's what the quieting period should help with |
| 20:10:14 | petertodd: | jtimon: quieting isn't magic - a 51% attack executed for long enough still steals the coins, so if I had 10BTC in a 5% merge-mined side-chain I'd be worried, especially if it was a side-chain people didn't like (e.g. Zerocoin) |
| 20:11:23 | jtimon: | a 5% merge mined? you mean 5% of BTC hashrate mining it? yes, I would definitely be very worried |
| 20:12:03 | petertodd: | jtimon: exactly, which gets back to my criticism of merge-mined side-chains in that they are either scalable or secure, not both |
| 20:12:23 | jtimon: | if your reward is interesting enough, I see no reason why most miners wouldn't mine you |
| 20:12:33 | petertodd: | jtimon: yes, but that's not scalable! |
| 20:12:42 | jtimon: | merged mining doesn't solve scalability, nobdoy is saying that |
| 20:12:49 | petertodd: | jtimon: no, lots of people are |
| 20:12:58 | jtimon: | it is just more secure than independent mining |
| 20:13:15 | petertodd: | jtimon: only if you get that majority; it's a double-edged sword |
| 20:13:42 | petertodd: | jtimon: if Mastercoin was merge-mined I wouldn't be at all surprised if someone with a big pool had decided to kill it off |
| 20:13:44 | justanot1eruser: | petertodd: why not? couldn't p2pool have each miner process 3 chains and then if there is liar, a proof can be constructed by someone else mining on that chain? |
| 20:14:05 | petertodd: | justanot1eruser: you're talking about fraud proofs, and they're a very poor substitute for the real thing |
| 20:14:28 | jtimon: | also 2-way peg unilateral withdrawals could be used between public chains too instead of only public-private, so you don't have to rely on committed utxo on the sidechain if you don't want to |
| 20:14:36 | petertodd: | justanot1eruser: same problem proof-of-stake schemes have actually when they start going down the rabbit hole of "I know! We'll make signing your stake twice make you lose it!" |
| 20:15:02 | zooko: | I've been going down that rabbit hole recently. |
| 20:15:11 | zooko: | I'm interested to find out that others are already in here with me. |
| 20:15:12 | petertodd: | jtimon: huh? it's public<->public that's the problem, public<->private is just an exercise in trusting people |
| 20:15:47 | justanot1eruser: | petertodd: so how do we have a healthy number of nodes while scaling to global Bitcoin usage? |
| 20:15:52 | petertodd: | zooko: I spent a lot of time thinking about it and concluded that making such schemes have the jam-detection abilities of bitcoin is very hard |
| 20:16:27 | zooko: | * zooko thinks about that. |
| 20:16:29 | petertodd: | justanot1eruser: well, I'm still a believer in off-chain txs, and since then I think tree chains are another viable approach |
| 20:16:45 | jtimon: | ptertodd by public chains I mean pow secured chains and by private chains the multisigned ones |
| 20:17:11 | petertodd: | zooko: note the subtelty with jam detection: you want to know if you're being jammed in the sense that a majority of minres/stakeholders shouldn't be able to give you a different view of history than another person |
| 20:17:12 | jtimon: | but you don't have to trust the private chain much, that's the point |
| 20:17:23 | zooko: | petertodd: do you mean that such schemes *lean harder on* jam-resistance than Bitcoin does? |
| 20:17:25 | jtimon: | it cannot still your coins |
| 20:17:33 | justanot1eruser: | petertodd: offchain tx where you trust a party? |
| 20:17:35 | zooko: | As in, they suffer worse if jam-resistance fails? |
| 20:17:44 | jtimon: | s/still/steal |
| 20:17:55 | petertodd: | jtimon: right, w/ trusted ledgers and fraud proofs as we were discussing above you can get pretty good protection there |
| 20:18:50 | petertodd: | zooko: so, with PoW, if I have 100% of the hashing power I still can't create a second history for zero cost - if I do I have to split my hashing power across both histories. With pure proof-of-stake I can create an entirely divergent history. |
| 20:18:59 | jtimon: | petertodd here you only use fraud proofs to make people move out of a chain, withdrawals are unilateral |
| 20:19:26 | petertodd: | zooko: similarly, because you can't know how much stake is out there and available, if I have 10% of the stake I can just wait and create what seems to be a pretty convincing history too |
| 20:20:14 | petertodd: | jtimon: note the discussion above - my definition of fraud also includes "Give me my money!", making withdrawals unilateral too in schemes where you can prove fraud to get part of a deposit pool returned |
| 20:20:52 | zooko: | * zooko thinks about that. |
| 20:22:35 | jtimon: | petertodd publishing "why won't you give my money back?" seems different from just moving coins on the main chain |
| 20:22:57 | adam3us: | petertodd: SPV in general will admit arbitrary inflation if the attacker has 51% |
| 20:23:24 | jtimon: | "well, here is the transaction on the blockchain showing I did so" in our case you don't need the private chain to sign anything to withdraw |
| 20:23:48 | petertodd: | jtimon: you'll find that if you try to make a scheme to "just move coins" on the main chain you'll soon get into the same system as a "give my money back!" one - notably you need to come to consensus about what exactly is the best known state of the balances signed by the trusted parties |
| 20:24:05 | adam3us: | petertodd: crypto-currencies arent safe if there is an attacker with 51% hashrate ongoing on side-chains or main-chain either even for full nodes |
| 20:24:59 | petertodd: | adam3us: also not true - a 51% *temporary* attacker on bitcoin would result in a day of chaos, but bitcoin can recover, a 51% temporary attacker on a side-chain can permanently destroy it by taking the backing funds - there is no recovery |
| 20:25:04 | adam3us: | petertodd: for example someone with 51% hashrate could steal all coins that went through their hands over the period of an attack. (and could work to make many cois go through their hands) |
| 20:25:33 | petertodd: | adam3us: exactly, that's a subset of all the coins. 2-way-pegs have a worst case of steal all the funds |
| 20:25:39 | adam3us: | petertodd: i didnt say temporary, you did, so what i said was true |
| 20:25:57 | petertodd: | adam3us: true, but misleading :) |
| 20:27:08 | jtimon: | petertodd: to withdraw you just need a proof of ownership in the private chain, the quieting period allows people to publish a "longer ownership" |
| 20:27:16 | adam3us: | petertodd: well it was clear in my mind. anyway point is things get pretty ugly if someone has 51% of hashrate in crypto currency in general. why would they use it for 1 day vs 1 month. their objective would probably be to cash out maximum $ value, which has to factor in system shocks and bitcoin price collapse |
| 20:27:22 | petertodd: | I think it's a really interesting social problem you're going to find yourself up against if you make it downright profitable to attack side-chains that some subset of the Bitcoin community thinks are harmful. E.g. suppose someone made "Assassination Market Chain" - how much pressure would be on GHash.IO/BTCGuild/etc. to kill it off for the good of bitcoin? |
| 20:27:53 | petertodd: | Fact is, if "Assassination Market Chain" asked me for advice, I'd tell them to be an embedded consensus system instead. |
| 20:28:13 | petertodd: | adam3us: they may have that 51% because they hacked into a few pools... |
| 20:28:45 | petertodd: | * petertodd wonders if anyone would actually notice if 50% of the hashing power was being diverted |
| 20:29:24 | maaku: | yes they would |
| 20:29:29 | jtimon: | petertodd but in fact you're advicing people to mine independently by criticizing merged mining, which is less secure than mining with bitcoin |
| 20:29:38 | adam3us: | petertodd: supposedly some people are monitoring hashrate dips for indication of attack |
| 20:30:02 | petertodd: | jtimon: if you're unsure of the support you have, I argue it is more secure - your attackers have to actually spend real money to attack you. |
| 20:30:18 | petertodd: | jtimon: anyway, embedded consensus is definitely more secure than both |
| 20:30:30 | jtimon: | of course bitcoin is more secure than namecoin, but you're telling people that dogecoin is more secure than namecoin |
| 20:30:34 | petertodd: | adam3us: yeah, "supposedly" - doesn't give me that much faith :( |
| 20:30:40 | adam3us: | petertodd: a what-if would be a zerocash side-chain. which can be used for improved fungibility and have identity on top |
| 20:30:50 | petertodd: | jtimon: dogecoin is more secure than coiledcoin... |
| 20:31:09 | adam3us: | petertodd: well its not like you even need any hash rate or to hack pools, just hack the routers in front of them and selectively drop packets... |
| 20:31:23 | petertodd: | adam3us: I was about to say zerocash actually |
| 20:31:25 | jtimon: | petertodd you're the only person who can attack namecoin without spending money but you resist to show us how |
| 20:31:58 | petertodd: | adam3us: yes, with gmaxwell pointed out yesterday is actually happening, specifically TCP/IP redirect attacks. Now imagine one of those with databases on pools getting simultaneously hacked with fake share info? |
| 20:32:08 | tomaw: | [Global Notice] Hi all. Over the last few days we've noticed an increase in fake donation requests asking for donations in various digital currencies. Please not that freenode does not currently accept cash donations in any currency and anything sent to these scammers will not aide freenode in any way. Also, please see http://blog.freenode.net/2010/11/be-safe-out-there/ |
| 20:32:23 | petertodd: | jtimon: look, I've had this argument before, arguing about it more is a waste of time |
| 20:32:25 | jtimon: | "dogecoin is more secure than coiledcoin..." because dogecoin's reward is much bigger than coliedcoin (zero), not because of merged mining or scrypt |
| 20:32:48 | _ingsoc: | _ingsoc has left #bitcoin-wizards |
| 20:32:48 | Fundraiser: | Due to popular demand, freenode is having to expand its bandwidth allocation on affiliated servers and this is putting strain on our operations. Please help us keep freenode running smooth and support FOSS projects with a small Bitcoin donation to our wallet: 1691YfRr7hPS2WUug8NuRHmH9j64RrkMRa |
| 20:33:00 | petertodd: | jtimon: if you don't agree with me that rewards aren't the same value to everyone, then we just can't have a productive conversation about this |
| 20:34:38 | jtimon: | even if you don't want zerocoins for yourself, you're losing the chance to sell them if you choose to attack instead: the opportunity cost is more or less similar for everyone |
| 20:34:58 | adam3us: | petertodd: you could say because a coin has moved into a side-chain it has been transacted, and so would (if that tx had happened on bitcoin) also be vulnerable to 51% attack even against full nodes. so the main objection i think boils down to the attack d.uration |
| 20:35:22 | jtimon: | the fact that you don't value namecoins, doesn't allow you to attack it "for free" |
| 20:35:31 | petertodd: | jtimon: like I said, I do not believe that is true, so we're just not going to have a productive discussion about it given we have completely different underlying viewpoints |
| 20:35:58 | zooko: | I think you are both partially right. |
| 20:36:01 | jtimon: | I don't know what you don't believe is true |
| 20:36:08 | adam3us: | petertodd: i guess if namecoins have a market price (whichc is obviously the case) then there is a cost, the forgone NMC reward |
| 20:36:22 | justanot1eruser: | jtimon: is it free to walk past a $5 bill and not pick it up? |
| 20:36:24 | zooko: | There is an opportunity cost to not-mining it, as long as *anyone* values it and you could sell it to them. |
| 20:36:43 | zooko: | But OTOH different people have different opinions about what that cost actually is, and some people would actively burn their own money in order to harm another coin. |
| 20:36:49 | petertodd: | adam3us: yes, and with 2-way-pegs there is a tradeoff between "guaranteed to be able to move money in and out quickly" and "a short duration attack will destroy it" |
| 20:37:46 | petertodd: | zooko: exactly - my local government may not allow me to mine Zerocoin, in which case the value of it is zero. I may have a competing crypto-currency, in which case it's negative. Or I might just be a irrational nutjob - best not to design systems where small irrational nutjobs can attack you. |
| 20:37:47 | adam3us: | petertodd: its not necessary to move coins very quickly as it is just a (moderately expensive) liquidity mechanism.. atomic swaps and market makers would in practice do most of the tx |
| 20:37:59 | jtimon: | s hort duration attack can't do much if you set the maturity period long enough |
| 20:38:28 | petertodd: | adam3us: I know that, which causes it's own issues, and at the same time, if you do a good job of it, then you might as well just use tree-chains:P |
| 20:38:42 | jtimon: | specially if you're not relying on commited UTXO on the sidechain for the withdrawals |
| 20:38:56 | zooko: | * zooko is still trying to think about what petertodd said earlier about jam-detection, proof-of-stake, etc. |
| 20:39:39 | petertodd: | zooko: do you understand why a long, 2 week, retarget interval is a good thing? |
| 20:39:46 | adam3us: | petertodd: i am not sure that tree-chains usefully scale. it seems to be committed tx variant + full node + argument that eventually fees exceed tx value (for massive k the number of tx for this to be the case) |
| 20:39:55 | jtimon: | petertodd although sidechains and tree chains have different pruposes, you could implement your tree chains idea on a sidechain |
| 20:41:04 | adam3us: | petertodd: or i am not sure how you can convince a non-full-node that a coin has not been double spent short of sending him the blockchain as the payment |
| 20:41:13 | jtimon: | merged mined or not, whatever you think is more secure, even with the altpow you like more |
| 20:41:28 | adam3us: | petertodd: (if there is literally no validation, just proof of publication) |
| 20:41:36 | petertodd: | adam3us: well it's a basic tradeoff between trusting people to do validation for you and not |
| 20:42:01 | jtimon: | adam3us: everybody is supposed to receive the whole blockchain with tree chains if I'm not mistaken |
| 20:42:09 | adam3us: | petertodd: so then what... centralized signing authorities that vouche they are a full node and its not double spent? |
| 20:42:26 | petertodd: | adam3us: however, there is an interesting middle-ground, which is you can use fraud proofs and have the consensus systems build on top of the tree-chains layer allow for people to profit by finding tx fraud |
| 20:42:36 | zooko: | petertodd: yes |
| 20:42:42 | petertodd: | adam3us: that is what my off-chain tx's were all about |
| 20:43:09 | petertodd: | jtimon: not the whole blockchain; sufficient and transferrable proof that their txouts are real |
| 20:43:11 | adam3us: | petertodd: i thought you were mr decentralization (I am too, but this doesnt sound so decentralized as a plan!) |
| 20:43:37 | petertodd: | adam3us: I'm also pragmatic - I'm going to accept centralization for my coffee buying if it keeps bitcoin itself decentralized |
| 20:43:40 | jtimon: | petertodd: no, I need to know there's not a previous doubl-spend |
| 20:44:00 | petertodd: | jtimon: re-read my tree-chains paper - it constrains where you have to look for that double-spend basically |
| 20:44:09 | adam3us: | petertodd: yeah i get the general idea bond of good behavior meaning u can sort of trust a node up to the point where it cashes its reputation in (if it has some huge good behavior bond) |
| 20:44:35 | petertodd: | adam3us: yes, and compared to "make bitcoin itself centralized" that's a huge win |
| 20:45:00 | jtimon: | fair enough I'm just not convinced it will be small enough if nothing is validated in-chain |
| 20:45:10 | adam3us: | petertodd: i think for example 1GB blocks would be centralization. |
| 20:46:35 | adam3us: | petertodd: isnt this in the same direction as 1MB blocks forever and $10k minimum tx size on bitcoin? everyone else uses trust me, or behavior bond centralization things. in that model unless u have $10k you may get defacto subjectd to the whims of the centralized services, which may over time subvert teh good behavior definition |
| 20:46:54 | jtimon: | I really think private chains/off-chain transactions are the only solution for scalability, the point is making them as trustless as they can be |
| 20:47:31 | petertodd: | adam3us: look, this is a boring conversation, I agree with you, where we disagree is the idea that you've helped solve the problem with the specific idea of merge-mined side-chains - I think you're making that problem a lot *worse* |
| 20:47:34 | adam3us: | jtimon: yes. private chain plus fraud proof has some similarity with good behavior bonds |
| 20:48:11 | jtimon: | yes, they're both basically try to solve the same problem |
| 20:48:14 | petertodd: | adam3us: as for private chains... as was discussed earlier, I was writing about them under the name trusted ledgers last year, and do think they are a good thing |
| 20:48:23 | adam3us: | petertodd: i have not so far heard an argument for why side-chains would be more centralized. other than their flimsy " its too much work to setup merge mining" |
| 20:49:10 | petertodd: | adam3us: merge mining has at best the exact same bandwidth, disk, etc. problems that raising the blocksize does, at worst it has all those problems plus admin overhead |
| 20:49:11 | jtimon: | the argument is that if there's 1000 chains, mining will become too centralized |
| 20:49:44 | maaku: | * maaku would rather spend time implementing this than arguing over it |
| 20:49:46 | jtimon: | I dbout miners will bother to mine 1000 chains though, only the ones with enough reward will make it |
| 20:49:47 | adam3us: | petertodd: for example it can be possible to have a side chain with 1GB blocks and reduce bitcoin block to 100kB and have the ability to unilaterally remove coins from the 1GB block if the centralization policy attack occurs |
| 20:50:08 | petertodd: | maaku: you'd rather implement something that's harmful than think through whether or not it is harmful - that's not a sign of having wisdom |
| 20:50:32 | maaku: | petertodd: no, I'd rather no debate obstinate people on the internet |
| 20:50:33 | maaku: | maaku has left #bitcoin-wizards |
| 20:51:24 | adam3us: | petertodd: so in that sense side-chains reduce centralization. or alternatively if we leave the status quo, when tx demand is > 7tps we'll have an argument about increasing block size on the main chain where there will be no nice answer |
| 20:51:26 | petertodd: | adam3us: which means the actual system is your 1GB side-chain, and you've basically just made "bitcoin that matters" a 1GB blockchain, ugh |
| 20:52:02 | adam3us: | petertodd: no because there is a unilateral return you get to have the benefits of a large block without the political risks |
| 20:52:10 | petertodd: | OTOH if you don't implement merge-mined side-chains, the argument appears to happily be off-chain stuff, and hopefully particularly elegant versions like trusted ledgers/private chains where at least you can generally get your money back |
| 20:52:30 | petertodd: | adam3us: I just can't agree with you re: political risks there |
| 20:52:32 | adam3us: | petertodd: (because if the more centralized large block nodes decide to freeze your coins you can move them to the main chain yourself) |
| 20:52:56 | petertodd: | adam3us: which applies equally well to private chains, but without encouraging the centralization of profitable mining |
| 20:54:21 | petertodd: | In particular, if there isn't solid consensus that what the now-centralized 1GB blockchain miners are doing is bad, they're still earning lots of money and can attack the solutions that try to pop up; private chains/trusted ledgers can't do that because they're not tied to mining. |
| 20:55:08 | jtimon: | to be is more important to have user-issued assets on a public chain with high hashing rate, so that they can be issued publicly and unilaterally withdrawn from the private chains |
| 20:55:47 | adam3us: | petertodd: the thing they can do that is bad is collectively impose political decisions on transactions. but you can address that by unilaterally moving your coin to the main chain |
| 20:55:49 | petertodd: | jtimon: whether or not the hashing rate is high has nothing to do with whether or not you can unilaterally withdraw your funds |
| 20:56:22 | jtimon: | no, it doesn't it has to do with the irreversibility of the transactions using that asset |
| 20:56:47 | adam3us: | petertodd: indeed. but its easier to withdraw your assets to a network that understands what your asset is. (as opposed to watermarking a bitcoin tx say) |
| 20:56:50 | petertodd: | adam3us: yes, that's true of private chains/trusted ledgers. However, with merge-mining you're funnelling money, through mining, to those attackers and giving them control of the underlying Bitcoin layer as well. |
| 20:57:19 | petertodd: | adam3us: and again, whether or not mining is invovled as nothing to do with ease of withdrawl |
| 20:58:03 | jtimon: | again, proof of work == what makes transactions irreversible |
| 20:58:17 | adam3us: | petertodd: if your asset is issued by a private chain it maybe hard to unilaterally withdraw it |
| 20:58:19 | petertodd: | jtimon: that is *one* way of making them irreverable, it is not the only way |
| 20:59:10 | jtimon: | others seem fragile to political attack, what if the government tells me to rewrite my private chain's history? |
| 20:59:40 | jtimon: | with unilateral withdrawal to a pow chain, I can really say "I'm sorry, I can't" |
| 20:59:45 | petertodd: | jtimon: e.g. the rules of my private chain can state that I, the ledger maintinaer, must publish a hash of the state of the ledger to the blockchain in a specified way. When it comes time to withdrawl you have a process of coming to consensus about what was the longest valid private chain, which can include proving extensions of that chian, proving fraud, etc. |
| 21:00:41 | petertodd: | jtimon: if the government tells me to rewrite the private chains history I can't after the fact - it shows up as fraud. Secondly when I deposit funds to that chain's 2-way-peg I'm depositing to a specific history, so if they rewrite history even before that, the alt-history never included my funds at all. |
| 21:01:27 | petertodd: | Ultimately all I'm trusting the maintainers to do is prevent double-spends, just like Bitcoin... |
| 21:01:29 | adam3us: | petertodd: achieving consensus on history probably requires time-stamps in proof of work at minimum\ |
| 21:01:31 | jtimon: | exactly, that's with 2-way peg to private chains |
| 21:01:57 | petertodd: | jtimon: indeed, and replacing that one "prevent double-spends" function with PoW is a step backwards |
| 21:02:22 | jtimon: | no, you're not replacing it, you're using both |
| 21:02:24 | petertodd: | adam3us: obviously - you have to have Bitcoin to do the proof-of-publication (not timestamps) of the state of the chain |
| 21:02:45 | petertodd: | jtimon: with regard to just the private chain, yes, that's replacing it. (in the mege-mined/pure-PoW scenarios) |
| 21:02:55 | jtimon: | you can issue petercoins on a sidechain and then move them to the private chain |
| 21:03:03 | adam3us: | petertodd: what is your definitional difference between time-stamping and proof of publication? |
| 21:03:31 | petertodd: | adam3us: timestamping proves data existed before a certain time; proof-of-publication proves it was published to a well-defined audience |
| 21:03:45 | petertodd: | adam3us: it appeas any practical proof-of-publication mechanism also does timestamping as a side-effect |
| 21:03:49 | jtimon: | I'm saying that to me the main purpose of the sidechain is to integrate better with the private chains than bitcoin |
| 21:04:38 | petertodd: | jtimon: I don't understand your point there, why do I need to issue petercoins on the sidechain as opposed to just the private chain? |
| 21:04:58 | petertodd: | jtimon: (I assume you mean merge-mined sidechain there right?) |
| 21:05:23 | jtimon: | because it allows you (or any owner) to unilaterally withdraw to a public chain that cannot be ceased |
| 21:05:25 | adam3us: | petertodd: ok so i think the practical difference for bitcoin related time-stamp/proof of pub is that the miners should see the hashes they do PoW on (rather than say being presented with a merkle root containing a set of hashes) |
| 21:05:35 | petertodd: | adam3us: basically, to understand the difference between the two, ask yourself if timestamping can solve double-spends? |
| 21:05:53 | jtimon: | not necessarily, but as always, why wouldn't you merged mine? |
| 21:05:54 | petertodd: | jtimon: and as I'm trying to explain, private chains can also have unilateral rights to withdraw |
| 21:06:10 | adam3us: | petertodd: well clearly it can its more of an efficiency argument |
| 21:06:43 | petertodd: | adam3us: it has nothing to do with efficiency! timestamping simply has nothing to do with double-spendings - I can easily timestamp simultaneous doublespending transactions to my hearts content |
| 21:07:59 | petertodd: | s/spendings/spends/ |
| 21:08:00 | jtimon: | "private chains can also have unilateral rights to withdraw" the point is to withdraw to the public chain, which is more secure |
| 21:08:40 | petertodd: | jtimon: to be clear, withdraw what? if you mean the petercoin's token, then just add colored coin support to bitcoin |
| 21:09:18 | jtimon: | exactly, that was my point, you need a sidechain because bitcoin won't implement freimarkets specs anytime soon |
| 21:10:06 | petertodd: | jtimon: well, this is the core of our disagreement - you guys are depending on merge-mining, and merge-mining is bad for decentralization if it catches on |
| 21:10:33 | jtimon: | no, what I just said is NOT dependent on merged mining at all |
| 21:10:53 | petertodd: | jtimon: ok, so friedmarkets is going to be independently PoW? fine, knock yourself out |
| 21:12:09 | jtimon: | it's orthogonal to merged mining, I just think merged mining is best but you think independent mining is better |
| 21:12:35 | jtimon: | my point is that sidechains are not for scalability they are for new features |
| 21:12:56 | jtimon: | some of which you need to integrate better with private chains |
| 21:13:12 | petertodd: | whatever... What's interesting is the underlying primatives to make private chains able to have funds withdrawl unilaterally can probably be used for merge-mined/pow sidechains regardless, so if you guys aren't convinced, it's not worth wasting my time. |
| 21:13:33 | adam3us: | petertodd: the disentangling thought experiment we discussed that you wrote up illustrates that you can build with full nodes a decentralized PoW based consensus with a variety of things including (decentralized PoW chain based) time-stamps. |
| 21:13:55 | petertodd: | Meanwhile, when projects ask me to consult for them, I'll continue to tell them the truth, which is that if they don't get a very high % of miner support they can be trivially attacked if they go with PoW or merge-mining. |
| 21:14:37 | petertodd: | adam3us: no, the point of it was to show that proof-of-publication was required, and what proof-of-publication was. If you think it was about timestamping you're mistaken. |
| 21:15:30 | adam3us: | petertodd: i think you're probably just quibbling on definitions |
| 21:15:34 | jtimon: | "...if they go with PoW or merge-mining" by pow you mean independent pow? |
| 21:15:40 | petertodd: | adam3us: what do you think timestamping means? |
| 21:15:47 | petertodd: | jtimon: independent |
| 21:16:08 | adam3us: | petertodd: i used it as a shorthand for PoW chain based time-stamping as i said above |
| 21:16:18 | petertodd: | adam3us: define what you mean by that |
| 21:17:03 | adam3us: | petertodd: its just a "turing completeness" argument. given this construct, you can to some level of efficiency create a bitcoin like system that requires a full node or weaker to participate. |
| 21:17:22 | petertodd: | adam3us: no, I mean concretely, what exactly do you mean by timestamping? |
| 21:17:26 | adam3us: | petertodd: so with that kind of fuzziness it turns out you dont need very much at all |
| 21:18:08 | adam3us: | petertodd: but i just said i dont mean timestamping in the abstract, i mean timestamping in the sense of placing an ordering on a piece of data in a PoW chain |
| 21:18:09 | petertodd: | adam3us: like, if I have digest d1, and you have digest d2, and we compute h=H(d1|d2) and commit h in the Bitcoin blockchain, do you agree we timestamped d1 and d2? |
| 21:19:13 | adam3us: | petertodd: yes i do get it. i said "could be used" (if the programmer was rational in the way he used the API). like for example one data item per stamp for example. as said, just "turing complete" level of "could be used to build" |
| 21:19:24 | jtimon: | petertodd as said my main problem is that when merged mining is criticized most people assume it is compared to independent pow, which puts shitcoins like quark and secure coins like namecoin in a position they don't deserve |
| 21:19:51 | petertodd: | adam3us: look, don't use the term timestamping for stuff that needs more than just timestamping in the future |
| 21:21:11 | adam3us: | petertodd: what i said was probably confusing, but correct. you could build a bitcoin full node system using nothing but a PoW chain timestamping mechanism (presuming you make appropriate choices of what to time stamp and how much data to timestamp at a time) |
| 21:21:48 | adam3us: | petertodd: anyway i guess these things are though experiments so more mathematical rather than practical "turing" equivalences |
| 21:22:00 | petertodd: | adam3us: no you can't, timestamping does not solve double-spends. Now maybe you meant "using nothing but a PoW chain publishing mechanism" |
| 21:22:17 | petertodd: | this is -wizards, we should be using these terms precisely |
| 21:22:19 | adam3us: | petertodd: i said a timestamping system based on PoW-chains |
| 21:22:48 | petertodd: | adam3us: said mechanism may be nothing more than "lots of people get together and make a merkle tree, whose full contents are unknown to any one person |
| 21:22:51 | petertodd: | " |
| 21:22:55 | petertodd: | that can't be used to stop double-spends |
| 21:23:22 | amiller: | adam3us, i think you're missing petertodd's point or not acknowledging it, it's different to say "everyone has SEEN value X" than to say "the document X was known to someone at time T, since everyone has SEEN the value H(X)" |
| 21:23:37 | adam3us: | petertodd: yes but thats like willful ignorance on the part of the user. we're in the realm of how could u use various types of semantics to extract other kinds of semantics. |
| 21:24:11 | amiller: | the former is much cheaper, but it's not as useful, so it can be really misleading to draw conclusions about the usefulness of the latter based on the efficiency of the former, that's the reason for being nitpicky about this differnce |
| 21:24:12 | petertodd: | adam3us: that has nothing to do with ignorance, that's fundemental to what timestamping proves. to solve double-spending you need to prove something stronger than just what time some data existed at |
| 21:24:28 | adam3us: | petertodd: i am supposing you consider that unless the timestamp is defined to not hide multiple commitments then its not really timestamping but proof of publication fine. |
| 21:25:09 | petertodd: | adam3us: yes, that's exactly what I'm saying, hence the terminology of "timestamping something with the Bitcoin blockchain" vs. "publishing something in the Bitcoin blockchain" |
| 21:25:49 | adam3us: | amiller: of course. but my point is that you could use a timestamping service (if you were defining it also) that it stamps one document at a time. or that n node should stamp a hash unless it has seen broadcast the leaves that make it |
| 21:26:00 | petertodd: | which I'll admit, does get abused to "timestamping something in the bitcoin blockchain", but think of that case as "some minor part of the timestamp proof ended up in bitcoin, and it may be shared among n different other proofs" |
| 21:27:25 | amiller: | adam3us, okay that makes sense. i think you are in agreement then, i think "publish" is the best term for this... in cryptogrphy and dist.sys. it's called "broadcast", but colloquially people think broadcast means anything like gossip so publish is a little less ambiguous |
| 21:27:43 | adam3us: | petertodd: so anyway isnt the constant k in the tree-chain so large that it does not for practical purposes scale given the relationship between fees and transaction amounts |
| 21:28:21 | petertodd: | amiller: after all, in cryptography and dist.sys, when they say "broadcast" the broadcast is often either understood to be reliable by definition, or unreliable in reality. Bitcoin's publishing mechanism is special for being well-defined proof. |
| 21:29:10 | amiller: | broadcast is reliable by default "unreliable broadcast" would be unstandard and need to be clearly marked.. |
| 21:29:37 | adam3us: | petertodd: (i think the fee sum > tx argument is something like i can create a coin out of thin air so long as i can provide proof > x fees were spent to create value x.) hmm but then dont i have to do likewise with the fees recursively (fees are also payments) so doesnt it end up being recursive to include the entire history) |
| 21:30:26 | petertodd: | adam3us: I have done some numbers on this, and to receive coins proofs in the region of megabytes looks attainable without doing anything fancy. Obviously with moon math that can be pushed down to maybe kilobytes/hundreds of bytes. |
| 21:30:33 | adam3us: | amiller: in the real world reliable broadcast is hard. |
| 21:30:50 | petertodd: | adam3us: fortunately in academic papers broadcast is easy! (to assume) |
| 21:31:30 | adam3us: | petertodd: ok. but the recursively for fees and the fees that paid for them etc? |
| 21:31:58 | petertodd: | adam3us: you define a system where it's per-tx PoW - with one tx per block and a known block reward that's easy to determine |
| 21:32:38 | adam3us: | petertodd: the PoW reward is the fee? |
| 21:32:54 | petertodd: | to be exact, per byte PoW is really what you want there |
| 21:33:07 | petertodd: | adam3us: yes |
| 21:34:43 | adam3us: | petertodd: thats a lot of PoWs, and an implied short block interval, maybe high orphan rate (is it still a chain?) |
| 21:34:43 | petertodd: | the real thing I'm intested in though, is can you do better than that? e.g. is there semi-moon-math I haven't thought of? clever economic tricks w/ fraud proofs? can we have miners validate in some limited way? the latter especially sounds like sidechains... |
| 21:35:24 | petertodd: | adam3us: no, the tree goes as deep as you want, even if an individual chain is just a 10min interval (for some amount of data) over the whole tree the tx/s is high |
| 21:42:45 | adam3us: | petertodd: can u do better with some interesting tricks. maybe. first challenge was to understand tree-chains. |
| 22:07:11 | adam3us: | petertodd: musing about publication vs time-stamping terminology. that doesnt naturally imply an ordering - we dont just have to publish, but to define who was first to publish. time-stamping tends to imply at least a partial-ordering (down to the clock resolution of the stamper) |
| 22:09:44 | adam3us: | petertodd: what incentive is there for a miner to include a given child in a parent hash (presume you can use NULL or reuse a previous hash if any at that child position) |
| 22:11:13 | maaku: | gmaxwell: well compact spv back-link commitments could hit core for 0.10 (0.a?) |
| 22:11:42 | maaku: | well, maybe not. i was going to say it's a fairly small change |
| 22:11:49 | maaku: | which is true except for the hash-trie stuff |
| 22:12:18 | gmaxwell: | I think the main delay there is that we'll need some time to shed paint the details before deploying. :) |
| 22:13:00 | maaku: | yeah |
| 22:14:06 | maaku: | we also never nailed down to universal satisfaction that the commit-to-all-prev-blocks approach is best, although sipa's simulations were leading in that direction |
| 22:15:15 | maaku: | but kinda like having height in the utxo set, it seems very useful to me to have a complete tree of past block headers committed to in each block |
| 22:18:56 | maaku: | you could do things like binary-search the tree to find common ancestors |
| 22:18:56 | gmaxwell: | I think it's super useful. Though it does make path-to-genesis proofs larger. I don't think we worked out an apples to apples comparison of that. |
| 22:18:56 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 252 seconds)) |
| 22:20:09 | barjavel.freenode.net: | topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 22:20:09 | barjavel.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot austinhill d34th maaku jaekwon skinnkavaj eristisk rdponticelli wallet42 justusranvier nickBW Vitalik__ spinza RoboTeddy prepost CodeShark nsh AnoAnon Logicwax roidster adam3us zooko edulix dexX7 mkarrer hearn EasyAt shinybro_ DougieBot5000 maraoz Luke-Jr coryfields [\\\] pigeons jtimon go1111111 c0rw1n tacotime TheSeven tjopper1 sunshyne LarsLarsen epscy shesek Burrito Hunger- K1773R cajg OneFixt zacm samson_ |
| 22:20:09 | barjavel.freenode.net: | Users on #bitcoin-wizards: Sorcier_FXK dansmith_btc otoburb johntramp iddo quickcoin espes__ harrow jgarzik digitalmagus phantomcircuit Eliel Dyaheon waxwing stephenreed qwertyoruiop realazthat Emcy_ bobke hno michagogo|cloud zenojis Sangheili BCB mike4 copumpkin zibbo gribble mappum ageis mr_burdell amiller roasbeef lechuga_ jcorgan tromp_ mmozeiko Anduck quackgyver stqism Graet cluckj artifexd jchp_ [-krypto-] HM2 so mhanne comboy LaptopZZ_ Alanius Muis weex |
| 22:20:09 | barjavel.freenode.net: | Users on #bitcoin-wizards: perrier UukGoblin kanzure kinlo Mikalv forrestv petertodd Apocalyptic asoltys rs0 poggy azariah4 nanotube warren BlueMatt sl01 @ChanServ keus sipa paperbot a5m0 gmaxwell midnightmagic helo [Tristan] ryan-c optimator justanotheruser heakins lianj wumpus nikitab flammit Krellan jhj1 pajarillo kaptah ewust Fistful_of_Coins |
| 22:20:57 | gmaxwell: | maaku: I assum your pull req will seperate out the adding it and enforcing it? |
| 22:22:48 | maaku: | as separate commits yes, should they be separate pull requests? |
| 22:24:24 | maaku: | gmaxwell: it would be dependent on #3977 |
| 23:19:42 | zzyzx: | zzyzx is now known as roidster |
| 23:20:12 | roidster: | roidster is now known as Guest95936 |
| 23:43:03 | adam3us: | petertodd: also (towards time-stamp) its not necessary to publish the data only a commitment to it. so it seems like an ordered list of commitments is the required function (which is some combination of time-stamps & publication) |