8 May 2020
Z
21:44
Zack
I guess we want multiple explorers running in parallel.
So if they ever show conflicting recent data, the users can check for themselves which of the explorers is more accurately recording the history of when data is available.
Which limits the space of possibilities for the explorers.
21:45
but we need to consider the case where the validators and watchers work together to trick one of the explorers into thinking data is unavailable, when it is actually available to everyone else. This could harm that explorer's reputation.
I wonder if the explorers need some kind of VPN network or onion encryption to disguise which IP address is doing API requests.
J
22:15
Josh
In reply to this message
They could also publish an alert about the bad request and tons of random people would try to check it for themselves.
22:15
although i'm not sure what they'd do with that info
Z
22:15
Zack
yeah. if people check for themselves, and get a different result than the explorer, it damages that explorer's reputation.
22:16
maybe the explorer should reward people who provide it with proof to show that the explorer is displaying bad info.
22:17
this would rescue the explorer from having bad data, without needing a complicated onion network.
J
22:18
Josh
how would they prove the bad data?
22:18
what if the validator just doesn't respond?
Z
22:18
Zack
if the explorer thinks a proof is unavailable.
You just send the proof. Now they know it is available.
J
22:18
Josh
oh yeah they can prove that it is available
Z
22:19
Zack
this would let the explorer realize that a certain validator/watcher combo are liars.
J
22:19
Josh
maybe the question should be about uptime, like there has to be a certain percentage of uptime during that hour
Z
22:20
Zack
there has to be some level of subjectivity involved when the oracle decides what height to freeze history because of unavailability
22:20
but over time, I think our community can develop traditions to handle all the weird border-cases.
22:20
because of the human element involved in the oracle.
J
22:21
Josh
yeah that's the advantage of oracles
9 May 2020
J
00:14
Josh
In reply to this message
It just has to be clear to everyone immediately so that they stop accepting payment on the SC.
00:15
the meta aspect of this is pretty cool
Z
00:16
Zack
if you are even 10% sure it will get frozen, you might as well stop trading and hedge your risk on some other sortition chain.
The exact percentage might depend on the contract.
J
00:40
Josh
Yeah
00:46
would it make sense to require the validator to publish the number of records in the tree and to provide proofs based on the position of the leaf in the tree? the advantage is anybody can ask for any leaf without knowing the hash of the leaf. anybody can reconstruct the whole tree if they want to. the disadvantage is it leaks metadata.
Z
00:47
Zack
the leaf isn't stored by hash.
00:47
the location is uniquely defined by the part of the probabilistic value space that you own.
00:47
that way, a merkle proof of the part that you own is also a proof that no one else owns that same part of the value
J
00:48
Josh
but without inside knowledge, i don't know what that range is for that leaf
Z
00:48
Zack
I don't see any reason anyone would care how many leaves there are.
00:48
In reply to this message
so, the leaf is a range.
If you look up any point inside the range spanned by that leaf, you get the leaf.
00:48
so if you are doing a query, look up a single point
00:48
any point in probability space is contained by a single leaf
00:49
probability-contract space
00:49
if you ask for a proof of a point, you will get a proof of the leaf that contains that point
00:50
the winning lotto ticket is a point
00:51
the baby sortition chains are leaves inside their ancestors. it is really one giant sortition tree made up of smaller ones recursively.
So, it is likely that no one can possibly know how many leaves there are.
J
00:51
Josh
ok, so that means i can construct the whole tree by asking for 0, get a proof which gives me the range containing 0, then asking for the end of that range, say 0.21, getting another proof, until i'm at the end of the range, then I have the whole tree.
Z
00:51
Zack
even if a validator made a claim for how many leaves there are, we couldn't verify if they are honest.
And the number doesn't matter to anyone anyway.
00:52
In reply to this message
yeah,you can do a paint bucket algorithm starting from a point, and download the entire space.
00:52
probability space is one dimension, the other dimension is contract space.
J
00:53
Josh
there are companies that analyze infra-red satellite images to study corn crops, who knows what companies will popup
00:53
could be a lot of money in these things one day
Z
00:53
Zack
sure. big data is big business
J
00:53
Josh
and the api calls should be very cheap
00:53
compared to the value in the SC
Z
00:54
Zack
we can charge some small amount of PoW, if money is not incentive compatible.
limiting api seems to be solved.
J
00:54
Josh
why wouldn't money be incentive compatible?
00:55
the validator is in charge of the API, that's off-chain
Z
00:55
Zack
maybe the validator can trick us into paying them to download lots of data
J
00:55
Josh
so we can't really control that
Z
00:55
Zack
yeah, it probably works with money too.
J
00:55
Josh
i think it's just like any api, that doesn't seem to be a big problem
00:56
there are overpriced services but there should be a lot of competition here
Z
00:56
Zack
we can kind of control it.
If everyone knows that a money based validator is insecure for some reason, then they wouldn't use wallets that depend on money based validators
J
00:56
Josh
yeah if we control the wallets
Z
00:57
Zack
if money-based validators are insecure, then wallets that use them are insecure.
We can't stop users from using insecure wallets, if they choose to.
All we can do is release good tools and make good recommendations.
J
00:57
Josh
yep
J
07:53
Josh
How does a validator freeze an SC, by not publishing root transactions, right? So why not build into the SC that it ends either after X blocks, or after Y blocks in which no roots txs have been published?
07:54
Then a validator wouldn't be able to freeze the SC, it would end early. This would also let people get their funds out quicker in the data availability attack.
Z
07:54
Zack
or they publish roots and don't reveal any proofs
J
07:55
Josh
That's the data availability attack we already talked about.
Z
07:55
Zack
it is a cool idea though. you are thinking in the right space of ideas.
07:55
yeah, the fix to the data availability attack left it in a frozen until final_spend_tx state.
07:55
because the oracle doesn't happen till much later
07:57
maybe we can end it early after the oracle
J
07:57
Josh
Right the blockchain wouldn't know that the txs aren't valid.
07:57
In reply to this message
Yeah. Everybody will have stopped trading anyway.
Z
07:58
Zack
if the oracle can let us out early, then the attacker who was motivated to cause maximum damager would prefer a freeze attack over a data availability attack.
So then, the upgrade you suggest would make sense.
If there are no commits for enough time, we should let it end earlier.
07:58
but we need to wait at least some minimum delay, so people don't have to come online so frequently to see if this is happening.
J
07:59
Josh
Also, this covers the case where there a non-malicious fault, like lost keys, or a DoS attack against the validator.
Z
07:59
Zack
yeah, it is a good idea
08:00
I think we should add this
J
08:00
Josh
They have to be online anyway to watch for bad roots
Z
08:00
Zack
right
J
08:01
Josh
Although in that case they don't have to do anything, here they need to do a final tx.
08:01
So they need to get their privkeys online
Z
08:02
Zack
yes
08:02
as long as it is clear what the setting are on this sortition chain before they put money into it, then it is ok
08:02
they could set up their wallet to only accept sortition chains that are fine with being offline for 2 days at a time. for the weekend.
08:02
or whatever their needs
J
08:03
Josh
Yeah.
08:03
How long does it take to get a decision from an oracle?
Z
08:04
Zack
at least a week with the current settings of governance variables.
A troll can extend it to 2 weeks pretty cheaply, but trying to get past 3 weeks starts getting very expensive.
08:04
the governance variables can be changed
J
08:06
Josh
Ok I'll have to read up on that
J
08:10
Josh
Thx
Deleted invited Deleted Account
11:56
Deleted Account
Excuse me, is there an administrator? Who do I need to talk to for business cooperation?
B
16:47
Ben
In reply to this message
Ack, good idea here
J
19:07
Josh
One of my main concerns is needing to be online constantly. This could be a serious drawback. This is something that's very hard to do with mobile phones. Even if you have a computer at home, many people have issues with electricity and internet outages, or the computer could crash.
19:07
It's very hard for regular people to guarantee that kind of uptime.
19:08
This can be outsourced, but that's introducing more trust into the system. And it's more concepts that people have to learn to secure their funds.
J
20:00
Josh
This seems solvable because the big players in the SCs can afford to be always online and the gains from cheating the small players may be small. Although it can add up if you do it across the whole system, which is what you'd want to do for a retirement attack.
20:03
An attack could be worth more than you think. If I'm a small, offline player with my $1,000 life savings on a SC and I get attacked by data availability, and I have an 0.1% chance of winning the lottery, how much would I pay to receive a guaranteed payout? It's very possible I'd pay 50% or more because of non-ergodicity. If I lose the lottery, I can't just keep playing again and again because I don't have the money anymore. I could have permanent losses like my kid not getting healthcare.
20:05
You could say I shouldn't put my $1,000 on one SC but that doesn't matter. I could be on 10 different SCs but unbeknownst to me they're all controlled by the same validator. I can't put the money in a regular account because that's too expensive in a scaled out world.
Z
20:12
Zack
It doesn't have to be 1 hour. Different sortition chains could be started with different settings
J
20:23
Josh
This is an interesting paper: https://arxiv.org/pdf/1910.10694.pdf
20:24
In reply to this message
Right but even if it's a week, some people are offline for longer than that.
20:26
Also, one of the points in favor of this scheme is it reduces the capital lockup requirements of hub participants because users can constantly be opening and closing channels. If it takes me hours to do that, it's very difficult for me to spend my money.
Z
20:27
Zack
I thought that is why we were going to use the Oracle and sortition explorers and sortition watchers.
So if a data availability attack happens, no one is forced to hold lottery risk
J
20:27
Josh
I'm also probably in several SCs at the same time, so I have to worry about timing issues on all of them.
20:28
If you trust the watchers this isn't a problem. The problem is trusting the watchers.
20:28
Although waiting an hour to move my money is still a problem.
20:33
Z
20:34
Zack
In reply to this message
I dislike how they use the word oracle.
They are polluting the name space.
Their tool has the miners downloading all the data.
At that point, it might as well be on-chain. There is no scalability benefit to doing this vs putting it on chain and pruning it later.
20:35
In reply to this message
Why would you need to trust them?

Any element of trust means it is completely broke.
20:37
In reply to this message
That sounds like it could have useful stuff for us
mx
20:47
mr x
BSV got it right all along xD
J
21:04
Josh
In reply to this message
You have to trust them to be competent, and analyze every potential profitable attack they might have against you.
Z
21:05
Zack
do we have to "trust" full nodes to be competent?
Usually we use the word "trust" to mean "insecure".
J
21:05
Josh
In reply to this message
Yeah seems like all the miners would have to store all the active data. What we need sharding for data availability.
Z
21:07
Zack
ive actually emailed this lazyledger guy before to get his advice about scalability in relation to his paper, but he didn't respond. I forgot about this paper since then.
J
21:08
Josh
In reply to this message
Ok I'll need to find another word. We need to prove to ourselves that there are no incentives for them to cheat us. And that there's redundancy in case they're incompetent.
21:09
In reply to this message
I'll check him out, see if I know anybody in his circle.
Z
21:09
Zack
In reply to this message
no worries, let me read the paper at least to see if it matters
21:10
In reply to this message
yeah, we need to analyze their relation to everyone else better, and make sure that it is incentive compatible with redundancy.

If hiring one is cheap, then hiring 10 should be cheap too.
21:10
they need to be in competition with each other somehow
J
21:10
Josh
And they can't all be the validator
21:11
The validator might be able to outcompete the other watchers if he makes money on the attack
21:12
There's another issue which is coming up in the stock market these days about passive vs active investing.
21:13
If everyone just buys the s&p500, that leads to systemic weaknesses in the system. Nobody is doing due diligence on the actual companies.
21:14
If wallets are just choosing watchers automatically, a similar thing could happen. Researching watchers has a cost.
Z
21:15
Zack
In reply to this message
as long as the attack is more costly to the validator in comparison to how profitable it is for the watchers, it should be ok.
21:17
In reply to this message
yeah, if all your watchers are the same person, that could be bad.
But only if a significant percentage of everyone on a sortition chain is the same way.

Because the validator can only do data availability attacks against the portions that aren't being watched.

This would ruin a lot of watcher's reputations, we would be able to know who failed.
21:18
maybe each watcher should have some kind of security deposit, and if a data availability attack happens, it gets deleted
K
22:24
K
Would it be worth it to temporarily switch to Zano's PoS/PoW hybrid algorithm until VEO has enough hash power?
J
23:40
Josh
In reply to this message
security deposits are tricky; too high and there's a big capital lockup cost; too low and it doesn't really help
23:41
i think a user is still going to want to keep some money locked up in a channel with a hub so they can instant spend whenever they want to
23:42
that money has to be locked up 24/7 or at least during the day or it's too inconvenient
Z
23:49
Zack
sure, some people will have money in channels for more than a 24 hour period
23:51
I expect smart contracts to initially be formed through a lightning path, by using waivers. That way it cab be instant, and atomically linked to other contract updates.
Then I expect the contract to be moved to the sortition-contract layer, defined in the sortition merkle tree.
That way, either participant can re-sell the contract without needing the other's permission, and we don't need to lock up any liquidity from the hubs or channels.
10 May 2020
J
00:30
Josh
yeah as soon as you have value that you don't expect so sell in the next day it makes sense to move it out of a lightning path
J
05:15
Josh
The watchers should work. Being a watcher is incredibly cheap, all you need is a stable internet connection. This means it will be very difficult to lock out competition. Many users will be able to achieve pretty high uptime even by themselves, even with a mobile phone, so the watcher is only a backup and the watcher doesn't know when it's really needed. That makes it really hard to cheat.
Z
05:15
Zack
yeah, good point.
J
05:17
Josh
For ending SCs early during a freeze, maybe wallets could constantly be negotiating settlements with their liquidators and signing waivers and final spends on condition of freeze. If there's no freeze, nothing happens. If there is a freeze, the liquidator gets the funds even if the user is offline and can't sign anything.
Z
05:18
Zack
but then the liquidator would always need a full duplicate of the amount of money in this chain, locked up in another chain
05:18
I think we need to have a long enough delay for everyone to come online and sell
J
05:19
Josh
oh right
05:21
i think that's UX that people aren't used to, that you could be on a hike for two weeks and lose a bunch of money
05:22
maybe people do have to plan a lot of things like rent payments before something like that
Z
05:22
Zack
some sortition chains could be set not to end early. for people that can't handle the responsibility.
05:22
oh, you are saying the opposite
05:22
yeah, it would be nice if there was a way to get out early
05:23
once Amoveo is more popular, there will be more attention on the oracle, and we can probably speed this up
J
05:23
Josh
can't you just sell early to a liquidator?
Z
05:23
Zack
yeah, if you set them up to be last in line
J
05:23
Josh
yeah so you would do that before your trip
Z
05:23
Zack
but then, you might also need their help to transfer the value
J
05:24
Josh
why?
Z
05:24
Zack
because they could need to step out of line, so you can pay someone else
J
05:24
Josh
I mean you actually want to get off this SC permanently and go to a long duration one
05:25
so you don't have to worry during your trip
Z
05:25
Zack
you can atomic swap between sortition chains, sure
J
05:25
Josh
yeah, so you'd swap out all your value to a long duration SC
05:26
that SC wouldn't end early, or it would give you a few weeks to come back online
05:26
but there are situations where that could be stressful
05:26
what if you get stuck in the jungle and can't get back for weeks?
Z
05:27
Zack
then it would be like holding a lottery ticket I guess
05:27
maybe someone like that could pay extra and put their value on the main-chain
J
05:27
Josh
if we assume ordinary people won't be using accounts, that could be your life savings
Z
05:28
Zack
amoveo is optimized for derivative type smart contracts
05:28
if people can use it for their life savings, or while going on jungle journeys, that would be nice.
But we can't let stuff like that distract us from our core.
J
05:29
Josh
if they're living in venezuela and they want to store value in a synthetic USD, it might be their best bet
Z
05:30
Zack
or maybe they are holding a combination of local currency, and something on amoveo that moves inversely to their local currency
05:31
a leveraged negative-bolivar
J
05:31
Josh
yeah, there will be tons of experimentation but that's the beauty of it
05:31
i want to make sure people don't have a bad experience
05:32
it would be sad if someone died and their kids would have had a lot of money but they couldn't find the phone in time.
Z
05:32
Zack
it wouldn't be good if venezuela had a power outage long enough so they all hold lottery risk
05:32
we will just have to allow for really long delays before people like that start getting onboarded.
J
05:33
Josh
it's also a potential DoS attack, the cops can put you in jail until you give up the password
Z
05:33
Zack
so if you don't give it up, it becomes a lottery ticket, haha
J
05:33
Josh
i'm not saying it can't work but we shouldn't take this lightly
05:34
people usually don't want to play the lottery with all their money
Z
05:34
Zack
well, at least once the money is gone, they don't have a reason to hold you
J
05:47
Josh
In reply to this message
"I used to think there would be different blockchains that would specialize for different goals. but this paper shows that this isn't the case. There is going to be one single best blockchain design, at least for all the characteristics considered in this paper." <-- you did say this tho
Z
05:49
Zack
yeah. if there is a better way to store long term value. that is probably a better way to store the on-chain state involved in each sortition chain
05:49
since they work similarly from the blockchain's perspective
05:50
so if someone found a better way to do that, we could probably upgrade that layer of Amoveo to be better.
05:50
but for now, I think the biggest scalability gains will be in probabilistic value type smart contracts
J
06:07
Josh
it's also true that regular account txs won't be expensive for a while, which means this won't be a problem for a while
Z
06:13
Zack
yes
Z
19:50
Zack
So I guess users will pay watchers. Watchers will pay the Explorer.
19:56
It seems like ending the sortition chains early for a data availability attack does not work.
Because of the recursive nature of sortition chains.
If one of the millions of descendents is frozen, that doesn't mean we should freeze the entire family tree
19:57
We can halt trading in one, but we cannot do the RNG early to pick a winner
20:09
Should users pay watchers directly, or buy insurance from them, or some combination?
J
20:12
Josh
In reply to this message
since baby sortition chains still have to post on-chain root updates, what's the scaling advantage again?
Z
20:13
Zack
the validator's computer can only process txs so quickly
20:13
it makes it cheap for new people to become validators
J
20:13
Josh
but they could become validators on the main chain
20:14
they have to do on-chain txs to maintain the SC anyway
Z
20:14
Zack
it's not the opening process that gets expensive. it is the settlement process
20:15
because smart contracts can end up on-chain, and we need the RNG process
J
20:15
Josh
it seems like that would be cheap compared to operating the chain
Z
20:16
Zack
doing regular merkle roots on chain is like, a very small amount of data spread over a long time period, and delays don't matter much.

The settlement is like, a burst of a bunch of data that needs to go on-chain all at once.
20:16
In reply to this message
renting a server and running software is practically free. Doing anything on-chain has a cost.
J
20:20
Josh
true, although there is also a cost of having all those sub-chains locked up for more time than they have to be if the top chain gets frozen
20:22
i like the insurance idea, you could get insurance that your funds won't be frozen and insurance against lottery risk
20:23
the insurance against lottery risk would have to be conditional on you signing a certain tx at a certain time period
Z
20:26
Zack
I think a lot of games devolve into self destructive interactions.
Like, if the validator tries to make the watechers/explorers waste time, it will at least make the validator look bad too.
J
20:27
Josh
it's very easy for everyone to check up on the validator, so very hard for it to cheat
20:28
in the future everybody could have a little box connected to their internet at home that would be checking this stuff
20:28
and most of the time, a mobile phone could do it
Z
20:29
Zack
ok, since people could be their own watchers, I guess it is more important we should make sure that the explorer is incentive compatible.
20:29
what is the financial relationship between an explorer, and the users?
20:30
is it some kind of insurance again?
you choose some portion of the data that you don't want to become unavailable
J
20:35
Josh
what if the validator insures itself and sells all the value in the SC to itself? it can then make the data unavailable, get the payout and still win the lottery.
Z
20:38
Zack
so maybe the explorer needs to buy insurance from the validator, before they can re-sell it to users
J
20:39
Josh
what are the terms of the insurance contract?
Z
20:40
Zack
if X portion of the probabilistic value becomes so that the merkle proofs are unavailable
J
20:42
Josh
how much value will the validator have to lock up?
Z
20:42
Zack
I think that is related to the cost of watching for unavailable data
20:43
so at most, the cost of having the explorer sync all the merkle proofs from that validator
20:43
which should be a lot less than how much value is actually locked up
J
20:44
Josh
so how does the insurance help if the explorer is watching anyway?
Z
20:44
Zack
the insurance is what incentivizes the explorer to actually watch
J
20:45
Josh
how do the users know that the explorer is paying insurance?
Z
20:46
Zack
they don't.
They buy a different insurance contract from the explorer, so that they know it is in the explorer's self interest to watch for unavailable data
20:47
and using sortition chains, I think we can attach the 2 insurance contracts together.
validator -> explorer, and explorer -> user
So we don't waste liquidity.
It is like the explorer is re-selling the same contract
J
20:49
Josh
ok, so the potential attack is that the validator creates lottery risk for some users and wants to collaborate with the explorer so that this doesn't get reported
Z
20:50
Zack
yes
20:51
the explorer doesn't know if you are also using other explorers.
So even if they think an attack could be profitable, because the validator could pay them, they don't want to take the risk.
Because some other explorer could stop the attack, and they would ruin their reputation.
J
20:52
Josh
but which explorer would get insurance from the validator? all of them?
20:52
i guess an honest validator could make a lot of money selling insurance
20:53
or at least it would be worth it to them to sell as much insurance as possible
Z
20:53
Zack
if they make more money selling insurance, then they can charge less for trading fees.
20:53
since validators are in competition to undercut each other for the lowest cost
J
20:54
Josh
yeah
20:54
this should also make things more simple for wallets
Z
21:09
Zack
the important thing to show is that the amount of money locked in these insurance contracts is much less than how much is in the sortition chain.

Even though a data availability attack could steal about as much value as is in the sortition chain.

And I think the way we can show this is by having multiple explorers competing against one another, so if one explorer participates in the attack, the others can prevent it.

So the amount that needs to be locked in insurance contracts only needs to be about as much as the cost of watching, not as much as how much could get stolen in a successful attack.
21:10
So I think explorers will be selling insurance for the slice of probabilistic value space that people own, but the explorer will be buying insurance for the entire sortition chain controlled by one validator.
21:10
that way the explorer doesn't reveal which part they care about when they buy insurance
21:10
so the validator can't know which explorers would need to be bribed to attack a certain portion of the probabilistic value space
21:11
I think we need to calculate the quantities of money in these different contracts more precisely to be sure this works.
21:15
There might be multiple ways to make this work.
What we need is to find one precise example that we can show does work.
J
21:30
Josh
If I'm buying insurance for a small part of the value space from the explorer, how do I know they bought insurance for the whole space?
Z
21:33
Zack
it doesn't matter to you if they did
21:33
as long as they have an incentive not to attack your portion, you are fine
J
21:40
Josh
So the incentive is if they tried to attack my portion they should expect to fail because some other explorer will freeze the SC
Z
21:41
Zack
yeah, do they still lose the insurance contract?
J
21:41
Josh
So the expected value of the insurance payout from the validator is higher
21:42
Either they took out insurance with the validator or they didn't
Z
21:42
Zack
I guess an explorer that noticed that their attack was failing, maybe they would call it off.
21:42
reputation is also worth something
Sarah myra invited Sarah myra
11 May 2020
Z
00:22
Zack
In reply to this message
so maybe an explorer should do a proof of existence when it notices an attack occurring, and it should only get paid the insurance money if it is the first to notice.
J
00:35
Josh
yeah that makes the insurance a lot cheaper because the validator only has to pay out once
00:35
but everyone still has an incentive to check
Z
00:36
Zack
So, we are going to need some sort of write up to explain the relationships between these different participants.
Then we need to go through, and show that even if the attacker does sybil to participate in multiple roles, it is still secure.
J
01:41
Josh
Yeah
01:42
I was thinking mimble wimble could help with scaling regular accounts for long term storage but not sure that helps since most people might want their savings denominated in something other than VEO
Z
01:43
Zack
like, main-chain accounts?
It might help, yeah
But i feel like there are more cost effective features for us to focus on, because as you say, people want a different risk profile than pure VEO.
01:44
it is convenient that we are using the same merkle tree database library for all these main-chain things.
It makes it easier to maintain and build wallets
01:49
Im going to write up a first draft of what we have so far, that will at least help focus further conversations to see if data availability is solvable this way.
J
01:50
Josh
awesome
Z
12:40
Zack
im thinking splitting up the watchers and explorers into different entities makes it really complicated.
But if they are the same person, it can be simple
12:41
and the explorer should maintain a full copy of the sortition merkle tree, like the validator does.
B
12:50
Ben
That does keep it simpler
Deleted joined group by link from Group
CeloStarter Bandits invited CeloStarter Bandits
B
17:46
Ben
Write-up looks good and makes sense.
17:46
The Oracle unavailability attack, that is.
J
18:03
Josh
So the explorer is only punished by reputation loss?
J
18:58
Josh
If the explorers are storing the whole tree, they have the ability to publish merkle roots; maybe we could drop the validator signing requirement and let anybody publish a merkle root with a high fee; instead of freezing the SC, we'd have oracles to invalidate bad merkle root txs. The high fee could pay for the oracle and maybe even an extra reward for whoever starts the oracle if it wins. Users would still have to wait an hour for confirmation, but the SC wouldn't get frozen.
Z
20:53
Zack
In reply to this message
Then anyone would be able to freeze any sortition chain with one tx.
J
20:56
Josh
It won't freeze if explorers show the data isn't available. Also there's a high fee.
Z
20:56
Zack
The explorers showing data is unavailable is what allows us to make the Oracle that causes it to freeze
J
20:57
Josh
Instead of freezing the SC it would just invalidate this tx.
20:57
What does an attacker gain from this attack?
Z
20:58
Zack
In reply to this message
We can't do a separate oracle for every commitment.
20:59
In reply to this message
It is almost free to make a tx. And it does a lot of damage.
J
21:00
Josh
We can do a separate oracle for each commitment if the attacker is paying for it. The fee can be more than the damage.
Z
21:01
Zack
Then the commitments are too expensive
21:01
Because it takes a long time for the Oracle to resolve
21:02
So we can't be sure if we should take the money or not
J
21:02
Josh
We need to know after an hour anyway
21:02
That's how the freezing works, we don't wait for the oracle
Z
21:02
Zack
The Oracle won't resolve for at least a week
21:03
You and I need to know that the data availability attack is happening. But still, the blockchain can't know for a week
21:03
Just like the presidential election. You and I will know the result a lot early than amoveo can find out
J
21:04
Josh
Sure but that's the same in both cases
Z
21:05
Zack
In reply to this message
We can't confiscate this fee until the Oracle tells the blockchain that cheating happened.
21:05
Which takes at least a week
J
21:12
Josh
So?
Z
21:14
Zack
We don't want this extra cost if we can avoid it.
It seems to be a lot bigger than the benefit of letting anyone spam merkle roots for any sortition chain.

Also, letting anyone spam would make programming a lot harder
21:14
What even would be the benefit of letting everyone spam? Less freezes?
But we already showed that the cost of a freeze is low.
21:15
Storing a single merkle root is a lot cheaper than doing an entire oracle
A
21:32
Asindu
In reply to this message
Have you thought of using scilla for Amoveo's state channels?
mx
21:32
mr x
yo are drive chains broken somehow?
Z
21:49
Zack
In reply to this message
I think so, yes https://github.com/zack-bitcoin/amoveo-docs/blob/master//other_blockchains/drivechain.md
It is sad because they are spending so much time building it.
Lj Domingo invited Lj Domingo
Z
21:55
Zack
In reply to this message
Amoveo uses chalang, which is a language optimized for state channels and short contracts. It is also optimized to compile to the shortest byte code possible, so txs can be shorter. https://github.com/zack-bitcoin/chalang
Chalang was written to be the ideal language for Amoveo.

Scilla is optimized for avoiding the kinds of bugs that happen with shared mutable state. Shared mutable contract state is anti-scalable. We purposefully do not support that feature in Amoveo.
J
21:55
Josh
In reply to this message
How is the cost of a freeze low? All the capital in that SC is tied up.
Z
21:56
Zack
each sidechain can be small. you can hedge your risk in other sidechains.
J
21:56
Josh
Anybody can spam the blockchain anyway, that's why we have fees. The only thing they can do is force more oracles, but they bear the costs for that.
21:57
They might as well just publish an equivalent number of fake txs.
21:57
it doesn't matter if you hedge your risk, your capital is still tied up.
Z
21:58
Zack
if you are even 10% unsure that the txs in a certain sidechain actually happened or not, that is a disaster
J
21:58
Josh
If you think there's a 10% risk, then freezing the SC doesn't work either
Z
21:58
Zack
if a sidechain can only get frozen once, and there is a clear measureable block height when it happened, then everyone can act accordingly
J
21:58
Josh
here there's a clear measurable tx that's invalid
Z
21:59
Zack
if there are 300 different mini-forks, and it is totally unclear who is in line for what, then it is a crazy mess
J
21:59
Josh
it's not a fork, it's a list of invalid txs
Z
22:00
Zack
So, lets say I own some sortition value.
And I want to send it to you.
But in the last couple of blocks, there has been 400 different merkle commitments, all sticking dozens of people in line behind me
22:00
How do I get you to be next in line so I can send the value to you?
22:01
if anyone can put someone new in line behind me, then anyone can freeze my value
22:01
doesn't even involve a unavailability attack.
A
22:02
Asindu
In reply to this message
Thanks for the feedback.

Shared mutable contract state is anti-scalable.
Could you explain more on this?
J
22:02
Josh
why can't the validator publish those 400 txs anyway?
22:02
there's nothing magical about a validator
22:03
In reply to this message
they can. and then your value is frozen until the final_spend_tx.
22:04
having one person who can lose their reputation is better than letting any random person who owns veo freeze your money.
J
22:11
Josh
they can't freeze your money, they can just force you to run an oracle
22:11
a validator can freeze your money even with the oracle
Z
22:12
Zack
so, if someone makes a merkle root putting Alice next in line to own my value.
You think this is a situation where an oracle should undo that merkle root?
22:13
but how can the oracle know if Alice should not be next in line?
22:13
The oracle can't know who is first in line. The oracle can't know who has permission to add someone new to the line.
22:13
and if we allow merkle roots to get undone for something like this, then you can never be sure which merkle roots will get undone
22:14
so you can never be sure if your tx is finalized, or if you will lose the money that you have had for days.
J
22:20
Josh
why can't the validator put Alice next in line and do the same attack?
Z
22:21
Zack
they can. and then you have to wait for the final_spend_tx
22:21
this harms their reputation
J
22:21
Josh
so they can attack the entire SC by putting Alice next in line for everyone
Z
22:21
Zack
yes, and then no one will hire them as a validator again.
22:22
everyone will need to wait for the final_spend_tx
22:22
unless they had wanted to pay alice anyway
J
22:22
Josh
but they can extract fees for not freezing your money
Z
22:23
Zack
if they hold your money hostage and try to get you to pay to unfreeze early.
The maximum that they could charge is (the interest rate on that money) + (how much it would cost to hedge these contracts in other sortitoin chains)
A
22:23
Asindu
ls
J
22:27
Josh
In reply to this message
they might be the validator on the other chains also
22:28
if you add up lots of SCs, that interest money could be a lot of money
Z
22:29
Zack
the interest is proportional to how long it is locked up for.
J
22:30
Josh
yeah so they'd optimize the attack for the beginning of a bunch of long SCs
Z
22:31
Zack
retirement attacks are a mixed nash equilibrium anyway. I really don't see this as an issue.
The scalability benefits of sortition chains more than makes up for this small cost.
J
22:32
Josh
i'm not talking about dropping SCs, I'm talking about dropping validators
22:33
the only difference between a validator and a random tx poster is that the validator has reputation
Z
22:35
Zack
if anyone can make merkle commitments, then this attack does become a serious issue.
Because it is cheap to freeze all the money.
22:36
as long as there is a validator, then they have something to lose by freezing everything.
22:36
some expectation of fees is lost.
J
22:37
Josh
what if i do have to sign the ownership transfer? i can prove to the person i'm sending value to what the chain of ownership was with the waivers, so they won't accept the funds if the ownership transfers weren't signed by the right people.
Z
22:38
Zack
i don't know what you are suggesting
22:40
when you tell the validator that you want to add someone new to the line, you do sign that message. Otherwise the validator can't be sure if it came from you.
J
22:42
Josh
why do they care who it came from? can anybody in line sign it?
Z
22:47
Zack
the validator checks if you are first in line.
J
22:56
Josh
ok, so anybody you're transferring value to can check if you're first in line. If you are, then it doesn't matter if someone posted a fake tx.
12 May 2020
Z
00:12
Zack
in order to transfer value, they would need to be second in line.
J
00:17
Josh
I don't understand what you mean there.
Z
00:23
Zack
I think each sortition chain needs a validator who can put new people in line.
J
00:25
Josh
that's the part i'm not convinced about.
Deleted invited Deleted Account
Z
03:36
Zack
In reply to this message
waivers are off-chain. you can't necessarily know who has stepped out of line
03:46
if we let anyone act as a validator, then if they do a data availability attack, we would want to undo that merkle root using an oracle.

But what if they do an edge-case, so it isn't clear if their merkle root will get undone or not?
Then no one would feel safe using that sortition chain any more, because they don't know which parts of the history will get undone.
And the attacker pays practically zero cost to do this attack. just publishing a bad merkle root once.

If there is exactly one validator per sortition chain, and they do weird edge-cases like this, then we can all stop using that sortition chain, and it is the same as if the validator had stuck itself as 2nd in line for everything,
we wait for the final spend tx, and their reputation is ruined. They are giving up a lot of tx fees, so there is a real measurable cost to doing this attack.
J
04:20
Josh
what's a weird edge case?
Z
04:20
Zack
like if we are supposed to undo the merkle commitment if the data is unavailable for more than an hour.
They could make it unavailable for precisely an hour, so different people are unsure whether it should get undone or not.
04:21
right on the edge
04:21
when it comes to the amount of time data was unavailable for, that is something that is relative to your own perspective. It isn't deterministic.
So there are edge cases.
J
04:25
Josh
is that really a problem? the oracle could be that it's unavailable for an hour but everyone would wait 2 hours.
04:25
if they wait exactly an hour they risk invalidating their block but nobody would be harmed either way
Z
04:27
Zack
so lets say the data was unavailable for 1.5 hours.
if you wait 2 hours, then you will accept a merkle commitment that the oracle will later reject. so you will think that you are 2nd in line, when really you were never put in the line at all.
So you might accept a payment that gets undone.
04:27
if you wait 1 hour, but the oracle is set for 2 hours. then you will ignore an update that the oracle accepts. so you might think that you are 2nd in line, when you are actually 500th.
04:29
basically, if there is even a small chance that the oracle will reject a merkle commitment, then you need to stop using that sortition chain entirely.
J
04:31
Josh
In reply to this message
why would you accept data that was unavailable for 1.5 hours?
Z
04:32
Zack
In reply to this message
it is literally the example you came up with.
04:32
im explaining why it does not work
J
04:32
Josh
i said they would wait, i didn't say they'd accept the data
Z
04:32
Zack
wait for what?
J
04:33
Josh
In reply to this message
you have the same problem with the validator, you have to be sure about the data before you accept the data
Z
04:34
Zack
if the validators freezes money, we all wait for the final_spend_tx.
That validator misses out on lots of future tx fees, and their reputation is ruined.

If any random person with veo can do this attack, then they aren't losing any tx fees to execute the attack. there is no reputation to lose.
J
04:39
Josh
In reply to this message
yeah, you're right about this. the advantage of freezing is it's asymmetric, freezing is always safe, even though it's expensive, so in an edge case you can at least freeze and not lose your money. different people could decide to freeze at different data availability periods depending on how much risk they want to take.
Z
04:40
Zack
yes
J
04:41
Josh
but this is an attack i didn't think of before, that a validator can try to trick the oracle, offer everybody liquidity then maybe not even trigger the oracle
04:42
then they could claim they just had internet issues
04:42
they wouldn't have to pay out any insurance
Z
04:43
Zack
I don't understand. do you mean, a data availability attack for less than an hour?
J
04:43
Josh
yeah, right on the border
04:43
people would freak out before that
04:44
we could have one oracle that triggers the insurance payment and another oracle that freezes the block
04:46
actually that might work for no-validator txs too, they'd need to put up a security deposit for the freeze damage for the value in the chain; that security deposit would be forfeited after an hour and the block would be frozen after 2 hours.
Z
04:46
Zack
In reply to this message
that's a good idea. so we can properly handle the cases where an attack doesn't happen, but people need to stop trading because the attack might happen.
J
04:46
Josh
freeze damage would be something like the interest rate on the value
Z
04:47
Zack
In reply to this message
cool idea. I need to think more about this.
04:48
so, the insurance contracts are all off-chain.
What if someone acts as a validator, and just doesn't do the insurance contracts?
J
04:52
Josh
each sortition chain could define a security deposit that's triggered by an oracle
04:52
each valid merkle root tx needs to include that
Z
04:53
Zack
attaching a security deposit to a sortition chain probably isn't compatible with having sorititon chains recursively inside themselves
04:53
oh, putting the deposit on-chain, associated with the mekrle commitment,
J
04:53
Josh
yeah
Z
04:54
Zack
so, after 2 hours they can unlock it, under what conditions?
J
04:54
Josh
just like each baby chain can chose a new validator, each baby chain here could choose a security deposit amount
04:54
In reply to this message
that's a problem, they can't
04:54
but they can use it as collateral
04:55
they need to wait for the oracle to free it up
Z
04:55
Zack
In reply to this message
lets say 10% gets locked up every layer of sortition chains.
So after 5 layers, only 59% of the value is left availabel for making contracts, and 41% is locked up in all the deposits.
J
04:56
Josh
it's even worse, because the same percentage has to be locked up for each merkle root
Z
04:56
Zack
and even then, if only 10% is locked up, and they can potentially do an attack that destroys the other 90%, then that is a 1:9 cost of attack: amount destroyed ratio.
J
04:56
Josh
and it all gets frozen until the end
04:56
they can't destroy the other 90% they can only freeze it
04:58
they don't have to freeze value from the chain, they can freeze other veo they have since it's an on-chain tx
Z
04:59
Zack
so it is locked up until the oracle? that could be weeks away
J
05:00
Josh
In reply to this message
not sure how else it could be done
05:00
but maybe if you've already made a deposit with your pubkey you shouldn't have to make another deposit
05:00
since it's already locked up
05:02
this is kind of like the insurance we were talking about
Z
05:02
Zack
if there is one validator who has an expectation of earning fees in the future, then the cost of an attack to make it freeze is proportional to the expected fees.

To get a similar amount of security by putting a different safety deposit on every commitment, it seems like the amount of money locked up would be (all those fees summed up) * (number of merkle commitments"
05:03
In reply to this message
buying insurance once that covers your part of the sortition value for the entire history of the sortition chain is very different from having someone lock up a security deposit on every single merkle root.
05:04
For the cost of a single deposit, anyone would be able to make the sortition chain frozen until the final_spend_tx.
J
05:06
Josh
the single deposit would be the same cost as the whole insurance; if you keep doing more roots you don't have to add more deposits because you're already covered
Z
05:08
Zack
and what if they put themselves as 2nd in line for everything?
05:09
I guess we would have to get rid of the waiver strategy, and do something like truebit binary fraud proofs on the history of ownership
05:09
waivers are really nice though, because we can prune so much of the history
J
05:10
Josh
i don't think i understand the attack of putting themselves in line; how do they do that without your signature?
Z
05:10
Zack
with the current design, the validator can put anyone in line for any value
05:10
no signature gets stored.
J
05:11
Josh
can we store the sig?
Z
05:11
Zack
then the fraud proof becomes way bigger
05:11
you need to prove the entire history of ownership
05:12
with the waiver strategy, all you need to prove is that you were put in line at some point in time.
And if no one else can prove they were in line in front of you, then you win.
05:15
if we have a really complicated smart contract, the waiver could be like 20 kilobytes of code.
And then when the contract resolves, a portion of the value goes to me, and a portion to you.
So at that point, we can sign new waivers that just tell how the money was finally divided. so we don't need to store the contract any more.
05:16
If every payment needed a signature and got recorded into a blockchain like bitcoin, then you would need to show the entire history of the winning portion of the probabilistic value, which possibly includes a lot of big contracts
05:19
or maybe we could do something like truebit, so you only need to put log2(N) txs of the N-txs long history on-chain for each fraud proof
J
05:20
Josh
i think we discussed some kind of binary search for this
Z
05:20
Zack
yeah, truebit is like a binary search
J
05:20
Josh
we already had this discussion in a different context
Z
05:21
Zack
if you own some value in a sortition chain, you need to keep track of a lot of data to be able to enforce your ownership.
with waivers, this data that you need to store can be pruned a lot.
with normal signed txs, can we prune anything?
J
05:22
Josh
if we just use a validator, the validator can add himself to everyone, freeze the chain and he won't lose the insurance, so the insurance doesn't help with freezing
05:25
In reply to this message
how do you prove the waivers? don't you have to keep all of them?
Z
05:26
Zack
idk what "prove the waiver" means
05:26
oh, you mean "prune"?
05:26
or what?
05:27
if we have a waiver with a 10kb smart contract, and the final outcome says "Josh gave up ownership of this part of the sortition chain"
Then we might as well make another waiver that is only 100 bytes that says "Josh gave up ownership", and doesn't involve running a 10kb smart contract.
05:28
you don't lose anything by signing the shorter waiver, and once you sign it, then I don't need to store as much data to enforce ownership of my value.
J
05:29
Josh
In reply to this message
yeah prune, sorry
05:30
In reply to this message
ok, so pruning the contracts
05:31
can't you still do that if you're signing the ownership transfers?
Z
05:32
Zack
if there is a ownership transfer connected to a merkle root in block 1000, and it involves a long complicated smart contract, and the value ends up going to you instead of me.
we are doing a truebit fraud proof, so you need to provide the step of history from block 1000.

What exactly would the waiver look like so you don't have to show the signed tx from block 1000?
05:33
Maybe if the tx from block 1000 signed over the hash of the contract.
then we could prune the contract, as long as we both sign something saying how the contract would have run, if it were not pruned.
05:39
maybe the waiver strategy was a mistake. ill have to consider it more.
05:47
if anyone can act as a validator, then they could do a temporary data availability attack for 59 minutes, for every merkle root that they commit, and it doesn't cost them.
This could prevent anyone else who wants to act as a validator from processing txs during that time, because they don't know the current state.
05:48
if the merkle commitments are happening more frequently than every 59 minutes, maybe they could prevent anyone else from being a validator
J
05:54
Josh
but everybody would wait that long anyway, whether the data was available or not
05:54
and it costs them a huge security deposit
Z
06:04
Zack
maybe the validator doesn't need to verify any of the txs in this case.
They just include everything, and then provide merkle proofs after.

Checking which txs are valid could all happen during the fraud proof
06:06
so, to make a sortition tx, you would send the tx to a validator, and then afterwards you would request a proof to make sure it was included.

Because of the structure of the merkle tree, we could at least be sure that there txs from the same merkle root are not re-spending the same value more than once.
J
06:08
Josh
so anybody could request ownership transfer of my space but it wouldn't help them because they wouldn't have the fraud proof?
Z
06:08
Zack
if you don't sign it, then it isn't valid
J
06:09
Josh
right but it will still be in the merkle tree
Z
06:09
Zack
yeah. so it would be kind of like optimistic rollup.
the validators would just be for ordering history and making it available, then we do a fraud proof for the winning lottery ticket to find out who won
J
06:15
Josh
yep, of course none of that data goes on chain until the fraud proof
Z
06:15
Zack
if I make a tx that spends some value I do own, and also spends some value that I don't own. and the part that I did own ends up winning. in that case we would want this tx to be valid.

So that means validators wouldn't actually be checking the validity of the txs they are including. They would just include everything, and give merkle proofs to show it is all available.
06:16
oh, but what if I keep making invalid txs to spend someone else's money?
That could prevent them from spending their own money. because both txs can't be included in the same sortition root.
J
06:17
Josh
maybe they can, there could be a list of txs for each probability space
Z
06:17
Zack
if a tx needs to be valid for the entire space it is spending in order to be considered valid, then the truebit strategy doesn't work so well.
Because 1 tx could depend on 2 txs could depend on 4...
So pretty soon we would be putting the entire sortition chain history on-chain
J
06:17
Josh
this stuff is complicated
Z
06:26
Zack
I think if we did it this way, we don't need a fancy sortition tree.
We could use a normal accounts tree.
So if you make a payment, the location where it is stored is based on your pubkey.
06:27
Because checking that you actually own the value would all happen in the fraud proof step.
Z
07:08
Zack
As far as relative costs.
Pushing all this computation into the fraud proof will cost around log2 (number of txs in the history of the winning lottery ticket) times more per sortition chain. So consensus related fees per tx would be that many times higher.

But the advantage is the there is no validator who could cause it to freeze until the final-spend-tx. So we aren't bribing him to not-freeze us.
07:09
Bribing to not freeze is proportional to the interest rate on the money for the duration that it would get frozen for.
J
07:23
Josh
If n is the number of merkle roots published for the SC, isn't that O(log n)?
Z
07:31
Zack
idk what you are asking
Z
08:01
Zack
with the heavy fraud proof strategy, the cost increases with the number of txs. log2(# txs), but the amount of money doesn't matter. The time cost is log2(time)
(im assuming that in 2x more time, there are 2x more txs).

and with the validator strategy, the cost increases with the quantity of money in the sortition chain, and number of txs doesn't matter. the time cost is sqrt(time)
08:12
oh, the number of rounds of the fraud proof is log2(# txs), and the depth of each proof is log(# accounts)
Z
08:29
Zack
does our data availability solution even work without a validator though?
Having a different oracle on each merkle root sounds crazy
Z
10:21
Zack
I think the final-spend-tx idea does not work. It never did.

I even wasted time implementing it.

If the validator is pretending to be a user.
And then the validator puts another account of its own second in line.

And Bob wants to receive the final spend tx from the first pubkey without involving he second.

The problem, is that Bob can't know if the first one made a waiver or not.
10:26
but the ownership cycle idea does seem to work.

Maybe we should revisit the idea where the liquidator is one of the participants in every ownership cycle
10:27
or like, he is the first thing to come right after the ownership cycle. so if they all give up ownership, it goes to the liquidator
10:28
The reason we didn't like this plan, is because that liquidator has a monopoly on buying up all the lottery risk. So he can charge a lot.
10:29
maybe since it is a repeating game, that isn't so much of an issue?
Like, if the liquidator decides to over-charge us at the last minute, then we just wont hire him for any future sortition chains.
I guess it is vulnerable to a kind of retirement attack, and would have a mixed nash equilibrium.
10:35
so how about storing signed txs in sortition chain, and then doing the truebit fraud proof on it's history to make it short to verify the winner.
if we can do the oracle trick solve data availability issues, it seems like we don't need to use the final_spend_tx trick, right?
Z
11:15
Zack
oh, I think we still do the final_spend_tx. so it wasn't a waste to implement it.
What didn't work is the waiver strategy.
J
17:06
Josh
In reply to this message
Can you explain this plan in more detail?
Z
20:11
Zack
if we require signatures, then there is no priority queue to own parts of the probability space. one person just owns it outright. or a channel of people own it.

So that prevents the attack where the validator would put itself second in line.

So as long as we can use oracles to prevent data availability attacks, the final_spend_tx would work.
20:12
its too bad. waivers had a lot of cool properties in this context.
But it is good we finally realized not to waste time on them.
J
20:19
Josh
Do to instant transactions do we have to go back to regular channels?
Z
20:20
Zack
we can have N-party channels too
20:20
to help with liquidity issues
J
20:20
Josh
how does that work?
Z
20:20
Zack
to update the state of the contract, everyone needs to sign
J
20:21
Josh
ah
20:25
so going back to validators, maybe the dual oracle solution can work, you put up a security deposit that gets forfeited after 1 hour, and the SC get frozen after 2 hours. The security deposit pays for the freeze damage and for the oracles. I wonder if the insurer can sell the security deposit to someone else who is willing to wait for the oracle.
20:26
If you already posted a security deposit, you should be able to post more roots based on that deposit, since it already covers the costs of a freeze.
Z
20:54
Zack
once the deposit is forfeited, doesn't that mean there is no way to punish them in the subsequent merkle commitments?
20:55
do they need to make another deposit to make more commitments?
J
20:58
Josh
the deposit isn't actually forfeited until the oracle happens. so yeah, once they already know they paid the price what's stopping them from doing more damage?
21:00
there could be a smaller deposit that they have to keep on paying every time.
21:01
what damage would the do though? if they got close to the freeze timeout, people would just start freezing, but that's already paid for.
Z
21:01
Zack
I think we should try and figure out if it can work with a single assigned validator.
It just seems very difficult to allow for multiple.

But it would be nice if we could somehow prove whether letting anyone act as validator could or could not work.
21:01
so if the one validator attacks, then the sortition chain is frozen until the final_spend_tx
J
21:02
Josh
yeah it's always possible to do a freeze attack by witholding data but by then they've already paid for it
21:03
the advantage of multiple validators is there's more flexibility, you don't have to bake the validator in when you make the sortition chain so you're leaving it up to the market.
Z
21:10
Zack
I wonder if amoveo could even support 10 sortition chains. if we need to do a separate oracle for every on-chain commitment. the blocks will be so full
21:11
and if there are 2 oracles per commitment, it is even worse
J
21:12
Josh
they'll only be full if someone can afford to pay to make them full. you can always fill up blocks by posting random txs with high fees.
Z
21:12
Zack
if using a sortition chain requires filling up the blocks, then using a sortition chain means paying fees to fill up the blocks yes
J
21:14
Josh
that's not a cost of the sortition chain, it's a cost to the dumb validator who's paying high fees for nothing.
Z
21:14
Zack
what kind of light node software could possibly deal with this?
If anyone can post merkle roots, and any of them might have unavailable data.
so there are tons of alternative histories and forks to keep track of.
If you are not online during the hour when a root is posted, then maybe you will never get a merkle proof for that data, and the attack wont get punished
J
21:15
Josh
he can also fill up the blockchain by posting random hashes with those high fees.
Z
21:15
Zack
oracles are big txs. if we need 2 on chain oracles for every merkle root, it is a lot of on-chain data
21:16
if it is dumb to participate as a validator, then there wont be any sortition chains
J
21:16
Josh
it's not dumb to participate as a validator, it's dumb to be a validator, lose your insurance and not get anything in return.
Z
21:17
Zack
whether they break the rules and lose insurance or not, the amount of on-chain spam is about the same
21:17
oracles are big
J
21:17
Josh
if they don't break the rules, you don't need an oracle
Z
21:17
Zack
>>If you are not online during the hour when a root is posted, then maybe you will never get a merkle proof for that data, and the attack wont get punished
21:18
if you can't prove the entire history of your value, then you don't own it. you can't spend it
21:18
so what if there is a data availability attack more than 2 hours after the root is posted?
J
21:20
Josh
In reply to this message
you have to be online during those 2 hours to get the data.
Z
21:20
Zack
In reply to this message
oh, we only make the oracle if there is an attack
21:20
In reply to this message
so, you have to be online 24/7?
21:21
a sortition chain could have a payment at any time
21:21
they could post merkle roots at any hour of the day
21:21
to spend value, you need proofs of the entire history of the slice you own. not just the parts where you made payments.
J
21:21
Josh
yeah you have to be online 24/7
Z
21:22
Zack
that isn't a useful tool then
21:23
so, these long-range availability attacks, I think they apply more generally to every design of sortition chains we have looked at.
J
21:23
Josh
In reply to this message
i think that's a function of the merkle root availability problem
Z
21:23
Zack
im starting to think that we should stop working on sortition chains
21:23
it seems like we have shown that they cannot be useful
21:24
so, we should shink our time horizon for Amoveo, and try to make the P2P tool really solid, and syncing blocks in reverse order.
And once someone else solves the scalability problem, we will copy them rapidly.
21:25
if we can get everything else right, then maybe we still have a chance
21:26
or maybe now that we learned why this kind of sortition chain cannot work, we have the design constraints to come up with a scalability plan that could work.
J
21:27
Josh
maybe the best bet is to build amoveo without the advanced scaling and keep working on the theory in the background.
Z
21:27
Zack
yeah
J
21:27
Josh
we learned that it's very tricky so there's a high probability that any work done on implementation might have to be done over.
Z
21:27
Zack
im glad we realized this before I wrote more sortition software at least
21:28
imagine if we realized after it was already merged with a hard fork. haha
it would have made the code base a mess
J
21:28
Josh
yeah
21:28
we probably have a long time before we hit scaling issues in the real world
Z
21:29
Zack
tx fees are non-zero. so we already have scaling issues.
21:29
as long as the fee is non-zero, it is possible to undercut on cost.
J
21:29
Josh
if it's zero won't there be spam?
Z
21:30
Zack
yeah, it can't actually be zero
J
21:30
Josh
also it doesn't have to be zero, just cheaper than everybody else
Z
21:30
Zack
well, if it was infinitely scalable, then spam wouldn't matter
J
21:30
Josh
if someone else gets cheaper scaling, we can copy them
Z
21:30
Zack
if it was infinitely scalable, then would could fit an infinite amount of spam at zero cost to anyone
J
21:31
Josh
that's physically impossible
Z
21:31
Zack
yeah, being able to copy other people is going to be important here.
Amoveo's code base is still very adaptable, so I think we have a good shot.
21:32
In reply to this message
maybe it is.
But maybe if people could carry their own costs somehow, so it is like you are paying a fee by storing your own spam.
21:33
the point is that scalability is always important. there is no threshold when it will start to matter.
As long as the txs fees are non zero, that means there is some cost that can be reduced if we were more scalable.
21:33
All this sortition research was useful in that we will be more able to understand scalability tech once it does exist.
21:35
I wonder if we can come up with a proof of the limits of how much PoW consensus can possibly be scaled.
What if we live in a universe where it cannot be?
21:35
It seems like that would be something important to know.
J
21:38
Josh
In reply to this message
would definitely be helpful, then we wouldn't have to waste time on trying to come up with impossible ideas
21:39
although probabilistic ideas like sortition chains can sometimes practically solve impossible problems
21:39
maybe our biggest strength compared to other blockchains is being willing to give up on ideas that don't work
Z
21:41
Zack
haha
well, I wasted a lot more time on PoS than I did on sortition chains
21:42
yeah, probabilistic scaling seems like something that will be important somehow
21:43
at least with PoS, I was eventually able to show why it cannot work. so it didn't feel like a complete waste
J
21:45
Josh
In reply to this message
i was kind of joking, but if you look at bitcoin (LN) and ethereum (state) it could be their biggest problem, and most other coins are based on ideas that could never work
21:46
i wonder if being online all the time is as bad as we think; the thing about it is it's actually very cheap to do even though most people aren't currently doing it themselves
21:47
you can pay people to do it for you, you can pay insurance for damages
21:47
all that should be cheap
21:49
you can even use oracles to have people prove they're keeping your data over a longer term, like a month.
Z
21:49
Zack
yeah. being online all the time is a strategy that deserves more research. especially if you don't need to leave your private key online.
J
21:49
Josh
yeah, and you don't if it's just a data availability issue
21:55
lol, what if there was a 3rd oracle that asked if the validator kept the data available throughout the whole SC? even if he made the data available right away but it was unavailable later on, he'd lose his deposit.
21:55
but people would still be able to trade after 2 hours
Z
21:55
Zack
so, lets say you bought insurance from someone. the agreement is that they stay online 24/7 to collect the data that you need in order to spend your money.

So, if they don't provide this data, they can destroy all your money.

The the amount that they could lose from insurance is smaller than your money, it is a level 3 vulnerability and doesn't work.
if the amount that they could lose from insurance is bigger than your money, then the lockup costs of liquidity make it cost prohibitive.
21:57
In reply to this message
we could punish the validator for failing to keep historical data available. but the amount of value lost to people being forced to hold lottery risk is much bigger than whatever punishment we can put on the validator.
J
21:57
Josh
In reply to this message
yeah but they can't force you to lose your value since you can hire someone else at the same time
Z
21:58
Zack
that is a PoS mechanism.
The different people you hire can cooperate to attack you.
J
21:58
Josh
they don't know if you're online when they're trying to attack you
21:59
they have to be certain that there's no way you can be online during the attack and that they've bribed anybody you could have hired
Z
22:01
Zack
so if you are online P portion of the time, and the ratio of (insurance payout)/(value you own) < P, that seems like it might work.
But if you are going to be online >1/2 the time anyway, why not just be online 24/7?

Is this just for power outages?
22:01
if the people you hired realize that there is a power outage or whatever in your area, they could take advantage of that
Z
22:42
Zack
if it isn't possible to have a single scalable currency, maybe there will be like, a hierarchy.
with lots of small cheap local currencies, and one big expensive global currency.
J
22:42
Josh
In reply to this message
yeah that's a problem, there are a lot of potential pitfalls
Z
22:43
Zack
if a single scalable blockchain isn't possible, then things like merged mining might be more important, right?
J
22:43
Josh
but i think it would pretty hard for them to guarantee that you're not hiring someone honest
Z
22:43
Zack
In reply to this message
they can use smart contracts to cooperate in the attack.
J
22:43
Josh
if they can do an eclipse attack on you, then basically all blockchains fail
Z
22:44
Zack
so if one attacker double-crosses the other, he loses a big safety deposit
22:44
idk "eclipse attack"
J
22:44
Josh
In reply to this message
didn't you say that merged mining doesn't work?
Z
22:45
Zack
i don't remember. I haven't thought of merged mining in a long time
22:45
when your attacker can decide which messages you get from the internet
Z
22:46
Zack
oh, like if all your peers are controlled by the attacker
22:46
it is pretty cheap to check with lots of peers if they have more headers than you
22:48
In reply to this message
the attack is that they're controlling your connection so you can only get data they want you to get
22:49
i think it would be pretty hard to guarantee that i'd be offline for an hour, and even then you'd have to make sure i don't get data that lots of people could have already downloaded
22:50
the more the data is worth, the more resources i have to be online myself
22:50
it's still tricky, lots of issues but i'm not convinced it can't work
Z
22:54
Zack
In reply to this message
drivechain is not the same thing as merged mining
22:54
I think the problem with merged mining is that the bitcoin miners don't have much incentive to protect the other blockchain. It isn't expensive to bribe them to break it.
So yeah, I guess the vulnerability is similar to drivechain
22:57
maybe optimistic rollup is going to be our best scalability strategy
J
23:00
Josh
optimistic rollup means that the nodes have to store all the data but they don't have to process it?
Z
23:04
Zack
right
23:05
they don't verify that anything of the txs are valid
23:06
so they are just making a bunch of data available.
We could stick all the sortition txs into the OR rollup, and then everyone would be able to look up the proof that shows that they own what they own.
J
23:13
Josh
how is the data indexed?
Z
23:16
Zack
OR makes a long list of bytes available, and it has a couple other simple tools to allow you to merklize the data.

You can have a pointer+256 bits next to each other, and it verifies that the pointer points to somewhere else in the OR data in the same block where it is storing the same 256 bits.

you can have a block of contiguous data followed by 256 bits, and the 256 bits are the hash of that data.

I think maybe they can do some other things too.

The idea is that a light node should be able to do something like log2(size of block) lookups on chunks of data from the block in order to get whatever info they needed from that block.
J
23:18
Josh
so we'd have to figure out a design in the context of looking up proofs for the sortition chain
Z
23:19
Zack
yeah, i think id need to learn more about OR to be completely sure how to apply it
J
23:19
Josh
would we need truebit style proofs?
Z
23:20
Zack
OR is just making the data available, so yes we would use something like the truebit fraud proof when someone is saying that they won the lottery
J
23:20
Josh
yeah
23:21
it might get rid of the thorniest problem, which was the data availability problem of the merkle root
23:22
i guess the bottleneck is indexing speed for the OR
23:22
it will also be important to prune so that we can sync quickly
Z
23:27
Zack
maybe it would be more important to add N-party channels to level 1 amoveo. to help with liquidity issues in the lightning network
23:30
does it make sense to put the entire sortition chain, on the main chain?
as a way to save liquidity in smart contracts. so you could have a channel denominated in stablecoin for example.
As like a compromise between having on-chain smart contracts and only having state channels.

We can keep the contracts off-chain until the fraud proof stage at the end.
23:32
A big part of our motivation in researching sortition chains was to solve the liquidity problem with amoveo markets.
Even if sortition chains aren't very useful for scalability, it would be nice if we could still use them for the liquidity problem.
23:34
the lottery aspect of sortition chains means only a small fraction of our smart contracts ever end up on the main chain, and lets us prune almost everything.
23:36
any historical tx that didn't contain a winning lottery ticket could be pruned
23:40
And the full nodes don't actually need to store the sortition contracts, because it is stateless. every block would have merkle proofs so we can know whether a an update is authorized.
23:44
so baby sortition chains wouldn't be possible.
the blockchain is basically acting as the validator.
23:44
it is like, a generalization of state channels
23:45
maybe the lottery aspect doesn't make sense, and it should just be an eternal data structure. like the accounts tree, but with bits of smart contract mixed into the merkle nodes
J
23:50
Josh
you might still be able to get pruning advantages if there are expiration dates on the data but we'd have to make sure the data isn't needed
Z
23:51
Zack
i don't know about that.
23:52
like, if I owned some money 1000 blocks ago, and then spent it so I don't have any left.
You can't just delete those 2 txs from history. people need them to verify the blocks are correct.
23:52
they need both txs to figure out where the money went next
23:52
and that it came from somewhere
J
23:53
Josh
yeah that's the advantage of the SC
K
23:54
K
In reply to this message
Have you written a paper on increasing blocksizes are a scaling solution?
J
23:54
Josh
maybe checkpoints can help with the indexing problem
23:55
but synching can quickly become the bottleneck if we don't prune
23:56
the cost of staying in sync is important too
13 May 2020
J
00:01
Josh
Right but even if a small node can stay in sync, without pruning or checkpoints they might not be able to ever catch up to the main chain when syncing from scratch
00:01
you can see this with raspberry pi's and bitcoin
K
00:01
K
In reply to this message
Have you check out https://codaprotocol.com/
00:02
uses zk snarks to keep the blockchain at very, very small size no matter the TPS
00:03
They fucked up by using PoS and distributing their coins via an ICO so if their tech is useful, Amoveo will still be unique in that it's coins are distributed by PoW
Z
00:12
Zack
In reply to this message
according to section 4 of their white paper, you need to hold a copy of the entire current state.
coda is only compressing history.

We already achieve this level of saving by using headers and statelessness, and we don't have to rely on any risky crypto.
So, instead of 10 mb of headers, this design has 1 mb of zk snarks proofs.
I have a feeling he still needs the 10 mb of headers anyway though.
and this seems to be limited to only transfering money around, because I think it is a kind of mimble wimble. it is encoding values into pederson commitments.

Amoveo is for derivatives contracts, not just spending value.
00:19
In reply to this message
the way to think of it is that there is some ratio between the cost of staying in sync, and the cost of coming into sync.
If it costs twice as much to stay in sync, then that means a node which can barely stay in sync, if the blockchain is 100 days old, it would need 66 days to get into sync, and the blockchain will be 166 days old once it is in sync.
00:19
with amoveo's stateless design, if we don't use OR, you can sync blocks in reverse order. so your node is operational as soon as it has the headers.
00:20
which can be within 5 seconds on a well connected node.
J
00:27
Josh
does OR stop us from syncing in reverse order?
Z
00:28
Zack
we at least need all the OR stuff that recent blocks could need to look at
00:28
I don't completely understand how OR works. like, what does an OR light node do exactly?
J
00:31
Josh
isn't it about full nodes, not light nodes? light nodes would ask full nodes for data that they need.
Z
00:32
Zack
the full nodes need to be designed in a way so that light nodes are possible.
00:32
it is a major constraint
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
02:36
Zack
what is nice about the sortition database, is that we can divide value up not only along probability space, but also between contracts.

It is kind of like how you can lock up eth to make augur-coins to bet on the true and false possibilities.

That way the operator of a market for trading the true and false outcomes, they don't need to have as much money locked in channels.
plenyun invited plenyun
J
03:39
Josh
Doesn't that depend on the outcome of the contract, not the RNG?
Aviel Gubat invited Aviel Gubat
Z
05:18
Zack
In reply to this message
if one of the accounts ends up with zero money, then we can prune it's history.
Doesn't matter if it has zero because it lost RNG, or because it lost a contract.
J
05:21
Josh
But even without sortition chains, can't we still prune the history if the account goes to zero?
Z
05:49
Zack
no.
We can prune lottery tickets which are eventually worth zero, because the entire path they took was worth zero, so that history doesn't matter.

If an account goes to zero, but it was previously holding real money with real value that it spent to someone else. We would need to remember the history where it was holding value.
05:49
it kind of depends on the security model though.
Once we are syncing blocks backwards, maybe we can just stop caring about early blocks.
05:50
hard code a header into the code base and forget the blocks from before then.
J
05:53
Josh
that's what i meant about checkpoints
Z
05:53
Zack
it isn't activated yet, but we do have code for checkpoints and syncing in reverse
05:54
so the benefit of the lottery mechanism would be that we can have N smart contracts, but only need to execute log2(N) of them on-chain.
05:55
the rest are just referenced by the hash of their contents, and never go on-chain
Z
06:43
Zack
Since sortition chains only make the smart contracts scalable, I wonder how much stuff we can push into the smart contract layer.
Deleted invited Deleted Account
Deleted invited Deleted Account
AK
18:11
Anna Karimova
Hi, everybody. I'd like to talk to the right person about the listing of this project. If you're interested, please let me know.
B
18:23
Ben
list it for free or move on. nobody will pay you a dime
Mimo Bakir invited Mimo Bakir
Z
21:05
Zack
In reply to this message
Even better. If N contracts are still active at the end, we only execute log2 (N)
21:07
Normally a spend involved proving the value in 2 different accounts.
But spending some sortition value would only require looking up one thing.

If each block focused on a single one of the sortition chains, then a lot of the proofs would be overlapping, so that would make it smaller than normal spends as well.
J
21:08
Josh
I feel like we're going in between trying to guarantee data availability with a tx fee to guaranteeing it with the entire blockchain. We should probably make sure we understand how much it's worth to ensure it and what the risks are.
21:08
We also realized that we can manage data availability with an oracle, that seems like a big deal.
Z
21:09
Zack
In reply to this message
I'm not sure that works.
J
21:09
Josh
In reply to this message
You mean each block of the blockchain could only have txs from one SC?
Z
21:09
Zack
Data availability is important until the user comes back online. Not just for the hour after the data is first made
21:10
In reply to this message
Yes.
That way we only need one merkle proof from the sortition chains tree.
So it wouldn't use much space in the block.
J
21:10
Josh
That's true but at least we can determine whether there was an attack or not.
21:11
In reply to this message
So what else would be in the block?
Z
21:12
Zack
If you want to spend a chunk of probabilistic value, you make a tx with a proof showing that you own it, and say the pubkey of who you want it to go to next
21:13
I wonder how mining pools would feel about probabilistic fees
21:15
I think this strategy could make the txs a lot smaller, so we could fit 2x or 4x more per block, and it could give us on-chain smart contracts for practically free.
If there are N active contracts when a sortition chain ends, only log2(n) are run on-chain.
J
21:15
Josh
they already have probabilistic fees 😛
21:17
In reply to this message
if there's a merkle root, how do we get around the data availability problem?
21:21
i think it's pretty dangerous to have a design where someone can block someone else without their signature. then we need a ton of complexity to try to guard against that.
Z
21:33
Zack
In reply to this message
I don't see any data availability problem.
21:33
In reply to this message
I don't see how anyone could get blocked.
21:34
The sortition trees would be on chain.
We keep them merklized so that they can be proved to light nodes, and so it is compatible with the stateless full node model we are using
J
21:40
Josh
In reply to this message
ok, didn't get that part
21:42
there's a lot of new details here, I think i'll understand it better when you write up the whole plan
Z
21:52
Zack
normal channels can be expensive. the smart contract might need to go on-chain.

A sortition chain is like mixing a bunch of channels together, so they all get settled at once, and only one person wins the entire lottery.
This way only a small fraction of the contracts ever go on-chain.
21:53
a normal channel has some delay programmed in. like 2 days. so if you want to end the channel, and your partner isn't cooperating, it takes 2 days to get your money out.

With a sortition chain, everything has the same expiration date together. when the RNG is calculated.
21:53
it probaly doesn't make sense to call it a "chain" now
21:54
maybe "sortition contracts"
21:54
or we could go with the name bitcoiners are using "channel factory"
J
21:56
Josh
why do only log n contracts go on chain?
Z
21:57
Zack
once the RNG is done, then we know which lottery ticket won. everything else is worth zero.
21:57
so someone posts the smart contract code to show that they control the winning lottery ticket, and every other smart contract does not matter.
J
21:58
Josh
but don't they have to prove all the contracts that they did during the SC?
Z
21:58
Zack
Normal channels aren't actually a scalability improvement, because the cost of enforcement is as much as an on-chain tx.
But this kind of channel would be a scalability improvement, because the expected cost of enforcement is (an on-chain tx) * (probability that you win the lottery)
21:58
In reply to this message
no. they only do the ones that are active in the final state of the lottery
22:00
the settlement could still work as a fraud proof. that way we only need to post one smart contract on chain at a time, not all at once.
22:07
so, the cost of making a transfer would be made up of these smaller costs:
1) starting from the consensus state root, prove the current root of the sortition chain you care about.
2) starting from the sortition chain root, prove the current sortition contract you want to spend.
3) you sign over this tx, and it is valid for the pubkey currently stored in the contract. ~64 bytes
4) you write the pubkey of the new owner. ~64 bytes
5) you need to specify the slice of probabilistic value space being transfered. ~64 bytes, + 32 bytes for every smart contract.

cost (1) can be eliminated as long as someone else is making a transfer in the same sortition block as you.
cost (2) can be mostly eliminated as long as someone else is transfering a part of the sortition value that is located nearby to the part that you want to transfer.

So we are looking at something like 300 bytes per on-chain tx, even if it includes arbitrarily long smart contracts.
22:08
and on-chain, we would mostly just be forming and ending channel relationships.
We could use lightning paths for most stuff.
22:09
channels are expensive because your partner can force you to put it on-chain.
if we embed channels in this sortition structure, then this cost is gone. they can't force you to put it on-chain.
22:11
Basically, everything is the same as the sortition chains we were discussing before. Except we would use the main blockchain as the validator, and we couldn't embed baby sortition chains.
22:13
oh, I guess the problem with this design is that if your partner wont let you close a channel, you could be stuck holding lottery risk.
22:15
I suppose that was also a problem in the off-chain version of the sortition chains, and we hadn't realized.
22:18
oh right. we solved that by requiring them to post a hashlock secret on-chain before a certain height.
22:18
that way exactly one person could own the channel before it ends, so it is transferable for them
22:23
so we wouldn't directly encode channels into the sortition tree.
Rather, those smart contracts embedded in the sortition tree, they would check whether certain secrets had been revealed on-chain before certain block heights, and distribute value accordingly.
So that allows us to transfer value off-chain by revealing secrets to each other. and we could do atomic swaps.
22:24
a contract that checks whether N secrets have been revealed, it could divide up some value in 2^N parts.
22:25
I guess it would only support one-way channels
Deleted invited Deleted Account
Z
22:26
Zack
if a channel can only do a single payment once, it doesn't seem very useful.
22:27
so maybe it is better to go back to the plan where when a sortition tree finalizes, it chooses a winning channel to put on-chain, and then we can enforce that channel like a normal channel.
22:28
oh, they can still force you to hold lottery risk.
22:33
so, how about if the channels have expiration dates before the sortition chain.
So you can enforce the channel ahead?

Then you would have the option of either paying a tx fee to run the contract on-chain and enforce the correct outcome of your channel, or else you can choose to play the lottery instead and not have to pay the fee.
22:42
So channels might not work well in the sortition tree.
But we can connect sortition contracts together so they update atomically, to enforce single price batches in markets.
22:43
As long as the batch prices are recorded to consensus state.
14 May 2020
Deleted invited Deleted Account
Z
00:43
Zack
This is a place to talk about Amoveo.
Deleted invited Deleted Account
Raj Put invited Raj Put
Elfajar Sudirman invited Elfajar Sudirman
Deleted invited Deleted Account
Radick Ardhiles invited Radick Ardhiles
J
01:01
Josh
i guess channels might still be useful for instant payments but you'd have to pay a premium for that since you're paying the other side to lock up funds and they can freeze your funds for a while
01:02
In reply to this message
Maybe it's best to focus on this and make sure blockchain validation for this case is as cheap as possible.
Thang Le invited Thang Le
효준 주 invited 효준 주
Deleted invited Deleted Account
Deleted invited Deleted Account
Truong Van Dung invited Truong Van Dung
J
05:28
Josh
Is there a post on how the single price batch markets work with sortition contracts?
J
05:29
Josh
thanks
J
05:56
Josh
still worth thinking about whether requiring everyone to stay online or have online agents for a whole sortition contract is worth the big scalability advantages
Deleted invited Deleted Account
Z
09:11
Zack
the reason I think we need something like sortition chains, even though it isn't providing scalability, is because it solves liquidity issues in these markets with single price batches.
Maybe we can remove even more complications from the design.
Pritam invited Pritam
Kadir invited Kadir
J
18:06
Josh
In reply to this message
How does it solve liquidity issues vs regular on-chain contracts?
Z
19:31
Zack
we don't want to have on-chain contracts with shared mutible state, because that is an anti-scalability feature. Our options are to either do it with sortition chains, or to do it with state channels.

Lets say Alice and Bob want to bet on whether a R or D will win the presidential election.

So it starts with Alice and Bob each having $10, and at the end, Alice can win $20 if a R wins, and Bob can win $20 if a D wins.

Charlie is the market maker.
With channels, the process is like this:
Charlie locks $10 in a channel with Alice, that channel has $20 in total, so Alice can win $20.
Charlie locks $10 in a channel with Bob. that channel has $20 in total, so Bob can win $20.

charlie simultaneously activates the bets in both channels.
Then over the next several blocks, Alice and Bob make a direct channel together containing $20. And the 2-step lightning bet is moved to the direct channel path, which unlocks Charlie's $20.
Alice and Bob need to be online at the same time and cooperate for this to happen.
If Alice or Bob want to re-sell their bets, they either need to lock up more liquidity and do a hedge, or else they both need to be online and cooperating to move the bet to different channels.

with a sortition chain, it is like this:
Charlie has $20. he splits it up into $20 or R-money, and $20 of D-money.
He simultaneously sells the $20 of R money for $10, and the $20 of D money for $10.
Everyone has what they want, they don't need to stay online or make more txs. Bob and Alice can re-sell their bets without each other's permission and without needing to lock up more liquidity.
Deleted invited Deleted Account
J
20:47
Josh
Thanks, great explanation.
20:49
How does Charlie split up the $20 into $20R and $20D? He's allowed to do this because the bets are mutually exclusive? What part of the SC mechanism allows him to do this? Does it require the RNG?
20:50
Does this example assume that Charlie thinks the odds of R vs D are 50/50?
20:54
on the scalability side, we really need to look at bottlenecks; apparently ed25519 can be 50-100x faster than ecdsa and it's possible that with GPUs things could get even faster.
Z
20:55
Zack
In reply to this message
the nodes of the sortition merkle tree have smart contracts. these contracts can reference the RNG, or oracles, or do anything.
20:56
In reply to this message
no. just that Alice and Bob happened to trade at that price later.
21:00
The savings are more extreme in the case where there are more possible outcomes.
Like if we are betting on:
R + war
R + no war
D + war
D + no war
so people could find out who to vote for to either cause or prevent war.

With state channels, if 4 different users each wanted to bet $10 and have the potential to win $40, we would need to lock $40 into 4 different channels, so a total liquidity of $160 is locked up.

But with sortition chains, the market maker could divide up $40 into RW, RNW, DW, and DNW types, and sell each of the 4 types for $10.
21:01
Betting with more than 2 possible outcomes is how we do futarchy, so it is an important use-case to get right.
J
21:03
Josh
In reply to this message
So why is the RNG part required for this?
Z
21:04
Zack
that way only a small fraction of the smart contracts ever need to go on-chain.
J
21:04
Josh
is that a scaling benefit or a liquidity benefit?
Z
21:04
Zack
depends what you are comparing against
21:05
you can only "benefit" if there is some other case to compare with
J
21:05
Josh
is there a way to get the liquidity benefit vs channels without RNG?
Z
21:06
Zack
you could have on-chain smart contracts with shared mutible state, like ethereum
21:07
but that isn't scalable.
21:07
there is no cost to using the RNG here, and only benefits. we can prune a lot of history.
J
21:08
Josh
there's a cost in having to be online before it ends and sell my lottery risk
21:10
the part I haven't understood yet is how the RNG solves the shared mutable state issue
Z
21:10
Zack
channels don't have shared mutible state. you don't need RNG for that.
21:11
you understand how an ethereum subcurrency for betting on R-shares, if someone new buys some R-shares, there is an on-chain contract that is updated to store your account and balance in the subcurrency, right?
21:12
so the old contract state where you didn't have the R-subcurrency, it mutated into the new state where you do.
21:13
everyone needs to synchronize the new version of the state to participate in the contract
J
21:13
Josh
yep
21:14
with the channel nobody on-chain cares what happens in the channel until it closes
Z
21:15
Zack
every version of the channel state that we sign is immutable. we can make a new contract state to replace the old one.
21:19
with sortition chains, to execute a batch, the market maker publishes a signed batch price.
None of the sortition contracts mutate, but how they would execute is now different. because we have more evidence available for them.
21:23
the signed batch price also doesn't mutate. it is shared immutable data.
J
21:24
Josh
why can't we have the same idea of charlie creating a new chain, dividing up $40 between RW, RNW, DW, and DNW but without doing the lottery at the end?
Z
21:24
Zack
you could divide up 100% of the value in the sortition tree between those 4 possibilities yes
J
21:27
Josh
i'm not saying that's a better solution, just trying to understand the different mechanisms and tradeoffs
Z
21:29
Zack
but consider if whoever owns RW wants to sell a fraction of the RW to someone else.
If we have RNG, then there is clear rules about if and when the contract would need to go on-chain, so everyone will be able to know who has how much money, and we don't need to keep a copy of the smart contract around any more.

Like, if a republican won, and there was war, that would mean the RW shares are worth as much as normal VEO, and the others are worthless.

We don't want the owner of the RW shares to need to forever keep a copy of the smart contract to prove to everyone that the RW shares are worth as much as VEO.
We want the RW shares to be converted into normal VEO that are fungible with all the other normal VEO.
21:31
imagine if the RW shares got sold and resold, so now they are distributed among 10k different people.
We can't have a single tx end the RW contract and pay out to 10k different people, that tx would be too big to fit in a block.
21:32
another possibility is if each person comes on and runs the contract individually to convert their RW into VEO. So then the contract would need to maintain a shared mutable accounts database of everyone who owns RW, like a subcurrency.
21:34
I guess it really isn't so different from everyone coming online to swap their RW for veo with a liquidator.

But at least if we use RNG, we can prune most of it from history.
21:37
if the swapping of RW for veo is swaping from one sortition tree into another sortition tree that has a later expiration date, we can prune the txs on both sides of the swap
J
21:38
Josh
In reply to this message
Is this with or without RNG?
Z
21:39
Zack
sortition trees have rng.
21:39
pruning requires rng
J
21:40
Josh
ok and pruning buys us faster syncing speed and less long term storage, right?
21:41
does it affect what we need to hold in memory?
Z
21:42
Zack
we can get similar syncing speed and storage benefits by using a checkpoint and ignoring early blocks.
But if we use RNG to prune instead, then we can maintain a better security model.
21:42
In reply to this message
who is "we"? what is "what"?
21:43
are you talking about a full node? a light node? a market maker? a trader?
J
21:43
Josh
"we" is nodes and miners, "what" is whatever needs to be in memory to validate a block
Z
21:43
Zack
oh, you mean full nodes
J
21:43
Josh
yeah
21:44
In reply to this message
this is what i was getting at
Z
21:44
Zack
if less smart contracts get stored or executed on-chain, then that saves memory.
21:45
if a sortition tree contains the hash of a contract, and that contract doesn't win the RNG, then that contract never needs to get posted on-chain
21:46
so we save on however many bytes of storage long that contract would have been. and we save however many CPU cycles it would have taken to execute it.
21:47
so, the miners would almost never execute any smart contract. they would just be inserting things into merkle trees a lot.
And then eventually they can prune almost the entire merkle tree, once the RNG is calculated
J
21:48
Josh
ok this sounds pretty compelling, even with the on-chain ownership transfers
Z
21:48
Zack
it is nice for privacy if the smart contracts can stay off-chain most of the time
21:49
if your branch of the sortition tree loses the RNG, then you don't need to create any of the oracles that would have been needed to execute your contracts
21:50
withdrawing winnings from the sortition tree can be done with fraud proofs. So you usually don't need to publish any of the contracts that you won either.
Only if someone challenges you to publish one of them.
J
21:55
Josh
so there are no waivers anymore, just on-chain ownership transfers?
Z
21:55
Zack
right
J
21:56
Josh
and those on-chain ownership transfers contain a hash of the contract?
Z
21:56
Zack
if the same person owns adjacent chunks of the sortition tree, they can combine them
21:56
so, if you own both sides of a contract, then you can shrink the tree and get rid of that contract
21:57
if you bet on a contract, it divides a leaf of the tree into 2 sub-leafs that own either side of the contract
21:57
and the parent node of those 2 leaves contains the contract's hash
21:58
so, if the RNG decides that this node has won, then the contract determines which of the 2 leaves wins
J
22:00
Josh
if everyone sells their value to one liquidator before the end of the SC, he should be able to collapse all the contracts
Z
22:00
Zack
he could
22:01
but it will all get pruned anyway
22:01
if he owns it all, then no one will challenge his claim of ownership. no one will make him post fraud proof evidence.
22:02
maybe fraud proofs aren't the right choice here. it might make it harder to maintain our security model while pruning.
J
22:03
Josh
they can still challenge him, even if they lose
22:05
if he collapses everything, we don't need fraud proofs, right?
Z
22:14
Zack
if he collapses everything, we can't benefit from fraud proofs.
22:17
if he collapses everything, we can't prune anything.
22:17
collapsing everything is basically the same as paying to spam the network with junk data.
J
23:54
Josh
when a liquidator buys up people's contracts, if he doesn't want to hold betting risk does he have to buy both sides equally?
Z
23:57
Zack
At that point the bets should already be settled
23:58
If the sortition tree is about to end
23:58
He only needs to buy the side of the bet that could win the lottery
23:58
But maybe both sides have non-zero value
23:59
Like a stablecoin contract
15 May 2020
J
00:01
Josh
shouldn't the contract specify a date for the price that's before the end of the SC?
Z
00:01
Zack
Right
J
00:01
Josh
so theyn it shouldn't really move after that date
Z
00:19
Zack
yeah. the contract stops mattering, and they just become like, piles of probabilistic veo.
00:30
If different blocks focus on different sortition trees, then we don't need to include as many merkle proofs per block. So in that way, each sortition tree is like a shard.
It is compatible with the stateless full node strategy.
It is compatible with syncing in reverse.

I guess the bottleneck will be the 2 pubkeys and a signature on each of the txs.


Since almost none of the smart contracts end up on-chain, we should try to push as much activity to that layer as we can.
J
00:33
Josh
doesn't that limit the number of active sortition chains we can have?
Z
00:34
Zack
it is the same way with accounts. if you reference 2 accounts that are near each other in the accounts tree, it saves space because part of the merkle proof overlaps.
00:37
each sortition tree is a merkle tree, so if you are using the same part, it saves space.

But also, all the sortition trees are part of a bigger tree that works similar to the accounts tree.
So if you reference the same sortition tree multiple times, or if you reference different ones that are near to each other, it saves space.
00:37
eventually, miners will probably adjust the fees for different txs to take advantage of these savings .
00:37
to pass on the savings to the users
J
00:46
Josh
makes sense
T
00:50
Tromp
Zack if a stable coin uses an oracle for keeping the price stable compared to an outside value, how secure is it if they use amoveo compared to chainlink?
T
01:15
Tromp
If they wete to use Amoveo is the project ready for that
Z
01:16
Zack
we are ready
T
01:36
Tromp
👍🏻👍🏻
J
04:26
Josh
So let's walk through this. It starts when Charlie starts a new sortition chain with 100 veo. Now he wants to split it up into 4 mutually exclusive contracts, RW, RNW, DW, and DNW. How does he do that, and how does the market work with Alice and Bob? Is he referencing oracles that might only be created after the SC completes?
Z
04:31
Zack
he could do the R-D split first.
Then split each of those leaves between W and NW.
So now there are 4.
then when alice makes a contract to buy RW for example, the contract has in it a limit price, for the most Alice is willing to pay, and it references the batch price, which has not yet been published.
If the batch price is below how much Alice is willing to pay, then the trade executes

Other people would have contracts to buy RNW, DW etc, each with different limit prices and batch prices.

the people are paying for these with probabilistic value from other sortition trees, or from elsewhere in the same sortiiton tree.
The same batch price that causes them to receive RW, also causes them to pay the correct amount for it.
J
04:50
Josh
So Charlie does an ownership transfer of 40 veo for Alice, and it activates based on a contract that returns true if there's a signed message from Charlie that the price is under 10 veo and if referenced oracles return the answers that the democrats won and there was a war; this is atomically linked with an ownership transfer from Alice of 10 veo with a contract that returns true with a signed message from Charlie that the price is under 10 veo. How much of that is right? There also needs to be a payment of 10 veo to Alice if she can provide double spends of signed prices.
Z
04:55
Zack
you don't get paid for providing evidence.
If anyone can show that Charlie signed 2 conflicting batch prices, then Charlie loses all his inventory, and doesn't get paid.
limit orders in channels is here https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md
doing it with sortition chains is the same thing.
04:56
oh, right, we had been using the extra liqudity stuck in channels to punish the market maker if they tried to double sign
04:57
I guess the payment to the market maker could be locked up until they publish the batch price, so we can enforce it the same way as channels.
04:57
oh, it needs to be locked up anyway, until we know how high the price is
04:57
so yeah, it works the same as channels
05:05
Sortition contracts don't get executed until much later. So there might be some data availability issues in letting the market maker sign off-chain batch priced.
05:06
Using the Oracle for prices would work great though.
Since it could be inside the contract, so it probably would never need to be executed
05:06
For futarchy, we really need to run out own markets, and discover our own prices.
So we need some way to do these batches.
J
05:08
Josh
the date for the facts the oracles are deciding on is slightly before the SC ends; everybody trades out their value to the liquidator and then the SC gets finalized; but the liquidator doesn't want to own any value that's conditional on an oracle unless he's 100% sure that the oracle will give a true answer because that piece of value might win the whole lottery; if the oracle returns an answer that voids the contract he loses the whole lottery.
05:11
In reply to this message
yeah, this sounds like a similar issue to the final spend problem; contracts that don't win the lotter don't go on chain so you won't have proof of double spend; contracts that do win the lottery aren't much of a punishment for the liquidator because it's just a tiny fraction
Z
05:12
Zack
So he can publish it with a proof of existence
J
05:13
Josh
i didn't understand that
Z
05:13
Zack
The proof of existence tx type.
05:13
So we know when he published the batch
05:15
Maybe we need to modify it a bit to prevent him being able to publish 2 conflicting batches.
Like if the key is a combo of his pubkey and the batch height and sortition ID
05:21
We could probably encode that rule in the smart contract
J
05:25
Josh
In reply to this message
oh, this isn't true, because each part of the probabilistic value is divided up among all the contract outcome states, so whatever probabilistic value wins, the liquidator will have value activated by that oracle outcome.
05:25
so he'll run the oracle and cash in whichever contract wins
Z
05:26
Zack
He knows the Oracle outcome before actually launching it
J
05:26
Josh
he knows a probability but it might only be 90%
Z
05:27
Zack
What?
If we are betting on whether a Democrat wins the election
05:27
The Oracle expires only after we know who won
05:28
If we don't know how the Oracle should end, then we couldn't run it. Because we couldn't report the outcome to it
J
05:28
Josh
say you're betting on who wins some event in the olympics and that person won, then 2 weeks later they get disqualified because they used drugs
05:29
or there's some challenge about voting booths in the election
Z
05:30
Zack
As long as it is nearest to the leaves, it doesn't matter.

Are you going to use shares from betting on the Olympics to price some other smart contract?
J
05:33
Josh
it's just an example, there can always be challenges about an outcome
Z
05:41
Zack
The smart contract can be programmed to realize that the Oracle didn't finalize, and act accordingly
05:42
It could treat it like a bad-question outcome
J
05:47
Josh
i think there's always some risk that the oracle doesn't end the way you expected it to
05:47
i don't think that's a problem though
Z
06:18
Zack
We have a channel in discord for price talk. This is not the right place for that.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
22:24
Zack
Thanks Mr flintstone
mx
22:25
mr x
What u think of quadratic voting?
22:25
Just voting imo
Z
22:25
Zack
Futarchy is a better way to make decisions
mx
22:25
mr x
right
Z
22:25
Zack
Identity is vulnerable to sybil
mx
22:25
mr x
yup
22:36
also who control what issues gets voted on hmm
Z
22:36
Zack
Anyone can ask amoveo futarchy questions
mx
22:37
mr x
yeah
22:43
404
Z
22:44
Zack
Where did you see this link?
Z
22:45
Zack
Got it. Thanks
Z
22:55
Zack
Yeah, we were just talking about that
X
22:57
X | NPC
oh, I've just seen the post...haha
Z
22:58
Zack
It's a good thing to share here
J
23:01
Josh
he's slowly figuring it out
23:02
since we're doing everything on-chain, maybe the market maker price double spend should be enforced by the blockchain
Z
23:03
Zack
Everything is enforced by the blockchain.
J
23:03
Josh
i mean the miners won't accept double spends of the batch price
23:04
instead of it being just a proof of existence tx
Z
23:05
Zack
Yeah. We just set it up so the proof of existence key is uniquely defined for each batch.
J
23:22
Josh
ok, so MM splits up 100 veo of probabilistic value into D and R; D contract returns true if: (1) oracle decides D; (2) RNG falls within prob. range; (3) there is a signed price from MM for batch X where limit < Y; (4) an atomic swap secret matches a hash. MM does an on-chain ownership transfer with A, which is atomically swapped with an ownership transfer from A to MM; this ownership transfer has a contract which returns true if: (1) there is a signed price from MM for batch X where limit < Y; (2) an atomic swap secret matches a hash. After the ownership transfers are confirmed, the secret is published; then MM publishes the price; if the price was < Y (the limit) A can now sell the value of D to other players.
23:36
Seems like you need an on-chain tx for each limit order, even if it fails.
16 May 2020
Z
00:15
Zack
It gets complicated if you try to describe it all at once.
00:16
Better to consider atomic updates and limit orders and batch trading all individually.
00:17
With channels we would need an on chain tx to make the chanel, and one to close it too. Even if the trade doesn't get matched in the batch
J
00:35
Josh
another issue is the market maker has to decide on a price and publish it but he doesn't know when it will be confirmed on the blockchain; if facts change about what the price should be there might be incentive to bribe miners to censor the tx.
Z
00:37
Zack
I guess the limit order document wasn't clear.

The market maker is incentivized to choose a price so that he doesn't take on risk personally.
He just profits from arbitrage.

So the price is only determined by the open trades in the market. Nothing else.
J
00:39
Josh
if i make a limit order, is there a way for me to cancel it?
Z
00:42
Zack
You can make the opposite trade to cancel your risk.
You could wait to receive your order, the resell it.
You could have a time limit on your limit order.
J
00:45
Josh
makes sense
00:48
so my question transfers to the people making the limit orders, they don't know when they're going to fill, it could take a minute, it could take hours, it could never fill; I can add an expiration time but that increases the cost because I have to keep doing more txs until I fill my order. maybe this still works but making bets will be expensive and slow moving.
Z
01:02
Zack
This is the case with all markets, right?
Even an exchange like qtrade
J
01:12
Josh
in a liquid market like kraken, I can place limit orders and cancel them any time for free, they can get filled immediately; if they get filled it's very expensive.
01:12
if we require people to be online for the duration of the SC it might be a lot cheaper and faster.
mx
05:38
mr x
maximizing future difficulty should be the ultimate objective for all futarchies. it is the only ungameable metric in this world
Z
05:40
Zack
isn't it better to maximize price or the expected rate of increase in price or something?
mx
05:41
mr x
price is external
05:42
hash rate should be worshipped
05:42
everything else is a false god
Z
05:42
Zack
the oracles can bring price data internal.
Futarchy can be linked to anything the oracles can report on.
mx
05:43
mr x
how oracles resovle should be aso ulitamtely linked to future hashrate
Z
05:43
Zack
hashrate seems to be connected to how quickly new money is being pumped into the system. So it might be our best way of measuring growth.
mx
05:43
mr x
only one governance rule
05:43
future hashrate
Z
05:43
Zack
you might be right.
mx
05:43
mr x
yeah...
05:43
pretty crazy
05:51
just lol at proof of stake
mx
06:41
mr x
the ultimate fork choice rule is that which maximizes future hash rate and that is decided by futarchy
mx
07:00
mr x
governance problem and oracle problem are the same problem
K
07:41
K
Are sorition chains proven to be unusable then?
Z
09:30
Zack
In reply to this message
Another thing we could do, you could sell the limit order as is. By reassigning that part of the sortition tree
09:34
In reply to this message
It seems like they can help a lot with liquidity and scalability of smart contracts, without having the complications of shared mutable contract state.
But they don't help as far as getting the pubkeys and signatures off chain.
09:36
Sortition trees are a way to have more smart contract features without sacrificing the stateless full node model.
So they should be a more scalable in some ways
J
20:33
Josh
In reply to this message
So we always have oracles running asking if the future hashrate will be over X at date Y and the fork with the best answers wins?
DRIC (EXNETB) invited DRIC (EXNETB)
mx
20:51
mr x
We will have multiple onchain MARKETS running and asking about the future hash rate(difficulty) given the network updates in some way. We update in the way that is predicted to maximize future hash rate. This can be done fully within network so no need for oracles. Actually how oracles resolve should part of the network update proposal. All the choices about the network (reward, blocksize, how oracles should resolve...) could be batched into single proposal. We could have just one futarchy about everything once every 3 months or something.
20:58
just thinking aloud
J
21:06
Josh
Choosing the questions to ask can also be a challenge.
21:09
We need a name for the mechanism that decides if the difficulty really was over or under the question. It's kind of like an oracle, but internal and trivial.
Z
21:09
Zack
Hashes per day is probably better to optimize for than difficulty per block
21:10
In reply to this message
Batching different decisions together doesn't make sense to me
21:11
In reply to this message
With futarchy we are trying to find which choice would make us more likely to achieve out goals.
mx
21:13
mr x
maybe not batching, but shouldn't the choices be "big" enough to matter
Z
21:16
Zack
In reply to this message
you have a point. Maybe batching does make sense.
We would need to think about this more.

If the sub-decisions are too small to measure the price, then maybe it is too easy to insert bad sub-decisions into a batch, right?
mx
21:17
mr x
maybe it would work
21:17
there would still be need for escalation to get oracle into hash rate futarchy proposal
21:18
supreme court
21:19
and i don't really mean oracles
21:19
everything should be just statements about how money in contracts should be divided
Z
21:20
Zack
in many cases, futarchy betting can be done without actually creating the oracle. if the participants can agree on the outcome
mx
21:21
mr x
yea im talking about THE FUTARCHY
21:21
on chain hash rate futarchy
Z
21:22
Zack
If we can agree what the difficulty was on a certain block, then we don't need to create an Oracle for that
mx
21:22
mr x
yes
21:22
the whole point
Z
21:22
Zack
I think it would be easy to add the ability to chalang to look up historical difficulties
21:23
Let's give it time and see how people actually use futarchy
J
21:23
Josh
why do we need historical difficulties? difficulty is already a measurement of historical hashrate.
mx
21:23
mr x
right
21:24
just look up difficulty
21:24
done
Z
21:24
Zack
Blocks have the difficulty written on them.
We can estimate the hashrate from that.

The actual hashrate at any moment isn't knowable.
J
21:24
Josh
yeah that's what i mean, just take whatever the difficulty of the block is
17 May 2020
Z
00:28
Zack
The winning ticket of the sortition tree might be on a very deep branch.
I'm thinking that we might want to split up the proof of who won into multiple txs.
00:28
To make sure it can fit in a block
J
00:37
Josh
Can we do that binary search challenge trick?
Z
01:04
Zack
Yeah, doing it like a fraud proof might be better
Z
01:31
Zack
Because then, the Nash equilibrium would be for none of the contracts to end up on-chain
01:32
If none of the sortition tree ever gets used, because no one challenges the fraud proof, does that mean we can prune everything?
01:33
If someone makes a false claim, and we end up running some smart contracts on a losing branch, does that mean we cannot prune that part?
J
01:53
Josh
first we would prove that the value didn't win the lottery before checking the contracts, no?
Z
01:55
Zack
You run the contract to find out.

For example, a stablecoin contract, the price of usd/Veo determines how the probabilistic value is divided up among the child nodes
J
02:00
Josh
well we could make sure that the probability at least falls into the zone of the parent of those children
02:01
then we'd need to find out the price in any case
Z
02:03
Zack
if it isn't in the same zone, then it is automatically false.
Like
If ((X == 0) AND (X == 1)) is always false.
02:04
but to verify that something like this isn't inside the contract, it seems like you would need to run the contract.
This is an example of the halting problem
J
02:05
Josh
right so at least we can prune most of the contracts, the ones belonging to probability value outside the parent zone
Z
02:05
Zack
well, not exactly the halting problem. something similar.
02:12
I kind of like the idea of doing it on-chain, because it is faster to claim your winnings, and simpler to understand, and it is more clear which parts can and cannot be pruned, and it is more resistant to censorship attacks, and even if you are stuck offline for a long time, no one else can steal your winnings from you.

But I like the fraud proof strategy because the nash equilibrium has less data and computation on-chain to prove who won.
02:14
maybe it is better to go with the simplest version first, and switch later if we need to.
J
02:14
Josh
that's usually the right call
02:24
In reply to this message
but isn't the amount of on-chain data O(n) vs O(log n)?
Z
02:24
Zack
idk what "n" means here.
J
02:25
Josh
the size of the proof
Z
02:25
Zack
yeah, im still lost
J
02:26
Josh
which is all the ownership transfers and all the contracts in those transfers
Z
02:26
Zack
the on-chain data is O(# ownership transfers) yes.

we only need to store the hash of the contract on-chain in most cases, not the entire contract.
J
02:27
Josh
unless someone challenges?
Z
02:27
Zack
challenges only happen if we use the fraud proof strategy.
J
02:28
Josh
so why wouldn't we need the contract on-chain?
Z
02:29
Zack
so im thinking a tx for proving that you won, lets say there are 10 steps in the sortition tree to get to the leaf that you own.
maybe you can't fit all 10 smart contracts in a single block.

So, first you could make a tx that runs the first 5, and the on-chain consensus state would update to realize that only a small sub-tree of the sortition tree can possibly win.
Then you make another tx to run the next 5 smart contracts and claim your winnings.
02:29
In reply to this message
if it didn't win the lottery, it doesn't matter what the contract does.
02:30
that is why we can prune parts of the sortition tree and some historical txs. because they contain no value and it doesn't matter what their contracts do.
J
02:30
Josh
sure, i was talking about the contracts in the ownership transfers in the chain that led to the winning ticket
Z
02:31
Zack
In reply to this message
lets just put all those on-chain and keep it simple
02:31
it is only log2(total # of contracts) that would need to go on-chain
J
03:13
Josh
In reply to this message
How do you calculate this?
03:13
Is this because you're only reporting the winning branches each time?
Z
03:15
Zack
If a balanced binary tree has n elements, then one path has log2(n) elements.
J
04:14
Josh
You're talking about a tree where each node branches into a contract returning true and a contract returning false?
Z
04:14
Zack
Like how the sortition tree already works yes.
04:14
It is one contract per node, either returns true or false
04:15
It is a binary merkle tree with a smart contract at each node