1 May 2020
J
05:01
Josh
k, sounds good
Michael invited Michael
J
05:20
Josh
cool, I'll have to sit down with that at some point, will take me a while to get through it
K
05:46
K
Cardano created a paper on their own state channels btw
Z
06:59
Zack
What we need is an outrageous story about how someone got rich making an unlikely bet using Amoveo.
07:11
In reply to this message
haha, cardano needed 24 employees over a 5 year period to implement state channels.
K
07:29
K
In reply to this message
Fake the story
07:29
In reply to this message
Yeah it’s the definition of vapourware
Z
07:47
Zack
In reply to this message
well, we at least need to get the conditions right, to make it possible
B
11:04
Ben
In reply to this message
Logically this makes sense
Z
13:22
Zack
Instead of downloading batches of blocks at a time, maybe it makes more sense to stream the blocks.
I think it would significantly reduce ram costs for serving blocks, and it would result in faster syncing speed.
Deleted joined group by link from Group
Deleted invited Deleted Account
J
18:32
Josh
Hubs might want to split their funds between cycle chains going in both directions, clockwise and counterclockwise; that way they only need a quarter of the groups waivers on average.
18:44
Each permutation of the cycle still allows a hub to send to everyone but optimizes the path to different other hubs. So each hub could have a few different permutations to reduce the number of waivers it needs each time.
J
20:13
Josh
I think each permutation can reduce the max path length by half, so maybe with log n SCs you'd never have to request more than log n waivers.
Z
20:16
Zack
if we split into 2 cycles, each has half the liquidity.
but yes, that could be useful.
Another pattern i was looking at. say A, B, C, and D are the cycle members.

ABACAD repeating

this way it is always very easy to send the money to A.
J
20:17
Josh
Yeah that makes sense since it's A's SC
Z
20:18
Zack
maybe A could be the validator.
It all depends on what the cycle members anticipate doing
J
20:18
Josh
I guess it would depend on the pattern of flows
20:19
In my scheme each channel has less liquidity but it's instant and cheap to rebalance the liquidity.
20:20
And each SC can still send to anyone, it's just more annoying
20:20
You could also send a payment through multiple SCs if necessary but that complicates things
20:21
But my scheme might drastically reduce chatter and signing operations
20:21
And maybe reduce freeze risk if one of the hubs goes AWOL
Z
20:22
Zack
sure. counter-cyclical is one way.
ABCDEF
FEDCBA
We can make 4 cycles too
ABCDEF
FEDCBA
ACEBDF
FDBECA
20:23
In reply to this message
each bit of liquidity can only have once cycle attached to it.
20:24
Having one cycle, but different parts of the liquidity are at different stages of the cycle is pretty similar:
ABCDEF
CDEFAB
EFABCD
J
20:29
Josh
In reply to this message
But you can't choose which part of the cycle you want to be in at any given point in time
20:30
I'm imagining 10k hubs and I'm only going to have to send a small payment randomly to a few of them
20:30
But I don't know which
Z
20:31
Zack
I am guessing the payment would go
You -> Hub1 -> Hub2 -> recipient
J
20:31
Josh
I can either ask for 5000 waivers, or choose the right SC and ask for 13 waivers
20:32
In reply to this message
Right
Z
20:32
Zack
if there are N participants in a hub, then at most that hub only needs to create N waivers to process a single payment
J
20:32
Josh
Problem is going from hub1 to hub2
Z
20:32
Zack
as long as hub1 and hub2 have a member in common, it works
B
20:32
Ben
In reply to this message
This idea makes sense — sounds like a good approach.
J
20:33
Josh
In reply to this message
Right but N can be a lot since there will be millions of small payments
20:33
I want to bring it down to log n
Z
20:33
Zack
a hub with 2 members could process millions of payments
20:34
the number of hubs has more to do with how many total customers there are, and how much liquidity each hub member has
J
20:35
Josh
If there are only 2 hubs in the system this doesn't help
20:35
But if there are 100 hubs it helps a lot
Z
20:36
Zack
if I have 1/2 of the veo in a sortition chain, then we would need 0 hubs. everyone could just make a channel with me.
20:36
if you and I each had 1/4, then we could have a 2 participant hub, and half the customers could have channels with me, and half with you.
20:37
if 3 liquidity providers each had 1/6th, then they could have a single 3 participant hub, and 1/3rd of the customers would make channels with each liquidity provider in the hub.
20:38
we don't really need 2 hubs until the cycle size becomes so big, that we can't trust the other hub members to sign when they are supposed to.
B
20:39
Ben
If I create a sortition chain, how do I select my validator? I’m still not totally clear on how they are selected, or discovered. Is there a pool of ‘willing and waiting’ validators that are advertising their services as being available?
Z
20:40
Zack
In reply to this message
in the new_sortition_tx, you write who you want the validator to be. you can put anyone's pubkey.
20:40
you could even write the burn address, and make a provably frozen sortition chain
B
20:41
Ben
Why would I select one persons pubkey over anothers? Is there a rational to picking my validators more wisely?
Z
20:41
Zack
I am guessing most people would just choose themselves as the validator of the new sortition chain.
B
20:42
Ben
And why would I pick a third party to be my validator when I could create another pubkey and pick myself ?
Z
20:42
Zack
like, why are you going to make a sortition chain? what is the motive?
20:42
you don't need to create a new pubkey. you can use your existing pubkey
B
20:42
Ben
I’m just trying to understand what the benefit of an independent validator is, if I can pick myself
Z
20:42
Zack
or you can create a new one if you want
20:43
If you get tired of being validator, you can create a baby sortition chain inside your sortition chain, and assign someone else to be validator
B
20:44
Ben
What are the conditions of being tired?
Z
20:45
Zack
like, if you want to turn off your computer with your private key, but you don't want the money in the sortition chain to be frozen.
B
20:46
Ben
What assurance do I have that the person I assign wont shut their computer off too?
20:46
I don’t see how its a viable alternative
Z
20:48
Zack
Maybe you want to use a different pubkey for the validator vs the pubkey that owns most of your money, so you don't need to put your important private key on a 24/7 server.
J
20:49
Josh
In reply to this message
I agree we don't need this for a while but we also don't need off chain scaling for a while
20:49
It's just a thought experiment, and doesn't even require any Amoveo changes
Z
20:49
Zack
In reply to this message
sortition chains isn't just about scaling.
We need single price batch markets for derivatives to be useful
20:50
doing single price batch markets through the lightning network had serious liquidity limitations
B
20:51
Ben
Let’s say I want to create a sortition chain that says BTC will not go to $7k again before June 15th. I’ll put up 2 VEO if it goes to 7k. I want 1 VEO if it doesn’t. does that work for a simple sortition chain?
Z
20:51
Zack
with sortition chains we can divide up the probabilistic value space by smart contract, which recovers a lot of the liquidity
20:52
In reply to this message
"sortition chains" don't say anything about the price of BTC.
You could make an oracle that will report on the BTC price. You can make a smart contract based on the outcome of that oracle. you can put this smart contract inside a sortition chain.
B
20:52
Ben
okay that makes sense
Z
20:52
Zack
yes, you can make a 2 VEO vs 1 VEO bet about the price of BTC
B
20:53
Ben
If there was a simple way to construct markets and the SC’s and the sortition chains that they existed in, then you could auto-generate a large number of interesting derivatives that operated similar to calls and puts
Z
20:55
Zack
In reply to this message
We can't have single price batch markets on-chain. it is always possible to cheat. I wrote about why the gnosis batch on-chain strategy doesn't work here https://github.com/zack-bitcoin/amoveo-docs/blob/master/other_blockchains/gnosis_multi_token_batch_auction.md
20:57
In reply to this message
> and the SC's and the sortition chains

what do you think "SC" means? if it doesn't mean "sortition chain"?

calls and puts are a kind of derivative yes.
B
20:59
Ben
i was just shortening smart contract in that case with SC
20:59
i guess you can use SC for either 🙂
Z
20:59
Zack
In reply to this message
its not just that we don't need it for a while.
Im trying to explain the conditions under which it makes sense to use 2 hubs instead of 1 hub.
Each hub only has a few members, so even if there are millions of payments, most payments wont be passing through most hubs.
So the total number of waivers per payment will be low.
21:10
Let me make a more concrete example.
If we use VEO denominated channels to bet that the price of BTC will be above $8k.
I want to bet 2 veo vs 2 veo.

If I want to be able to win 2 veo, then I need to have 2 veo locked into the other side of the channel with the hub, and 2 veo locked on my side.
Also, the hub will have another channel with someone on the other side of the trade, it locks up 2 veo on each side.
So in total, 8 veo of liquidity are locked for the duration of the trade.

Now imagine I am doing the same thing in a sortition chain.
I could make a channel with the hub, and the channel is denominated in derivative contracts. So if BTC is worth > $8k, the channel has veo, and if BTC is worth < $8k, the channel is empty.
The hub also makes a channel with the person I am trading with. That channel is set up so if BTC is worth >$8k, the channel is empty, but if BTC is worth <$8k, the channel has veo in it.

Each channel can have up to 4 veo at the end, but the total number of veo at the end is only 4.
So the total liquidity locked up in this case is only 4 veo.

Without sortition chains, we would need 8 veo to enforce this contract. With sortition chains we only need 4.
21:15
In ethereum they would achieve the same thing by creating a subcurrency for the 2 sides of the bet, and then having a market for the 2 new kinds of subcurrency.
That also reduces the liquidity requirement from 8 to 4.

But having on-chain subcurrencies does not scale. It requires mutable state. Amoveo wants to have only stateless contracts.
And having on-chain markets is not secure. It is vulnerable to front-running from the miners. Amoveo wants to have secure single-price batches.
J
21:20
Josh
In reply to this message
Good example, I need to study this a bit more.
21:22
In reply to this message
I don't understand this. If there are lots of users and only a few users per hub, that means there will be lots of hubs. If all the hubs have to be in a cycle together, that means that each payment will require O(n) waivers. So the total number of waivers per payment will be high.
Z
21:22
Zack
I have been using the word "hub" to mean a cycle of several people.
so saying "all the hubs have to be in a cycle together" doesn't make sense.
21:24
if each hub has 5 participants, and there are N people participating in hubs, each with the same amount of money, and there are M customers who have made channels with the hubs, then the number of steps in a typical payment path is log5(N).
21:24
Notice that M is not a part of that equation O(log5(N))
21:25
if a payment has O(log5(N)) steps, and each step has 5 waivers, then the number of waivers for a payment is O(5*log5(N))
21:27
well, I guess on average only 1/2 the hub participants need to sign waivers for a payment. so more like
O(5*log5(N)/2)
J
21:28
Josh
I was using "hub" to mean the node that has a lot of users connecting to it; so a group of these hubs in a cycle would be your "hub". So we were talking about two different things.
21:29
what do you call a participant in your hub?
21:29
we could call the participants and hubs and the cycle a "superhub"
Z
21:30
Zack
hub-member
21:34
In reply to this message
>if all the hubs have to be in a cycle together

so you are asking "if all the N people who want to be hub-members for a given sortition chain all made one giant hub together, then a single payment would require N waivers"
Yes, that is true.
But also, they would never do that.
Because any one of them could refuse to sign, and the whole thing freezes.
It is more likely that there will be many small hubs of between 3 to 10 members each.
J
21:40
Josh
but then i might not have a path to someone else i want to transact with
21:41
i want to be able to walk into a store and instant pay
21:41
if each hub only has 5 members, we won't be connected to the same hub
Z
21:43
Zack
each member is also a member of other hubs. It can be a densely connected mesh
21:43
if certain paths become too unbalanced, the entire network of hubs can get re-created at the next on-chain merkle confirmation
21:44
we can close every hub-cycle, and recreate an entirely different network of hub-cycles, at every block. 130 times per day.
J
21:44
Josh
but i also might not have a path at all
Z
21:45
Zack
In reply to this message
you chose which person to make a channel with to sign up. You have an incentive to choose a well connected person.
Which means the hub-participants have an incentive to be well connected.
J
21:46
Josh
it will be interesting to see how this develops
Z
21:46
Zack
making a graph where everything is well connected is pretty easy
J
21:46
Josh
yep but there are usually a few huge players
Z
21:47
Zack
since there are many sortition chains, a huge player could be the entire network of hubs for one sortiiton chain, or multiple sortition chains.
21:47
He could own like 20% of the value in the sortition chain, and everyone makes a channel with him
21:47
he could also be the validator of that sortition chain at the same time
21:48
so any lightning payment inside that sortition chain is
User1 -> validator -> User2
21:50
we only need to use 2 hubs if there are a large number of people who want to be hub-members in a single sortition chain
21:51
Since it is practically free to make baby sortition chains, maybe the normal way to do thins is 1 person acting as the hub for the entire sortition chain, while also being the validator for that sortition chain.
21:52
That is another reason we need the ability to do baby sortition chains.
Because it lets us switch out validators.
J
21:55
Josh
what does "acting as the hub" mean?
21:56
who is in the hub?
Z
22:07
Zack
everyone just makes channels with the one guy. so every lightning payment is 2 steps
22:08
he doesn't need to make a hub-cycle, because no one else is participating to provide liquidity. it is just him
J
22:13
Josh
i think it will be important to connect different SCs, most people will not be on the same SC
Deleted joined group by link from Group
Z
22:35
Zack
yeah. so participants in a hub on one sortition chain can also participate as a hub on others.
22:36
the relationship between different probabilistic value in the same sortition chain, and the relationship between different probabilistic value in different sortition chains, is basically the same thing
23:09
I'm not sure this is right. In Bitcoin if I publish a block and nobody builds on it I will get orphaned. But in Spectre if I publish a block and nobody builds on it the nodes will still recognize my block reward.
Mohammed Dalí invited Mohammed Dalí
Z
23:38
Zack
In reply to this message
There is a difference between a censorship attack, and literally no one building on your block.
If no one builds on your block, it is like that block never happened.

If you look at the graph and example from the spectre paper, you will see that even during a censorship attack, the blocks that get censored are still being built on top of.
23:39
Indefinitely delaying finality is another way to break it.
If we keep flipping txs back and forth for which are valid and which are canceled.
23:43
Spectre has 2 contradictory problems to solve.
They want to stop people from building blocks in secret to overtake the chain.

So to stop this, they need to reject blocks that don't get referenced by other recent blocks.

The other problem is if an attacker builds blocks and refuses to reference other blocks, in an effort to censor them, this needs to be punished to.

But any effort to prevent the first failure mode would make the second failure mode easier to pull off. And any effort to prevent the second makes the first easier to pull off.
23:44
So when you are imagining features that could help prevent one failure mode, you need to also consider if you are creating a vulnerability in the other failure mode.
J
23:48
Josh
"If no one builds on your block, it is like that block never happened." — why? you did PoW and the nodes will accept your block. in what way did it not happen?
Z
23:50
Zack
In reply to this message
Imagine I made a tx that conflicted with a tx in the dead block, and my tx got included in a recent block. Which of the conflicting txs wins?
23:50
If the dead block wins, that means I can rewrite history after the fact by building dead blocks.
J
23:51
Josh
the block doesn't win, the tx in the block wins
Z
23:51
Zack
If the dead block loses, then all the txs in it are worthless. Since they always lose.
23:52
So a block that is never built on top of, might has well not exist at all.
23:54
But there are also censorship attacks where the block does get referenced by a more recent block.

If spectre was a serious attempt at a blockchain consensus, the first thing they would do is give a fork choice rule. To calculate the weight of the chain from any given block. So we can know which block has highest priority.
23:55
Blockchain designers are always scared to admit the fork choice rule, because then it is obvious how it is broken.

If they can obscure the fork choice rule, then they can secretly use a different fork choice rule for every example, and trick people into thinking it is something that can exist.
23:57
Each block has a merkle root for the utxo set/accounts database from that point, right?
23:58
Or does spectre require everyone to run a full node, and sync the entire history?
23:58
If there is no database root in each block, then the only way to know if a conflicting tx exists is by syncing all the older blocks that it references
2 May 2020
Z
00:05
Zack
So when you add a block, do you need to scan through the entire utxo set, and assign new priorities to every output, and possibly switch out valid and invalid outputs?
J
00:06
Josh
They alluded to some fast algorithm but that might be a problem. I'm not saying this is a good approach, I just think the argument I pointed out isn't correct.
00:07
In reply to this message
I can build on my own blocks and nobody can stop me. Eventually they might have enough PoW for the mining rewards to be accepted.
00:08
I don't think we need to spend too much time on this, I just want the doc to be accurate.
Z
00:08
Zack
In reply to this message
If the highest priority block doesn't have any of your blocks as ancestors, they are all completely censored.
J
00:25
Josh
what's the highest priority block?
00:26
this is a dag, you look at all the blocks
Z
00:49
Zack
if there are light nodes, the highest priority block is the one that the light nodes download a merkle root from to verify merkle proofs to find out if their txs have been include.
00:51
if there are no light nodes, you can define "priority" or "block weight", and then whichever block has the highest weight is the "highest priority block"

We know that priority must exist, because if I build a block who's only ancestors are from a week ago, and no one builds on top of it, if there are txs in my block that conflict with txs in other recently made blocks, the txs in by block will be rejected in favour of the others.

So my block has lower priority than the others.
00:51
if blocks have relative priority against each other, then there must be some block that has the highest priority.
J
01:04
Josh
They don't talk about light clients so it's better to stick with full nodes. Full nodes have to download all the blocks.
Z
01:04
Zack
if every user is a full node, and every full node needs to scan every tx, then it is not worth discussing further, right?
01:05
that clearly does not scale. it is worse than bitcoin
J
01:05
Josh
There might be a lot of blocks with the same priority. You can't just take one top block because it might point to all the blocks and to all the transactions.
01:06
In reply to this message
Perhaps but we should still describe it correctly.
Z
01:07
Zack
so it isn't worth considering the case that every user is a full node.
So if we are going to talk about it, we must be focusing on the case where their are light nodes.
But then, we can show it is broken because the merkle tree is infeasible to maintain.
01:08
There is this general pattern I am noticing in all these scam projects.
The refuse to make decisions that would lead to it being too obviously broken.
01:09
It is like, their paper outlines a massive space of possible blockchain designs. and for every possible attack, they show that there is some design inside the massive space they are considering which would be secure against that attack.

and then they conclude: "we proved it is secure against all possible attacks!"
01:09
but they never showed a single design which is simultaneously secure against all the attacks.
01:09
and if you try complaining about this, they are all "we wanted to solve for the general case. that decision is outside the scope of this paper."
01:11
for example, alternative blockchain designs almost never admit to what the fork choice rule is.
01:11
or in the case of spectre, they refuse to admit whether or not they will have light nodes.
J
01:14
Josh
Well otherwise there would be a lot more good designs
01:14
The reason I was drawn to Amoveo is that there aren't
Z
01:15
Zack
im thinking of calling it the "undecided fallacy"

We should create memes to help immunize people against scams.
01:15
Maybe we can make this concept bite-sized and attach a funny picture
J
01:16
Josh
Don't we have a meme-master in here?
Z
01:16
Zack
there is a difference between advertisement memes and immunization memes
01:16
we have a different (dead) channel for advertisement memes.
01:17
oh, I think this is called "over-generalization"
J
01:17
Josh
I think it would be hard to out meme Bitcoin maximalists
Z
01:18
Zack
There is a Russian who can build blockchains.
There is a Russian who can write books.
There is a Russian who is 6 feet tall.
Therefore: all Russians are 6 feet tall,can build blockchains, and write books.
01:18
bitcoin maximalists love sharing memes that immunize against shitcoins
01:18
or at least make fun of them
J
01:18
Josh
Yeah but they call Amoveo a shitcoin
01:19
But if you can get into a high profile fight that boosts your signal
Z
01:20
Zack
this is different from advertising Amoveo.
I want to make it easier for people to notice when blockchain scammers are using the over-generalization fallacy to make their designs seem more secure than they are.
01:21
or at least have a paper about it, so I don't have to waste time re-explaining this concept so often
J
01:24
Josh
Yeah it's hard to make these things simple
01:26
https://github.com/zack-bitcoin/amoveo-docs/blob/master/other_blockchains/spectreDAG.md I added more notes from our discussions to the spectre review.
J
01:40
Josh
Nice
Deleted joined group by link from Group
3 May 2020
Z
00:21
Zack
An attack was discovered against bitcoin LN. it is kind of interesting.

Say we have a 2 step lightning path Alice -> Bob -> Charlie
With channel AB for Alice and Bob, and channel BC for bob and charlie.
We want to atomically connect an update between AB and BC, so that either the payment goes the entire path, or else it doesn't happen at all. This way Alice can pay Charlie.

The attack involves how bitcoin's mempool for zeroth confirmation txs works. If you try to publish a tx, mining pools will only accept it if it doesn't conflict with any tx already in the mempool. This helps to prevent double spending of zeroth confirmation txs.

So if Charlie publish a very low fee tx, revealing the secret in order to close BC in the state of the payment having executed, this tx could sit in the mempool for a while. And as long as it is in the mempool, it isn't possible to close BC in any other conflicting state.

But since it is only in mining pools mempools, and not written on the blockchain, Bob might not be able to find out the secret to close AB in the state of the payment having executed.

So this is a way to disconnect AB and BC, so the payment only goes half-way. Alice and Charlie can steal money from Bob.
00:22
--------------
I wonder if this attack can be applied to any parts of our plan for sortition chains.
00:25
if we can't atomically connect smart contract updates, it throws the entire sortition design into question. so this is something we need to solve.
00:28
I think we already decided that if cooperation isn't happening with an atomic update, that the secret needs to get put on-chain with a proof-of-existence tx, and it needs to be put on-chain before an expiration set inside the contract.
So if someone attempts this attack, you just need to wait until the expiration.
At that point the low-fee tx becomes invalid, because it wasn't included soon enough
J
00:48
Josh
I didn't fully understand this attack, do you have a link?
Z
00:49
Zack
I added you to the group
J
00:50
Josh
ok thx
Z
00:52
Zack
I wrote about the attack here, but it is basically the same thing I wrote above https://github.com/zack-bitcoin/amoveo-docs/blob/master/attacks_analyzed/LN_mempool_attack.md
01:01
there are a lot of proof-of-existence issues in amoveo, like a validator publishing a merkle root without providing the structure, so we're probably thinking about these things more.
01:02
but blocking a counter-party's tx via the mempool is a pretty novel attack
01:02
is this even possible in amoveo?
01:08
it definitely wouldn't work the same way because there isn't even multisig in amoveo
Z
01:19
Zack
In reply to this message
That attack is well documented and discussed.
That is what happens if the validator freezes your funds.
You do a final spend tx, so you don't have lottery risk.
J
02:12
Josh
Right, so how would this kind of attack happen on Amoveo?
Z
02:15
Zack
if our mempool was full, I think this could happen to normal state channels.
But, you can overcome it if you make a more complicated smart contract that may require the secret to be revealed on-chain in a proof of existence tx.

Turing completeness makes it very adaptable.
J
02:17
Josh
I guess we should have a test for this
Z
02:18
Zack
good idea
J
02:18
Josh
Wouldn't we want the sortition finalization to guard against this by design?
Z
02:19
Zack
i don't know what you are asking
02:21
when we do time-hashlocking, once the secret is revealed, it is important that everyone learns it.
we use time-hashlocking inside the sortition chain to connect channels together
J
02:26
Josh
By channels you mean sortition chains, right?
Z
02:26
Zack
I mean the ownership cycles with 2 participants
02:26
or any other structures that can be hashlocked
Deleted joined group by link from Group
Deleted invited Deleted Account
Deleted joined group by link from Group
neeraj bhatia invited neeraj bhatia
Andrey Kolyada invited Andrey Kolyada
Z
23:13
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_defense.md I remembered why we need multiple validators for each sortition chain.
If all the validators work together, they can force you to hold lottery risk.
23:13
I documented it in "data availability + double-spend"
23:16
it has to do with the probabilistic nature of sortition chains. Waivers don't necessarily become available, and there is an asymmetry between people who could get paid by waivers vs final_spend_txs.
23:16
luckily I didn't remove this feature yet.
Z
23:37
Zack
I do need to switch a bunch of documentation back from singular to plural.
4 May 2020
J
00:13
Josh
Could Charlie make his smart contract not pay Alice if he can prove she issued a final_pay to someone else?
00:22
I guess she wouldn't accept a deal like that but it would show that she was cheating. Charlie still wouldn't have incentive not to take the original deal though.
Deleted invited Deleted Account
Z
00:36
Zack
I was imagining that Alice and Charlie are actually the same person, but with different keys.
J
00:41
Josh
Hmm, yeah even if she only owned a small bit of the probability space it still works for her because she'd get Bob's payment even if she loses.
00:54
What if everyone always had a queue with their liquidator in it; the liquidator is the guy who buys up all the probability space; every time they add someone, they add the liquidator to the end of the queue. The liquidator will constantly be issuing waivers for people, but if there's a data availability attack, everybody can still sell out to the liquidator. Probably too much overhead tho.
Z
01:13
Zack
In reply to this message
very clever idea. I need to think about this more.
01:13
maybe if we used that strategy, we only need one validator per sortition chain
chadsgx invited chadsgx
Rembo Ronald invited Rembo Ronald
Z
02:09
Zack
It seems like with this strategy, you would need the liquidator's cooperation to put anyone new in line in the sortition chain.

But we already need the validator's cooperation for that.

Maybe the liquidator and the validator should be the same person.
02:10
oh, we don't want one person to have monopoly control of liquidation for one sortition chain.

He could freeze your money so that you are stuck either selling to him, or holding lottery risk.
02:12
we don't want one person to have monopoly control of liquidation over any part of the probabilistic value space.
J
02:22
Josh
If this happened we wouldn't be able to do final spends so the liquidator could charge high fees. But the liquidator still has the incentive to buy up as much as he can so he doesn't have lottery risk.
02:24
Although maybe he'd want to bribe the validator to get higher fees.
Z
03:19
Zack
Maybe there could be several liquidators listed in the ownership object, and if your money gets frozen, you can choose one.
J
04:36
Josh
how would they know you're not double spending them?
Z
04:41
Zack
It is symmetric. So we can set it up so if you spend to both, then the money is deleted.
The liquidators are incentivized to check with everyone else in the list, and share with each other evidence of a double spend.
04:42
The atomically linked payment can get canceled if a double spend happens.
J
04:47
Josh
what if you already gave someone else a waiver?
Z
04:47
Zack
can you be more specific about the situation you are asking about?
04:47
gave who a waiver for what?
J
04:53
Josh
say you have a queue where you add alice, then bob, then 3 liquidators l1, l2, and l3; how do the liquidators know you didn't give a waiver to alice?
Z
04:54
Zack
So, I am in line ahead of Alice?
J
04:54
Josh
yeah
Z
04:55
Zack
oh right. It isn't clear whether Me, or Alice, or Bob was the last to own it before the liquidators. So it isn't clear which of us should choose which liquidator to win.
04:56
oh, I got it.
So, I won't make a waiver at all.
I have Alice and Bob both make waivers, so now the liquidators are next in line.
Then I sign a final_spend_tx to choose which liquidator should win.
04:57
If I did sign a waiver after all that, I guess nobody would win.
04:57
because we can't prove whether Alice and Bob signed their waivers first, or whether I signed my waiver first.
J
05:00
Josh
why wouldn't the liquidator still win even if you signed a waiver? they should be next in line.
Z
05:01
Zack
which one of the liquidators would win?
05:02
if there is only one liquidator, there are monopoly issues. If there are multiple, then there is no secure way to know which one should have won.
J
05:03
Josh
your original idea is that the liquidator group is special, it's a set not a queue, so they could invalidate each other's payments
Z
05:03
Zack
ok, so if I want to send to liquidator B, then liquidators A and C could sign something admitting that I didn't send it to them
05:04
but if we do it that way, any one of the liquidators could prevent you from doing a final_spend_tx
J
05:04
Josh
yeah, might as well just put them in the regular queue
Z
05:05
Zack
oh yeah, if they are queued up, then you don't need permission from B or C to sell to A.
But you need A's permission to sell to B.

Doesn't that mean A can do monopolistic exploits?
J
05:05
Josh
but if it's a set, then they don't have to worry -- if you signed it over to two of them, they'll both get double spent and they'll have proof you cheated so the atomic payment won't go through
Z
05:06
Zack
what if I sign over to only one of them, and then make a waiver giving up ownership of the value?
There is no way to tell which of those events happened first.
05:06
if I made a waiver first, then I shouldn't have had permission to do the final_spend_tx
05:07
if I did the final_spend_tx first, then the waiver should be invalid.
J
05:07
Josh
yeah, the problem is they still don't know which waivers to demand because there might be new ownership records in the root with missing data
Z
05:09
Zack
it would sure be nice if we only needed one validator.
J
05:09
Josh
actually, they'll have precedence because they're in an earlier block
05:09
which means you'd need their waiver to transfer to new people
Z
05:10
Zack
right, you would need their cooperation for every update of the sortition ownership object. the same as the validator.
J
05:10
Josh
and since you don't have final spend, there's still lottery risk
05:10
so it's basically the same as having multiple validators
05:11
the difference is you have more control
05:11
do you know about coded merkle trees?
05:12
actually that might not help
Z
05:13
Zack
https://arxiv.org/abs/1910.01247 looks like they make data availability cheaper to prove.
But to prove the availability of B bits of data, you need to download O(log2(B)) sized data from whoever is maintaining the merkle tree.
J
05:16
Josh
yeah but they could just prove data availability, that just means they have the data, it doesn't mean everybody else has it
Z
05:17
Zack
right. and sortition chains are flipped the other way.
Each user is storing the data they need to prove their own ownership.
There isn't a central location with a huge database we all care about.
J
05:18
Josh
another idea I had was having all owners sign the merkle root instead of validators; this only works if the multisig is O(1) but that might be possible
Z
05:18
Zack
most of them are offline though
J
05:18
Josh
only the ones that are actually requesting ownership changes need to sign
Z
05:18
Zack
we can't require them all to come online at the same time, that would be a UX nightmare
05:19
In reply to this message
but to know who is allowed to do that, you would need to record all the waivers as well
J
05:20
Josh
i'm not sure, the tree is just a collection of signed ownership changes, you just need the people who are signing those records to sign the root
05:21
the only reason anybody needs to sign the root is to avoid the data availability issue, right?
Z
05:22
Zack
if I am first in line, and the validator puts you second in line, and I don't want to send you my money, and you refuse to leave your spot as second in line, then my money is frozen until the final_spend_tx.

So we don't want just anyone to be able to act as validator.
J
05:32
Josh
but i have to sign, so that can't happen
Z
05:32
Zack
if anyone can act as validator, they can make a burn address be next in line to own your value.
J
05:33
Josh
i have to sign any record that puts someone next in line
Z
05:35
Zack
If we keep a shared record of everyone's txs to everyone else, then it is a normal blockchain.
J
05:35
Josh
we only publish the root on the blockchain
Z
05:35
Zack
linking together a PoW blockchain with something like this seems to be an unsolved problem
05:35
and how does the main chain know which roots are valid?
05:37
https://github.com/zack-bitcoin/amoveo-docs/blob/master//other_blockchains/drivechain.md drivechain is a project trying to do something like that
J
05:37
Josh
if i want to prove i'm next in line, i need a published root, a merkle proof, and that merkle root has to be signed by the owner who put me in line
Z
05:37
Zack
and how do we know that owner had permission to put you in line?
05:37
how do we know that they were the previous owner?
05:38
do you publish on-chain an entire history of the part of the value that won?
J
05:40
Josh
how is it different from the situtation now with validators? i'd still need to prove the full history, no?
Z
05:41
Zack
in normal bitcoin a tx is simultaniously giving up ownership, and assigning ownership.
In sortition chains we split apart those 2 things, and this makes it more compatible with fraud-proofs.
05:42
in sortition chains there exists some ownership claim which does not have a waiver, and is the highest priority of all sortition claims for the part of the probabilistic value that won. that is the claim that wins.
J
05:45
Josh
ok alice starts with ownership of probabilistic value, puts bob next in line and gives him a waiver; now bob has ownership and puts charlie next in line and gives him a waiver; how does charlie prove that bob was the owner?
Z
05:48
Zack
charlie doesn't prove anything about bob.
charlie shows that the validator(s) had put him in line at a point in time.
05:49
if Alice or Bob try claiming the value with higher priority, then charlie publishes the waiver from them, to show that they gave up control of this value.
J
05:53
Josh
so same thing in my version; alice has ownership, she signs a root putting bob next in line; bob signs a root putting charlie next in line; charlie has waivers from alice and bob so he knows he has ownership
Z
05:54
Zack
in my version Charlie can show he was put in line in a single step. by showing the merkle proof from when the validators put him in line.

in your example, proving that charlie has ownership involves first proving that Bob had ownership, which involves first proving that Alice had ownership.
J
05:59
Josh
the merkle root and merkle proof are exactly the same in my version, the only difference is it's signed by bob instead of the validators; the reason bob signs it is so nobody can do a data availability attack on him
Z
05:59
Zack
and how can we know that a merkle root signed by Bob is valid?
First we would need to prove that Bob has permission do spend this value.
J
06:01
Josh
if bob doesn't have permission to spend the value, charlie won't have waivers from everybody before him
Z
06:05
Zack
and how do we know that those waivers are from previous owners?
J
06:07
Josh
if anybody else tries to claim the value, bob can publish their waiver
06:07
i mean charlie
06:08
the only difference between our versions is who signs the merkle root
06:09
the validators aren't supposed to have any power in your version, we only need them to sign it to guard against an availability attack
Z
06:09
Zack
In reply to this message
and that is the key difference that lets sortition chain fraud proofs be so small.
06:09
if we don't do it that way, you need to publish the entire ownership history
J
06:10
Josh
but in my version we are publishing the same merkle roots
Z
06:11
Zack
the key is that the validators sign it, not the previous owner.
06:11
because we can prove who the validator is immediately. they stay the same.
06:12
proving who the previous owner was is more complicated.
J
06:13
Josh
in your version, charlie needs waivers from all the previous owners, so he needs to know all the previous owners, right?
Z
06:14
Zack
yes. charlie keeps all that information for his own personal record.
06:14
That way Charlie can prove that Alice and Bob do not own his value.
J
06:15
Josh
ok, so i'm saying charlie needs to check that the previous owners signed the correct merkle roots, nobody else needs to check that
Z
06:15
Zack
so if Charlie wins, what does he publish on-chain to claim his winnings?
J
06:16
Josh
the merkle root where he was put next in line, and the merkle proof for that record
Z
06:16
Zack
How can we know that the root putting him next in line is valid?
J
06:17
Josh
because it's signed by the same person as the record
Z
06:17
Zack
if the validator had signed it and put it on-chain, then we could prove it is valid in O(1).
06:17
In reply to this message
as what record?
J
06:17
Josh
the ownership record that the merkle proof is proving is in the merkle tree
Z
06:17
Zack
how do we know it is the valid version of the merkle tree?
06:18
(if the validator had signed it, then we would immediately know it is valid.)
J
06:18
Josh
that's the only thing that makes it valid, so it's valid
Z
06:19
Zack
So lets say there is a big sortition chain that I am uninvolved with. I build a merkle tree saying that the entire value is mine. Then I sign something giving all the value to you.

How can the main-chain know that the ownership claim I had given you is not valid?
J
06:23
Josh
the real owner has higher priority, so they will post their claim and beat you
Z
06:41
Zack
I could post a claim with even higher priority.
The moment a new sortition chain is created, I will give myself all the value from no-where.
Then I will keep spending the value to myself, through 10 different addresses.
And with the final address, I do an on-chain claim, showing that I have ownership from the highest priority possible.
06:42
if the claim isn't valid, the priority on it doesn't tell you anything
J
06:46
Josh
why can't the validators do this and give themselves all the value?
Z
06:47
Zack
if the validators assign value to themselves, they are just adding themselves next in line.
If you are first in line and you don't sign a waiver, then the value wont leave you.
J
06:48
Josh
but you might not know that they added themselves next in line
Z
06:49
Zack
if the validators refuse to reveal the merkle proof of your value from one of the on-chain commitments they had made, then you can't know whether they added someone new to the line or not.
06:49
and in that case you can't even do a final_spend_tx
J
06:50
Josh
ok, so the difference is that with validators, only validators can cause lottery risk, without validators anybody can
Z
06:50
Zack
if a merkle root has unavailable data, the validators aren't supposed to sign on it.
If even one validator refuses to sign, then this attack wont happen
J
06:52
Josh
yeah but that assumes you trust the validators not to cause lottery risk
Z
06:53
Zack
if all the validators work together, they can force you to have lottery risk. but this attack is not profitable for them, and they end up ruining their reputation, and any future fees they could have collected.
J
06:55
Josh
it's hard to prove it's not ever profitable for them
06:56
i wonder if there is some way to do a fraud proof that would show that somebody doesn't have a chain of signed ownership assignments going back to the creator of the sorition chain
06:56
it's basically a blockchain
Z
06:56
Zack
mimble wimble is kind of like that
06:56
the payments all collapse into each other
06:57
the history collapses on itself into something small
06:58
I was looking into a mimble wimble version of sortition chains at one point last year. I wonder why we decided not to do that.
06:58
did we decide? or maybe I gave up because it was complicated.
Z
07:02
Zack
So if we also keep a plaintext version of the number around, dies that mean we don't need range proofs?

Sortition chains are different because we are dividing up probability space. Each lottery ticket is a unique range of the space.

In mimble wimble you are recording values that are completely indistinguishable.
07:02
I guess we should review the mimble wimble plan again, now that we understand sortition chains so much better
J
07:04
Josh
yeah if we can somehow aggregate the ownership chain we might not need validators
07:05
or even get a fraud proof down to O(log n) of the number of previous owners
Z
07:10
Zack
In reply to this message
That would work too. I wonder if such a thing is possible.
J
07:15
Josh
this stuff is addictive but I better get to sleep, maybe you'll solve it by tomorrow 🙂
Z
07:17
Zack
If there is a better way to do sortition chains, I hope we figure it out before I go through the effort of implementing it and building a wallet and API and databases etc etc
07:18
mimble wimble is an application of pedersen commitments. Which is something you can do with elliptic curve crypto systems.
07:19
Maybe we should get a mimble wimble veteran in here for a couple days to find out if it is compatible with sortition chains.
J
07:21
Josh
I was just thinking that this is kinda like the rng proof. What if the sortition claim had to include log n checkpoint ownership records; you could keep asking for sub ranges until you got to the missing link
Z
07:21
Zack
it is a kind of partial homomorphic encryption that preserves addition, but not multiplication.

So, encrypt(5) + encrypt(7) = encrypt(12)
07:22
In reply to this message
like a binary search on the history.
An application of the truebit fraud proof idea.
J
07:22
Josh
Yeah
07:23
You always want to choose two breakpoints where the first is an actual owner and the second is a fake owner
Z
07:24
Zack
So, an ownership claim would include a number for how many other addresses have previously been in line for this value.
07:24
we know it starts with the creator of the sortition chain owning 100%, and their ownership proof has 0 previous owners
07:26
that is definitely something worth thinking about
07:29
I think it doesn't work.
If I want to spend some value, I would need to prove that I own it.
Merely showing a chain of ownership back to the creation isn't enough, because what if someone in my chain was spending value that they had already spent? then the whole chain is invalid.

The only way to prove that each spend in my chain was from someone who actually owned the value is if there are merkle roots on-chain, and I can show merkle proofs for the entire history of this value.
But the only way we can have on-chain merkle roots, and not suffer from data availability issues, is if there are validators assigned for each sortition chain.
07:29
so it would increase the cost of the fraud proofs from O(1) to O(log2(number of payments in the history of this bit of money)), and not provide any benefit.
J
07:36
Josh
The owners adding people to their queue would have to sign the merkle root; I would only accept payment from you if you gave me waivers and merkle proofs for the value from all blocks signed by any of the previous owners.
Z
07:38
Zack
if all previous owners need to have signatures on-chain, then it isn't really a scalability tool.
The signatures were already one of the biggest parts of the txs.
J
07:38
Josh
This assumes 1000 people can sign a message with O(1) space
Z
07:39
Zack
and if the signatures aren't on chain, how could you be sure if they didn't already spend the value before giving it to the person who wants to give it to you?
07:39
In reply to this message
then we need 1000 pubkeys on-chain. which is basically the same size.
J
07:40
Josh
The pubkeys don't have to be on-chain, they just have to match the pubkeys that signed the waivers
Z
07:42
Zack
if the pubkeys aren't on-chain, how can you be sure that someone in the chain of ownership didn't double-spend?
07:43
with sortition chains, you look at every merkle root on-chain that was signed by the validators for your sortition chain. for every merkle root you download a proof of the part of the value that you own.
This way you can be sure that you have the entire history.
J
07:49
Josh
Instead of looking for merkle roots signed by validators, you look for merkle roots signed by any of the previous owners of the value you're getting. I'm not sure if this is possible with multisig schemes, I'd have to look into that.
Z
07:51
Zack
if everyone who is spending value needs to sign a merkle root and record it on the main-chain, that is not scalable. they might as well put a tx on the main chain.
07:52
Well, I guess we could achieve something like optimistic rollup scalability that way.
Since the main-chain doesn't need to maintain any database for the sortition spends.
All we do is verify a signature and move on.
J
07:52
Josh
With multisig they all sign a big merkle root together and the sig is constant size
Z
07:54
Zack
we would need a coordinator to add all the txs for the next sortition block, and he generates a root, and then gets everyone to produce the signature.

If one person doesn't sign, then he needs to remove that tx from the set, calculate a new root, and try and gather signatures again.
07:54
I'm not sure if there is a threshold signature scheme with that property.
J
07:55
Josh
Yeah that's true but it's all off chain
Z
07:55
Zack
it could be a pain to make payments. because you can't be sure if you need to provide another signature or not. you need to leave your wallet online until there are on-chain confirmations.
J
07:59
Josh
It's pretty complicated, maybe there's a better way.
Z
07:59
Zack
What if some people do a multi-sign, and then refuse to reveal the data they had signed over?
Seems like anyone could do a data availability attack and make it freeze.
07:59
since the signature doesn't reveal the accounts that made it, we don't know who participated in making the merkle root.
08:00
so, anyone could have made it.
J
08:01
Josh
I'm assuming if you have a pubkey, you can check if that pubkey participated in the multisig but that might not be possible
08:01
I'll catch you tomorrow
Z
08:03
Zack
In reply to this message
The signature would need to be as big as O (# pubkeys) then for information theory reasons.
08:03
I think mimble wimble doesn't work with sortition chains because it can only encode values. It doesn't encode ranges of probabilistic value space.
08:05
I feel like I'm doing a thesis defense.
Answering all these varied questions about why it has to be designed this way.
Deleted joined group by link from Group
5 May 2020
Deleted invited Deleted Account
Deleted joined group by link from Group
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
04:38
Zack
hello new members.
Say something, or get banned.
M
05:24
Minieep21
bots are ruthless
Deleted invited Deleted Account
13:06
Deleted Account
Hi
Z
13:06
Zack
hi
13:07
Deleted Account
Whats the update admin
13:08
How to check veo coin and it's explorer
Z
13:42
Zack
depends which info you want.
13:42
lazy pool has a lot of good info
13:42
i
13:42
I mean lazy explorer
13:43
the light node has a lot of info too
13:54
Deleted Account
Which exchanger has high volume of trade admin.
B
14:08
Ben
you can find a lot of VEO for trade on Qtrade
Deleted joined group by link from Group
Ahsyeriee Shela invited Ahsyeriee Shela
5676734 shaji invited 5676734 shaji
6 May 2020
J
00:02
Josh
I'm still obsessed with the missing data attack. I wonder if there's a way to help a liquidator re-create the missing data in the merkle tree. If he had all the owner records he could do it but if was missing just one, he couldn't. Although if he was missing just one, other people could give him path pieces so he'd be able to re-create most of the proofs.
00:06
Some kind of probabilistic tree could help if the tree could be a little bigger but if you have 2/3s of the leaves you could figure out the rest.
Z
00:26
Zack
In reply to this message
The validators could publish a root and reveal nothing.
J
00:27
Josh
if i have all of the leaves of the tree, i have the whole tree
Z
00:27
Zack
Yes.
J
00:29
Josh
i think we can divide it into 2 cases: case 1, the validators just publish a root and don't release any data to anybody; case 2: they release data but not to everybody
00:30
there's another important classification: the root is a valid merkle root of an ownership tree; it's not a valid merkle root
Z
00:32
Zack
In reply to this message
Yeah, they could post random bits or a bitcoin block hash
J
00:34
Josh
but in the case that it's a valid tree, and > 50% of owners actually got their merkle proofs, that might be enough for the liquidator to find most of the proofs
00:34
with some erasure coding tricks we might be able to let a liquidator find all the remaining proofs
00:36
i don't know if it's possible to prove that the validator is publishing a bogus root
Z
00:40
Zack
Why would only some of the data be unavailable?
J
00:41
Josh
if they were doing an attack on just some of the people
Z
00:42
Zack
why would they do that?
J
00:42
Josh
why would they publish a random hash?
Z
00:42
Zack
we don't expect them to. it would ruin their reputation and they wouldn't get hired as a validator again.
J
00:43
Josh
right but people don't always do what you expect them to and lots of people will lose their money
00:44
it's also hard to think of all the interests in the world, governments and other chains could wish to sabotage the system
Z
00:46
Zack
Increasing the complexity of the software increases the number of ways that it can break.
We can only justify making the software more complicated if it results in a product that is more secure in the mathematical sense of trust theory. https://github.com/zack-bitcoin/amoveo-docs/blob/master/basics/trust_theory.md
00:47
preventing the validators from doing data availability attacks on less than 50% of the probabilistic value space doesn't decrease trust.
J
00:50
Josh
This is a 3.3 or 3.2 level attack; "if a blockchain mechanism has this kind of level of trust, it is usually considered a bug that needs to be patched"
00:50
having multiple validators doesn't change that
00:52
I don't consider this a viable design with that level of vulnerability. It's too early to talk about software complexity before we have any idea what the fix would be. All I know is that without a fix, I'm not convinced it can work.
Z
00:53
Zack
In reply to this message
it is level 3, but it is also a 1 of N PoS.
Normal PoS mechanisms are like 2/3 or 1/2.
1/N is a lot beter.
J
00:54
Josh
I don't trust any PoS, so that doesn't help me.
00:55
Also, that means that any validator can do a DoS attack on the sortition chain, which is another problem.
Z
00:55
Zack
they can freeze your money until the final_spend_tx
J
00:56
Josh
You'll still get your money but tying up millions of dollars for a few weeks has a huge cost.
Z
00:57
Zack
the sortition chains are recursive. each one can be small
J
00:57
Josh
and it doesn't have to be malicious, it could just be some server somewhere going down, somebody losing their private key, a company going bankrupt.
Z
00:57
Zack
like, each hub of the lightning network could be it's own sortition chain.
Each market for trading derivatives
J
00:58
Josh
then that reduces the on-chain scaling benefit, since you need an on-chain tx for every update of every chain
Z
00:58
Zack
you need an on-chain tx for every team of validators yes
J
00:58
Josh
if SCs are very small, there's not a lot of benefit in the merkle tree
Z
01:05
Zack
In reply to this message
How about we don't verify the signatures for any of these on-chain merkle roots.

light nodes verify the signatures when they sync the history of a sortition chain. and when we do on-chain claims of ownership, that is when we verify the signatures.

That way, the sortition block tx would take advantage of optimistic rollup style scalability.
01:06
so a sortition block tx is just a bunch of bytes that get recorded in a block.
01:07
We would need some kind of database showing that a particular merkle root had been recorded on-chain in a particular block height.
but signature verification at least could be lazy
J
01:11
Josh
which problem is this addressing?
Z
01:12
Zack
it would reduce the cost of all the on-chain merkle roots from the sortition chains.
01:13
so we could process bigger blocks faster
01:13
I wonder how many signatures my computer can verify in a second.
01:13
I think there is a way to use GPU for signature verification, but we want full nodes to be cheap
J
01:16
Josh
that could be an optimization but still if you have a lot of small SCs doing a lot of updates you're going to have a lot of on-chain merkle roots and that's going to take up block space
Z
01:17
Zack
block space isn't a problem. bandwidth is cheap
J
01:20
Josh
so why do we need merkle trees? we could publish all the ownership transfer records on-chain.
Z
01:21
Zack
like bitcoin?
01:21
oh, but with the probabilistic nature
J
01:21
Josh
yeah but you can do as many lightning style transfers over hubs as you want
01:21
it only costs money to add your hub
Z
01:22
Zack
so, like, the waivers would still be off chain
J
01:22
Josh
right
01:22
but this gets rid of the validator issue, no freezes, no lottery risk
Z
01:22
Zack
yes, this is an interesting idea. I need to consider it more.
J
01:23
Josh
it's also simpler (i think)
01:23
it'll take years to get to bitcoin level congestion and even then blocksizes can be bigger
Z
02:54
Zack
http://explorer.veopool.pw/index.php blocks stopped happening. a lot of miners have left.
Difficulty is dropping.
02:54
GPU miners might start being profitable if the difficult keeps dropping
03:02
Whoever was running the FPGA and turned them off, contact me and I will help you make a plan to mine more efficiently, so you can get the same rewards using fewer FPGA.
А
03:32
Андрюхин
is here any public pool yet ?
Z
03:35
Zack
yes http://explorer.veopool.pw/index.php this is a mining pool.
J
03:37
Josh
Just wanted to say the discussions here are really productive, it's exciting to talk about this stuff in real time. Thanks for making yourself available here, Zack.
Z
03:38
Zack
im glad to have your help
03:38
im still trying to wrap my brain around your most recent idea.
J
03:40
Josh
pleasure 🙂
03:40
Which part?
Z
03:40
Zack
In reply to this message
this one
03:41
I might need to sleep on it
03:42
if we could use OR tech this way, maybe we can use zk-rollups with sortition chains
J
03:42
Josh
the merkle tree is just a commitment to the leaves, so if we just publish the leaves we don't need to trust anybody to reveal the merkle tree information.
03:48
In reply to this message
can you explain more about how the optimistic rollup or zk-rollup would apply here?
Z
03:49
Zack
putting all this data on-chain to make sure it is available, that is the definition of OR.
and ethereum is doing a lot of work on zk-rollup to be able to do all the OR stuff with validity proofs instead of fraud proofs.
03:50
first we need to see if using OR this way makes sense, then we can look into whether it can be upgraded to zk-rollup
J
03:53
Josh
ok, so once it's on-chain which costs are we trying to avoid?
03:54
validation and storage?
J
04:32
Josh
If Alice wants to transfer a share to Bob, Bob will want to know that Alice owns that share. That means that Alice has a higher priority than everybody else that she doesn't have a waiver for. For Bob to know he's not missing anybody that might have a higher priority, he needs to check all blocks from the beginning of the sortition chain until Alice's block.

Next, Bob needs to check that there's nobody next in line before him that he doesn't know about. In order to check that, Bob needs to check all the blocks after Alice's block until now. So he needs to get all the blocks from the beginning of the sortition chain until now.

If Bob wins the lottery, he just needs to make a claim indicating the block where his ownership record is. If someone challenges him, they will have higher priority and he'll just need to provide their waiver.
04:34
If blocks are sorted merkle trees, we might be able to prove that there are no relevant owner transfers in a given block with a merkle proof. Then light clients could get both proof of existence and proof of non-existence of ownership records without downloading the whole block.
04:41
Maybe in Amoveo we don't need all the blocks, just their headers.
04:45
I think we also have to worry about a DoS attack where Charlie sees Alice publishing an ownership request to put Bob next in line and publishes his own request to put himself next in line. Since he would have the same priority as Charlie, this would block Alice from doing a waiver. So Alice would need to sign the ownership request. However, nodes wouldn't have to check this signature, since it's only relevant for the parties involved to check and for ultimate claims if someone wins the lottery.
04:47
Also, most of the records related to the sortition chain can eventually be pruned and forgotten by all nodes, unless they're related to the ultimate winning claim.
Z
05:01
Zack
In reply to this message
Great idea.
On-chain lotteries can have unused state pruned eventually.
05:02
In reply to this message
Doesn't this require Alice to sign 2 ownership transfers at the same time?
J
05:05
Josh
In reply to this message
Yeah, I just meant that we need her signature because of this.
05:06
this brings up the question of whether the blockchain should enforce a double spend by her
Z
05:06
Zack
I thought that was the plan. Get rid of the validator, and have people sign their own transfer requests
J
05:07
Josh
Yeah, it is.
05:08
it's actually not a double spend, it's just Alice putting Charlie before Bob
Z
05:08
Zack
In reply to this message
What makes or fast is that we get rid of the database that could be used to know if she has double spent.
The only operations allowed on the OR layer are lists of bytes that do nothing, and we can verify the hash of a sequence of bytes.
J
05:09
Josh
right, i think that applies, the sigs can be checked by the people who want to receive value
Z
05:09
Zack
Maybe requiring a gpu for a full node wouldn't be a bad thing?
Then we could do signatures fast.
J
05:09
Josh
and they can be checked at the final claim stage
Z
05:10
Zack
In reply to this message
Right, I think that part works.
J
05:13
Josh
if I'm Bob and Alice is offering me value from her SC, how would I go back and check all the ownership records related to this probability space? I'm already storing the full headers and the latest block, right?
05:13
Do I need to download any more data?
05:14
Do I store the headers or just populate a db and forget them?
K
05:22
K
Zack did you like nimiq?
Z
05:27
Zack
In reply to this message
In the current design, alice sends all that as part of the payment.
J
05:39
Josh
In reply to this message
But doesn't Bob have to verify that there aren't any ownership records she didn't tell him about?
Z
05:44
Zack
yes. in alice sends bob merkle proofs for every on-chain commitment from the team of validators in charge of that sortition chain.
J
06:00
Josh
so Bob would need to make sure he has all the txs from these validators, in case Alice didn't tell him about all of them
Z
06:01
Zack
yes
J
06:16
Josh
yep so in this case Bob would need to look at all the txs associated with this sortition chain
Deleted joined group by link from Group
Adam Hou invited Adam Hou
А
21:52
Андрюхин
H/R restored, diff dropped, but blocks are still very slow
Z
21:55
Zack
I don't understand
21:55
can you give more details?
21:55
if the difficulty was low, and hashrate was high, then blocks should be faster than 11 minutes each
А
22:14
Андрюхин
Can't post an image here. atm diff is 265.532 TH and hashrate came back to 31.12 TH/s. but blocks are still very rare (5 blocks for last 2 hours).
Z
22:14
Zack
you can DM me
7 May 2020
Deleted invited Deleted Account
Z
00:36
Zack
There is this girl who wants to make a short video about Amoveo and she is charging a good price.
So I want to make a script for what she should say in the video. I wonder what topic is most important.

Maybe a basic explanation of what is a financial derivative, and why it is a good idea to put them on the blockchain?
ŽM
00:38
Živojin Mirić
In reply to this message
so now you are paying for marketing?
Z
00:38
Zack
In reply to this message
The optimistic rollup plan would be nice, because we can get rid of the possibility that we would ever need to hold lottery risk.
But eventually bandwidth will become a bottleneck.
And it is hard for me to imagine how light nodes would work in that case.
00:39
I think that a level 3 attack in the case of 1 of N PoS is not a big deal, and for how much scalability we can get from that, it is a good compromise.
00:40
What is important is that the Nash equilibrium is for no attacks to occur.
00:40
In reply to this message
yeah, I am paying for marketing this once. It is a small experiment in a different strategy.
J
00:41
Josh
It also gets rid of the freeze attack, which only takes one bad validator.
Z
00:41
Zack
but, what would a light node even download?
00:41
does that strategy work at all?
J
00:42
Josh
I have to learn more about how Amoveo handles the consensus state.
ŽM
00:43
Živojin Mirić
In reply to this message
ban this dude, scammer
Z
00:43
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/consensus_efficiency.md according to my ideas about consensus efficiency, scalability and security are actually the same thing.
So there should be a way to mathematically calculate the relative consensus efficiency of the two designs, and prove that one is better.
J
00:44
Josh
It might even be more efficient than validators if you only have to look at the txs containing membership changes from the winning probability space, whereas with validators you have to look at all the membership changes that the validator does for everyone.
Z
00:45
Zack
In reply to this message
how can a light node look at txs at all?
00:46
In reply to this message
>with validators you need to look at all the membership changes that the validator does for everyone.
False.
Every time the team of validators makes a sortitoin-block-tx, you need a merkle proof of the part of the value that you own from there.
00:46
you only follow your own history, not anyone else's.
J
00:49
Josh
But what about someone who's looking at the history of coins the came from a sortition chain after the chain is finalized?
00:49
Somebody wants to send them that veo
Z
00:49
Zack
if the sortition chain is finalized, then someone got paid all the money as the lottery winnings. so now it is normal on-chain money.
00:50
you can use a normal spend tx.
00:50
or make a new sortition chain and spend inside that.
J
00:51
Josh
Yeah but you have to prove that history to yourself to know it's valid. That the person sending it to you is the real owner.
00:53
In reply to this message
I'm not convinced it's not a big deal. It's a level 3 attack. Now we're introducing more vulnerabilities like reputation that can centralize control and be used as pressure points by regulators.
Z
00:54
Zack
In reply to this message
she is attractive yes, but doesn't have experience with videos or blockchain. yeah, we should make a script.
J
00:55
Josh
The sortition chain idea is really cool but it's already scary to people that they'll have to sell off their lottery tickets before they become worthless. Now we also have to tell them there's a chance they won't be able to sell them at all.
Z
00:55
Zack
In reply to this message
hahaha, I don't think that is the right strategy
ŽM
00:55
Živojin Mirić
In reply to this message
so basically sex is selling Amoveo
Z
00:55
Zack
In reply to this message
the reputation is measurable, because we know the cost of making another sortition chain, and the cost of having money locked up.
00:57
In reply to this message
I think people who buy and hold will be using accounts on the main chain.
The sortition chain will be used for smart contracts with a lot of activity. Only a small fraction of your money at a time.
ŽM
00:57
Živojin Mirić
women are historically known for steering good stuff off course
J
00:59
Josh
In reply to this message
For most people in the world, what they spend each month is all their money.
Z
00:59
Zack
most people aren't using derivatives right now either
J
01:00
Josh
I'll read up more on the light wallet stuff, I need to understand that first.
01:00
They will be, stablecoin denominated wallets are the key.
01:01
That's going to be the rocket fuel.
Z
01:01
Zack
retirement attacks are a mixed solution kind of nash equilibrium.
As the fees get higher, the frequency of attacks gets lower.
01:02
but fees also go lower as scalability increases.
So if we have enough scalability, and if retirement attacks are low enough in profitability, then very low fees can prevent retirement attacks.
J
01:03
Josh
Low fees increase or decrease attacks?
Z
01:04
Zack
if we are looking at a situation that has retirement attacks, the frequency of attacks increases as the fees decrease.
J
01:06
Josh
So how do low fees prevent attacks?
01:07
Without validators there's zero attack surface for these attacks.
ŽM
01:08
Živojin Mirić
Josh I have to commend you for your immense contribution to the Amoveo project. Your name will be written in history when Futarchy becomes the only governance mechanism for the human race.
J
01:12
Josh
In reply to this message
Haha thanks but I'm probably just distracting Zack from actually writing the code.
ŽM
01:13
Živojin Mirić
this is more important than coding!
Z
01:13
Zack
In reply to this message
you are right. consensus efficiency theory doesn't apply here. the sortitoin chain can get attacked independently of blockchain consensus.
01:14
In reply to this message
No, you are very helpful.
01:17
In reply to this message
Well, maybe not.
Any system will have some attack it is weakest against, right?
J
01:18
Josh
right, so we always have to address the biggest vulnerability
01:18
according to your scale that's a level 3 attack
Z
01:19
Zack
is it level 3 though?
The loss of expected future fees is worth something
01:19
and they don't gain anything
01:20
the attack that worries me is if all N of the validators work together to freeze the money, and then they start buying it up at a huge discount.
01:22
If you only had 1 or 2 minutes to sell Amoveo, what would you say? Do we have an elevator pitch?
J
01:22
Josh
true, they're the only ones that can trust the transfer
01:24
In reply to this message
"In order to make a useful blockchain, you first have to understand why all the other ones are broken. Meet the Oracle."
ŽM
01:30
Živojin Mirić
In reply to this message
Amoveo is harnessing the power of futarchy with superior blockchain oracle technology for the benefit of the whole human race... or just to make money and make bets, whatever you like more.
Z
01:31
Zack
If you had lottery tickets for 1/100 chance to win $10 000. How much would a person need to pay you to buy them?
01:32
In reply to this message
most people don't know about "futarchy" or "oracles" or "blockchain"
ŽM
01:32
Živojin Mirić
you are confusing me
01:32
are we targeting all people or what
01:33
isn't an elevator pitch for potential investors?
Z
01:33
Zack
I guess we should choose a target audience.
Probably my twitter feed. So probably people who know what a blockchain is at least.
ŽM
01:34
Živojin Mirić
you can't target wide population with amoveo in this state, only products using it's tech in the backend can try to target wider population
Z
01:34
Zack
Economically speaking, 1/100th chance to win $10k is worth $100.
So I guess it depends on the average user's risk tolerance.
ŽM
01:35
Živojin Mirić
only way to attract regular joes is to market easy money to them
Z
01:35
Zack
In reply to this message
yeah, that makes sense.
01:36
the validators also probably don't want to hold lottery risk.
but maybe they can team up with a specialist who buys up all the tickets at the end, so they don't need to.
01:49
This is exactly the concept we're talking about with lotteries.
01:49
In the probability space it's worth $100 but if you're stuck and can't sell the ticket it could be worth zero.
01:55
New paper from vitalik, et al
Z
01:55
Zack
lots of people do buy lottery tickets, even if they aren't re-sellable.
J
01:56
Josh
In reply to this message
But they're not using them to buy groceries.
Z
02:00
Zack
I wonder if we could split it up into 2 layers.
So the current sortition design, instead of choosing a winning pubkey, we have it choose a winning integer.
And then we use some other decentralized scheme to make a database connecting integers to pubkeys.

That way if the sortition chain is frozen, you can still sell your value by changing which pubkey is assigned to your integer.
02:00
In reply to this message
im having trouble understanding the abstract. ill read it more and get back to you.
Z
02:17
Zack
In reply to this message
we could have N layers, each with only 1 validator.
So as long as 1 of the N validators is cooperating, it wont get frozen.

So if all N of the validators are working together to try and freeze money and charge a big fee to unfreeze it, any one of the validators could undercut the rest, and charge less.
It isn't a monopoly, because there are N different validators who can provide the same service.
02:29
In reply to this message
Amoveo blocks include merkle proofs for all the data you need to verify that block. this means that Amoveo is a stateless blockchain.
But our merkle proofs are pretty big. like, 80% or 90% of the size of the txs.
I think this paper is just about making the merkle proofs smaller. So at most, it is only a 10x scalability improvement on Amoveo.
02:32
In reply to this message
I think this strategy would prevent the attack where 1 of N of the validators stops cooperating.
But it makes data availability attacks much worse. because any one of the validators could cause a data availability attack.
02:33
I wonder if we could have sortition smart contracts with embedded oracles, and the oracles could say something about what data is or is not available.

That way you could have a payment conditional on whether the validators are causing a data availability attack.
J
02:52
Josh
In reply to this message
That's a cool idea.
02:54
In really bad cases it could be escalated to a fork
02:55
Although the validators could still withhold proofs from just some of the users
02:55
But in that case the regular liquidators could probably reconstruct the proofs
02:57
If I'm betting on the oracle, how do I know who the validators are withholding proofs from?
02:58
Are they supposed to publish all the hashes of the merkle tree to some website?
03:02
I think the oracle would have to be about whether they published the valid tree to website X, not whether they published a valid root.
Z
03:08
Zack
In reply to this message
We only need to make the Oracles on chain for the lottery ticket that actually wins.
03:08
But I guess by that point, it doesn't matter if the data is available or not.
03:09
Since trading has ended.
03:20
doesn't exist
Z
03:26
Zack
Thanks for the heads up.
03:49
where did you see the dead link?
03:50
its weird, because the links look the same. but mine isn't dead.
03:50
dominant assurance contracts
J
03:50
Josh
His is in the design directory
Z
03:50
Zack
oh, thanks
03:52
got it
J
05:32
Josh
So a light node checks it's account balance by getting the roots hash from the latest header and then asking for the account record along with its merkle proof?
Z
05:33
Zack
yes, that is how it works now
05:46
im working on the elevator pitch.

Derivatives are a powerful financial tool used for insuring against risk, and communicating your future needs to the world.

Today, the majority of people are locked out of these powerful tools.

Blockchain is the technology that powers bitcoin. With blockchain, you don't need anyone's permission, and no one can be excluded.

We are putting derivatives inside of a blockchain, that way everyone will have access.
J
05:56
Josh
In reply to this message
are you planning on changing that?
Z
05:57
Zack
if you are looking up a balance in the sortition chain, it would work very differently
05:57
you would sum over all the probabilistic value space proofs in your database
J
05:58
Josh
In reply to this message
I think some examples for the regular joe would be good. Stablecoins for people in countries with weak currencies is a big one. Billions of people are used to having to deal with foreign currencies because they don't trust their home currency.
Z
05:59
Zack
the changes that blockchains are going through kind of reminds me of the history of the internet.
It started with the computation happening on servers, and over time, more is happening in the browsers instead.
J
05:59
Josh
Sports betting is another popular one.
Z
05:59
Zack
In reply to this message
yeah, stablecoins is a good one to mention.
05:59
to go into details about "insuring against risk"
05:59
sports betting is popular too yeah
J
06:03
Josh
In reply to this message
so the header has a hash of a merkle root of all the sortition ownership trees?
Z
06:05
Zack
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/trees/trees.erl#L163
This is where we take the roots of all the different merkle trees, and take the hash of them all, to make one merkle root for all the data for that block.
06:05
it goes into the header
06:06
J
06:11
Josh
In reply to this message
I think it's about making the verification faster, not making the proofs smaller
Z
06:12
Zack
does it take long to verify a merkle proof?
06:12
we can do sha256 so fast now
06:14
5 million times per second per CPU.

and if you have N users, the proof is only log2(N) many hashes.
or, with the binary tree plan ethereum has, if you are willing to make the proof M times bigger, you only need log(N)/log(2*M) many hashes per proof.
J
06:15
Josh
yeah i didn't understand the issues yet, they also reference this: https://eprint.iacr.org/2018/968
Z
06:16
Zack
Elevator Pitch
===========

Derivatives are powerful financial tools.

Derivatives are used to insure against risk.
For example, if your local currency is unstable, you can use a derivative to protect youself from the possibility that your currency will lose value.

Derivatives are used to communicate your future needs.
For example, if your restaurant sells a certain amount of beef every month, then you can use derivatives to communicate your beef needs ahead of time, this allows you to buy at a better price, and it helps the cow farmer to plan.

Today, the majority of people are locked out of these powerful tools.

Blockchain is the technology that powers bitcoin. With blockchain, you don't need anyone's permission, a\
nd no one can be excluded.

We are putting derivatives inside of a blockchain, that way everyone will have access.
06:26
In reply to this message
they dont like amoveo's design.
Because if you want to spend value to someone, verifying that tx requires a merkle proof of their current account balance.

In amoveo, besides accounts we also have oracles and channels and sortition chains etc.
And each tx can need a bunch of different proofs.

It seems like they are very focused on the application of account to account spending, and they are optimizing for this one thing completely.

It is important to know that the merkle proofs do not need to be inside the signed part of the tx.
So the tx can be signed first, and then sent to a specialist who keeps a record of the necessary merkle proofs. They can attach the proofs and publish it.

In fact, it is important that the merkle proofs are not in the signed portion. because if txs are sitting in the mempool and don't get included, then we need to update the merkle proofs for these txs when we sync more blocks.
J
07:00
Josh
In reply to this message
Getting there but I still think it's too abstract. The S&P 500 stock index is a derivative. With Amoveo your wallet can hold an S&P 500 portfolio, or US dollars, or bars of gold, no matter where you live in the world. And you can send that value instantly, to anyone in the world. You can play fair lotteries, bet on football games or try your hand at predicting the future.
Z
07:00
Zack
In reply to this message
Thinking more about this.
How about if every waiver references an Oracle saying that the waiver is only valid if all the following sortition root hashes are available.

And we also have some sortition explorers that anyone can submit a query to, and the Explorer checks if the data is available. And it is a public record of what dat is available at what times.

Anyone can easily check if the current data on the Explorer is valid, and the Explorer can make root hashes into the blockchain to prove that it doesn't manipulate historical data.

Then, the Oracle would be able to know what data was available at what times.
07:01
In reply to this message
Those are good examples. Though we don't have lotteries yet.
MF
07:02
Mr Flintstone
you could probably write a vdf into an oracle lol
Z
07:03
Zack
In reply to this message
Well, you could ask an Oracle for one bit of the result of the vdf.
MF
07:03
Mr Flintstone
yeah thats what i mean
Z
07:03
Zack
If you had 256 oracles you could get the whole hash of of the version we have written
07:04
That would be pretty intense if all 256 went on-chain
MF
07:04
Mr Flintstone
couldnt you just ask if it was above a certain #?
Z
07:04
Zack
The most tx volume ever
07:04
You can ask anything about the random value
J
07:05
Josh
In reply to this message
Maybe talk a bit about all the middlement and gatekeepers we have now. Amoveo doesn't have clearing houses, brokers, prime dealers, correspondence banks, accredited investor restrictions. Amoveo cuts out the middlemen and their scandalous fees and their long delays. Amoveo isn't just open to millionaires and US citizens, Amoveo is for everyone.
Z
07:06
Zack
Yeah that is good too.

There is so many good things to say about the tech, it is hard to know what to put into a short explanation.
J
07:07
Josh
I think it's easiest for people to understand when it's about concepts they're already familiar with and problems they have on a daily basis.
07:08
In reply to this message
Yeah so the oracle question would be something like: "all hashes of the merkle tree for sortition ID X, were on site xyz with an uptime of 90% between date Y and Z."
07:13
If this works it's a really interesting solution to the missing data problem.
07:24
I also think everybody doing their own signed ownership transfer records still works. Wouldn't the miner just take the tx and put it in the merkle sortition tree just like he does with account txs?
Z
07:29
Zack
In reply to this message
If he builds the tree like accounts, then it has no scalability benefit over normal on-chain payments.
J
07:39
Josh
There are two advantages; 1) once a other has added people to the queue, all subsequent txs between them are off-chain; 2) only the currently active sortition trees need to be maintained
07:39
These are huge advantages
Z
07:41
Zack
1) we already have this with channels.
2) we can already prune almost everything. Especially once I activate the update for syncing blocks in reverse order.
J
07:46
Josh
So maybe that's good enough scaling for the foreseeable future. Is it really worth all the complexity and risks of sortition chains at this point?
Z
07:51
Zack
scalability is the same thing as price. we want to undercut the competition
07:53
the bigger we get, the harder it will be to make changes. it would be nice if we could go global without having to make any major changes.
J
07:57
Josh
That makes sense. I think we need to analyze the scaling gains carefully though. The bottlenecks are verifying sigs and keeping structures in RAM?
07:57
Gotta head to bed but there were definitely some interesting ideas like the oracle.
Z
08:32
Zack
it is hard to be certain of the bottlenecks before testing it out.

Currently, while syncing, some amoveo nodes are bottlenecked by bandwidth, and other's by hard drive, since they are storing a copy of the full merkle tree by default.
We are using very little ram. like 150 mb or something like that.

Besides while syncing, we are really far from hitting any bottlenecks.

With the design in the sortition branch, I would guess that the bottleneck would eventually be when there are too many teams of validators competing against each other.
mx
13:36
mr x
In reply to this message
Yeah it should be about examples that make amoveo investors free and powerful! Show how you can hold s&p500 pseudonymoysly without tax consequences... makes bets about ANYTHING... and unlike others this is secure and scalable! Maybe don't even mention that xD.
J
17:53
Josh
In reply to this message
This can somewhat be controlled by limiting block size and frequency.
S
17:59
Sebsebzen
Btw, I've been away for a while, did I miss anything?
17:59
Would be nice to have summaries, like monthly dev updates, so I could follow without having to browse through 6000 unread messages here haha
18:01
it's been a while
Anna Karimova invited Anna Karimova
Z
20:25
Zack
So the attack I think could actually prevent sortition chains from working, is if all the validators team up to freeze some value, and then they buy it up at a discount.
This could potentially be a level 4 attack.

If this attack does occur, we can see it happening, and the sortition chain will take a long time to finalize.
We could do a hard update to delete that sortition chain, and prevent the attackers from profiting.

But it would also punish a lot of bystanders who just happened to have money in it.

If all the validators worked together, they could cause a bunch of money to get destroyed, but that is only a level 3 attack, not level 4.
20:28
In reply to this message
this idea was backwards.
We don't want to invalidate waivers, we want to prevent anyone new from being put into any lines, that way final_spend_tx can work.
Z
20:44
Zack
I think the problem with our sortition chain design is the same as the problem with most oracle designs.
We are layering different consensus mechanisms on top of each other.

Our oracle is effective because the underlying Nakamoto consensus is the oracle consensus mechanism as well.

So, if we can find a way to use the underlying Nakamoto consensus for sortition chains instead, maybe that could solve this.
20:48
I hope we aren't suffering the sunk cost fallacy here.
mx
20:52
mr x
just use oracle to say how money should be divided xD
Z
20:58
Zack
each oracle is only providing one bit of information
20:59
maybe something like that is possible, if we use the oracles carefully
mx
20:59
mr x
oracle says this is correct merkle root for withdrawal from sidechain
Z
21:00
Zack
yeah, that is a one bit question
21:04
the fact that: <data was available at a certain time> this fact can be public data.
And the oracle can put any public data on-chain.
21:05
So if we say "This merkle root on this hash was the first one that did not have data available"
And the oracle responds "true"
Then we can know to disallow any merkle proofs based on that root, or any other roots that came after.
mx
21:05
mr x
it is up to sidechain provider how public he wants to be about all the balances and withdrawals and how often
21:06
if something goes wrong just go with the latest
Z
21:06
Zack
the idea is that some customer would not be able to get the data he needs, and that customer's wallet would release a warning, and then other people would check if that data is available, and if not, then the sortition chain should freeze.
mx
21:06
mr x
insanely simple side chains xD
Z
21:07
Zack
but a tool like this, it seems like it could be used to undo a lot of sortition chain history.
21:08
so you would need a lot of time before you could accept that you were actually put in line to own some value in the sortition chain.
21:14
there would be some timelimit, like 1 hour. we refuse to undo more than 1 hour of history, even if an attack did occur.
you would need to come online at least once per hour and check the proofs, but this doesn't require your private key, you could hire a 3rd party to provide this service.
And you would need to wait 1 hour before you could trust that you were actually put in line to own some value.
So, close/opening channels or hubs would take a full hour.
21:18
As for programming, this would actually be pretty easy to do.
we would need add a special version of the oracle that can only ask about data availability in sortition chains, and when it is settled, it updates the sortition object to have a height limit, after that height, no more on-chain merkle commitments are valid.
21:19
so then, the final_spend_txs would be enforceable.
21:20
an interesting side effect.
Since everyone needs at least 1 hour of confirmations anyway, the sortition operators don't have any reason to post the merkle root on chain more than once per hour.
21:21
I think if we did it this way, we could switch back to having one validator per sortitionchain.
21:22
because we only had multiple validators to reduce the frequency of data availability attacks.
21:27
If we only need one validator, that will save me from having to write a lot of code.
The protocol to have them agree on what to sign next would have been a lot of work.
Z
21:42
Zack
It would feel nice to say "the same Nakamoto consensus is used for double spending, the oracles, and all the side chains.".
mx
21:42
mr x
yeah!
Z
21:43
Zack
I asked the drivechain guys if oracles can be used this way.
mx
21:43
mr x
haha would be too easy??
21:46
why make oracles make statements about facts if u can just make stamenet about how money should be divided
21:49
just code your contract in natural language
Z
21:49
Zack
Practically speaking, I think both questions are identical.
I'm just saying the long version so it is more clear what the Oracle is accomplishing
21:51
This kind of oracle won't have a text question anyway.
We need it to be more parseable for the blockchain to verify the sortition claim txs.
21:51
So it will just have a sortition id , and a block height of the last valid merkle commitment
J
22:03
Josh
after a merkle root is published by a validator, everybody will immediately know that the data is available, so they should have confidence that the oracle will eventually converge on that answer and it's safe to receive the funds.
Z
22:05
Zack
It could take time for the complaint to spread and everyone to verify that it is valid.

Each sortition chain needs some hard limit for how many blocks of history it is willing to undo if an attack like this happens.
22:06
What is this hour period even measuring though?
Since the Oracle takes at least a week to settle.
22:06
I guess whoever makes the complaint needs to store a hash of the complaint in a block so it is time stamped
22:07
Each level 1 sortition chain can only get attacked like this once. So it isn't a scalability issue if they need to post the complaint on-chain.
22:08
But I wonder about if the sortition validators were messing with their users, making data temporarily unavailable, to trick them into complaining for nothing.

So the system wastes time checking on data that was available all along.
J
22:09
Josh
i think they would have to publish the full tree
22:09
so that everyone can validate the full tree
Z
22:09
Zack
Publish it means what?
It's too big for everyone to download all that
J
22:10
Josh
only the people challenging the oracle would have to download it
Z
22:10
Zack
I don't see why they need the full tree
22:10
If no one made a complaint, then it doesn't matter
J
22:10
Josh
you can only guarantee full availability for the oracle question if you check the whole tree
Z
22:10
Zack
Full availability isn't a requirement.
J
22:11
Josh
but you want to know immediately that the oracle will be on your side
Z
22:11
Zack
We just want to make sure all the customers are being served
J
22:11
Josh
so you feel confident in accepting the payment
22:11
the question for the oracle is whether the tree is fully available
22:12
btw, this can be done more efficiently with that coded merkle tree
Z
22:12
Zack
The design you are suggesting is the same scalability and tx finality speed as normal bitcoin

It is better to need 1 hour to open a channel, with the benefit that we have infinite scalability.
J
22:13
Josh
but that adds a lot of UI issues
Z
22:13
Zack
The whole point of sortition chains is that each user tracks their own proofs, so we don't need a central database.
22:13
That is why it is more scalable
J
22:14
Josh
the tree wouldn't be on chain though
22:14
before you said you expect the trees to be small, do you expect them to be huge now?
Z
22:14
Zack
For data to be public, it needs to be easy for anyone to look it up.
J
22:15
Josh
it's easy to look up, it's just not easy to know that you will be able to look it up
Z
22:15
Zack
I want to process at least 100k tx per second. So that means 100k sortition updates per second
22:15
Well, maybe each channel can have like 10 txs on average.
J
22:15
Josh
why only 10 tx?
22:16
if you have hub and spoke channels you could have hundreds of txs
22:16
or thousands
22:16
all off-chain
Z
22:16
Zack
Idk, what would you guess?
Sure hundreds are possible.
Trillions are possible.

But we need to consider what customers actually want. Not a theoretical pair of people that send the same money back and forth millions of times per second.
J
22:17
Josh
yeah, it depends on whether people get their income on the channel
Z
22:17
Zack
A derivative contract that only stores 1 cent or only lasts for a millisecond, it isn't useful for anything
J
22:18
Josh
if i get my income on a channel and all my expenses are on the channel, pretty much all my txs get cancelled out
22:18
if i'm a store and my suppliers and customer are on a channel, same thing
22:18
but the tough part is migrating up to that
Z
22:18
Zack
If you are getting income by channel, and paid every 20 minutes, you don't want to tie up your employers funds unnecessarily.
So you would open and close another channel every couple of hours.
22:19
If you are shopping, you don't need more money in the channel than you will spend in the next hour.
22:19
If you are running a store, you don't need more money locked on the hubs side of the channel than what you expect to sell in the next hour.
22:19
We don't want to lock up liquidity unnecessarily
J
22:19
Josh
the money isn't necessarily "tied up" if that's how everyone is paying
22:20
you need it tied up in the channel to do anything with it
Z
22:20
Zack
The hub would rather use the liquidity to serve someone who actually needs to use it now
22:20
So if you are sleeping, and not being anything for 8 hours, you should close your channels and let the hub serve other customers.
J
22:21
Josh
it depends on how much it costs to open and close channels
Z
22:21
Zack
Closing and opening channels is free in sortition chains, so we shouldn't be shy to do it a lot.
22:21
But locking up liquidity is as expensive in sortition chains as it always is.
J
22:21
Josh
but getting into a sortition chain is an on-chain tx
22:21
and it's tying up funds
Z
22:22
Zack
Almost no one will ever have value outside of the sortition chains.
J
22:22
Josh
so why wouldn't I just tie up those funds in a channel instead?
Z
22:22
Zack
Only people who win lotteries, or want to participate in an Oracle.
J
22:22
Josh
why can't we just say everyone will have their money in channels?
Z
22:22
Zack
Channels are not scalable.
22:22
Sortition chains are.
22:23
Doesn't really make sense to talk about channels that aren't inside the sortition chain.
J
22:25
Josh
hmm, if i have all my money in channel with my hub, the difference between that and having all my money in an SC is that the hub will need to lock up capital for me for the channel but not for the SC.
22:25
Is that the difference?
Z
22:25
Zack
In reply to this message
why is that? I don't think that is the case.
22:26
In reply to this message
you don't pay for the money on your side of the channel. you pay for the money locked on the other side.
J
22:26
Josh
that's what i mean
Z
22:27
Zack
there is no one who needs to maintain a full history of the entire layer 1 sortition chain.
And the fact that people want to store money in channels is totally unrelated.
J
22:28
Josh
but can't you do the same thing as a sortition chain without the random part? i can add the hub to my queue for free, I can send a waiver for free, I can buy a piece of the next chain for free.
Z
22:28
Zack
idk what you are asking.
22:28
is this about the RNG?
J
22:29
Josh
yeah, why does it all have to go to one person in the end. since you need an on-chain tx to buy into the SC, how many on-chain txs are we really saving?
Z
22:31
Zack
an entire layer-1 sortition chain has 5 on-chain txs
1 to create it.
1 to post the rng result
1 to for the timeout of the rng result
1 to make the claim that you won.
1 for the timeout and withdraw of the winners funds.

This sortition chain could have trillions of descendents, and each descendent can process at least 10 txs per second for opening and closing channels.
22:32
oh right, we need all the sortition merkle commitments
22:33
So, lets say that it has 1 per hour, and lasts for a month. 720 txs. those ones are really small too.

So in total, like 725 txs for the sortition chain.
J
22:35
Josh
How do I buy a piece of the sortition chain from the owner? If I only have on-chain funds, that's an on-chain tx.
22:36
So I guess we're assuming most people won't be getting funds via on-chain accounts, they won't even have an on-chain account, they'll just get pieces of sortition chains?
Z
22:36
Zack
do an atomic swap from a channel on another blockchain.
Pay someone in cash who already has money in the sortition chain.
Use an exchange that supports withdrawing funds to inside the sortition chain.
22:36
right. most people never have an on-chain account.
J
22:37
Josh
if i win the lottery do i need an account? can i create it only if i win?
22:37
if i win i'm probably a liquidator so i'll probably already have an account.
Z
22:38
Zack
im pretty sure it gets created and the winnings deposited to it.
It depends on some decisions we need to make about the sortition_claim_tx.
Maybe only the person who won should be able to make that tx, to prevent some kind of spam.
22:39
and you need to pay a tx fee to publish that tx.
22:39
if you are guaranteed to win $1000, I think you will be comfortable paying a $0.10 tx fee in order to claim the winnings.
J
22:40
Josh
it could be more, but the point stands
22:40
but that $0.10 has to come out of the $1000 winnings as part of the tx, since I don't have an account with $0.10 in it
Z
22:40
Zack
even if you don't create an account, you need to pay someone to publish the sortition_claim_tx
22:41
so, 2 $0.05 fees then. one to create the account, and one to claim the winnings.
J
22:41
Josh
I can pay someone with SC funds, but I can't necessarily pay an on-chain fee with SC funds
Z
22:41
Zack
creating the account is cheaper
22:41
if you publish a false claim, and someone else publishes the correct claim, then you should get reimbursed.
J
22:42
Josh
oh right, i'm not guaranteed to win when i publish the claim, so the fee can't be deducted from the SC value
22:43
so I need to pay someone with SC funds to publish the claim and pay the fee
Z
22:43
Zack
at this point the sortition chain has halted trading.
you could pay them in some other soortition chain that is still active.
J
22:44
Josh
anybody doing any kind of on-chain challenging needs to have an account or pay someone with an account
Z
22:44
Zack
yes
J
22:44
Josh
In reply to this message
right
22:46
back to the oracle, the bet is that nobody will be blocked from getting their proof during an hour?
Z
22:47
Zack
no.
If they don't complain, then we should not freeze.
J
22:47
Josh
so what's the bet?
Z
22:48
Zack
we only freeze if someone is locked out, and they complain, and it becomes common knowledge that someone's account is unavailable. and we freeze it at either 1 hour before it became common knowledge, or before the merkle commitment that had unavailable data, whichever comes second.
22:49
it is really weird, reasoning about what we know about what we know
22:49
English doesn't have grammar for this
J
22:50
Josh
the oracle has a 1 bit bet right? so we should be able to state what we're betting on.
Z
22:50
Zack
what?
22:50
each oracle responds with either true, or false, or "bad question"
J
22:51
Josh
if i'm betting on the oracle, in what situation do i get a payout?
Z
22:53
Zack
if you are honest, and your bet was matched
22:54
potentially the blockchain could fork into honest and dishonest versions.
If you are honest, then you get paid on the honest side, and you lose your money on the dishonest side.

So the oracle mechanism is a way to do 1:1 swaps to put your money on the side of the fork that you think will be more valuable.
J
22:58
Josh
right, i mean what's the bet for this specific oracle that determines whether to freeze the merkle root tx
Z
23:00
Zack
is block height H the earliest height that meets this condition:
if someone is locked out, and they complain, and it becomes common knowledge that someone's account is unavailable. H1 is 1 hour before it became common knowledge. H2 is the time when the merkle commitment had missing data. H = whichever is later(H1, H2).
23:02
but we don't need to write it all out in english.
We will have an alternative way of making oracles for this purpose, so it is more parse-able for using to update the sortition chain.
J
23:21
Josh
don't we need it in english to that people can know what they're betting on?
Z
23:21
Zack
the UX can stick whatever words are convenient in
23:21
not everyone reads english
J
23:21
Josh
by english i mean human language
Z
23:21
Zack
sure. the wallet has lots of instructions in human language
J
23:21
Josh
yeah
23:22
so more practically, if i want to bet on this oracle, i see someone complaining somewhere that he can't get a proof for hash X, so I go to the website and ask for the proof for hash X
23:23
I keep doing that for all the complaints
23:23
if I'm able to get them all at the end of the hour, I can bet that the data is available
Z
23:24
Zack
when someone isn't able to access a proof for the data they need, the wallet automatically sends this complaint to explorers that watch for unavailable data.
anyone can audit the explorers for their current data, and the explorers publish merkle roots so they can't edit their historical data.
oracles look at the explorers to decide when data was available.
23:27
if you want to do a final_spend_tx because of a data unavailability attack, then someone needs to create the oracle for this sortition chain, to invalidate the unavailable date.
J
23:28
Josh
so the explorers have the full tree from the validator?
Z
23:29
Zack
no. when they get complaints, they request the data from the validator to see if it is available.
23:29
if it is available, then they drop the complaint and don't need to store anything.
23:29
if it is unavailale, they only need to remember one unavailable fact per sortition chain, at most.
J
23:30
Josh
do we even need a designated validator? what if anyone can post a merkle tree on chain?
23:30
merkle root
Z
23:31
Zack
if I post 256 bits of randomness and claim it is a root, then all the data will be unavailable, and that sortition chain freezes.
23:31
everyone needs to wait for a final_spend_tx.
23:32
we need a validator to be able to put new people in line to own sortition value.
J
23:33
Josh
if everybody knows the data is unavailable, they can disregard it because it will eventually be voided
Z
23:34
Zack
what?
23:35
the oracle only gives one bit of information. it can tell us the earliest height when data started being unavailable.
J
23:35
Josh
somebody posts a bogus root, i request my proof and can't get it so I make a complaint, the explorers all say that the root is bogus
23:35
ok, so the problem is you'll need an oracle for each bogus root
23:36
instead of just one oracle per SC
Z
23:39
Zack
we want the on-chain cost of enforcement to be finite.
If the validator can cause us to need to make hundreds of oracles, that would fill up blocks.
23:40
if the validator is only being punished once, then everyone who was hurt by the attack can pool their resources, so it is cheap to show that the validators is attacking.
23:41
if every commitment needed a different oracle, then they couldn't pool their resources effectively, everyone is being attacked individually and needs to fund their own defence.
23:42
And why would we want to continue using a validator who is harming users? They should be fired immediately, so they stop getting paid fees.
23:43
it would be nice if we had a way to prevent the sortition chains from freezing at all.
23:45
publishing a sortition root is a very small tx.
Making the oracle to show unavailable data is bigger.
23:46
maybe if the sortition root tx had a big enough fee, then making the oracle that shows it is false could be free. or, it could at least have it's fee refunded, in the case that the result of the oracle shows that the root was wrong.
23:51
Sometimes having a clause in the contract that causes everyone to lose can be a good thing.
Like the japanese rules for the game of go, it is possible for both players to lose.

If we only undo sortition roots where there is unavailable data and someone complains, then there can't be a big punishment for whoever is making the unavailable data. Each merkle root commitment is it's own deal.

If there is one validator who is making claims for an entire chain of updates, then we can tie all these claims together, and allow for a bigger punishment when they try to cheat.

It would be nice if we could use math and calculate the relative costs of these strategies.
8 May 2020
J
00:20
Josh
what are the costs for doing an oracle?
Z
00:21
Zack
3 on chain txs.
create it.
report the result.
close it after the timeout.
J
00:22
Josh
ok, so that's only 3x as much as the root update
00:22
it's still constant factor
Z
00:23
Zack
if you don't know which merkle commitments are valid until much later, then as soon as one of them has questionable validity, it makes the whole thing really complicated.
J
00:24
Josh
In reply to this message
every commitment would need to be for the full merkle tree anyway, so publishing a bogus root is attacking everyone
Z
00:24
Zack
if we can just freeze it, then it has a simple result. everyone waits for the final spend tx.
00:24
validators can publish a valid root and simply refuse to reveal part. it doesn't have to attack everyone.
00:25
if there are a bunch of roots published in a row, all with questionable validity, it becomes a confusing situation.
J
00:25
Josh
but the explorer would still know that they are cheating and that it's a bogus root
00:26
the explorers have to clearly know if it's a bogus root in order for the oracle to work
Z
00:26
Zack
there are edge cases where it isn't clear whether we should consider it a data availability attack or not.
00:26
this attack can happen even if the root is good.
J
00:26
Josh
that's why we give the validator a time period to reply
Z
00:26
Zack
it is about refusing to reveal things that the root can prove.
J
00:27
Josh
if they don't reply in that time period we consider it a malicious attack
Z
00:28
Zack
sounds like you are assuming that the fact of whether they reply, that fact will be available.
00:28
do I know that you know, that I know, that you know...
00:28
meta meta meta knowledge
J
00:30
Josh
it will be because the explorer will give it to me
00:30
i don't ask the validator for my proof, i ask the explorer
Z
00:31
Zack
if anyone's data is unavailable, then the entire root needs to be undone.
J
00:31
Josh
right, it needs to be voided
00:31
nobody will rely on it until it's trusted
00:32
it's trusted if after an hour there have been no valid complaints
Z
00:32
Zack
so you don't ask the explorer for data. you ask the explorer if a validator is attacking or not. and if they are, you ask the explorer for which portion is being attacked. and then you ask the validator to provide that portion.
00:33
if the validator refuses, then you have confirmed an attack is happening
00:33
if the validator gives you the data, then maybe the explorer is lying, or maybe the validator stopped attacking.
J
00:34
Josh
that's true for an oracle better; but if i'm sending money on the SC I ask the explorer for my proof
Z
00:34
Zack
the validator is the one who maintains the database that can produce your proof.
00:35
the explorer is just for knowing which sortition chains are being attacked
00:35
so the explorer is constant sized based on the number of sortition chains it is observing .
J
00:35
Josh
well, I could ask the validator first but if he doesn't give it to me, I report him to the explorer
00:35
if he gives it to the explorer, the explorer give it to me
00:35
there's not much difference
Z
00:36
Zack
if the explorer was maintaining a copy of the entire sortition database, like the validator has, then the explorer's memory would grow with the number of channels in all the sortition chains it observes. that is not the behaviour we want.
00:36
we want the memory cost on the explorer to be linear with the number of sortition chains it is observing.
00:36
Something like 1000 bytes per sortition chain.
00:37
the key for one value which is unavailable.
00:38
It is like, when you look up the results of a basketball game, they don't maintain a precise computer simulation of the entire game occuring.
They just record the final score.
J
00:39
Josh
the explorer doesn't need to store the whole db, he just has to forward the requests to the validators
00:39
it's just a question of optimistic vs pessimistic
Z
00:39
Zack
what requests?
He just stores a record of what data is unavailable and when.
00:39
people only request to know what data was unavailable, and when
J
00:40
Josh
ok, so i ask the validator for my proof and he doesn't give it to me
Z
00:40
Zack
then that validator is attacking.
J
00:40
Josh
i report it to the explorer, the explorer asks for it and the validator gives it to him
00:40
who do i get it from?
Z
00:41
Zack
the explorer is using the same api that you are using. if they can download it, then so can you
00:41
its not like you are sending a signed request
J
00:41
Josh
unless the validator knows who the explorer is
Z
00:41
Zack
the explorer isn't signing requests either
J
00:42
Josh
why should the validator provide records to everyone? he could get DoSed
Z
00:43
Zack
this is what the validator is paid to do.
Stick new people in line, and provide proofs that they did.
J
00:43
Josh
only to the people who need the proofs
00:43
otherwise i can attack him with a botnet
Z
00:43
Zack
if the botnet is paying for the proofs, that isn't an attack.
J
00:44
Josh
so the validator can make the price very high so that only the explorer can afford it
Z
00:44
Zack
no one would use that validator.
00:44
the validators are in competition with each other to provide service for a good price
J
00:45
Josh
this would be part of an attack
00:45
if we were trusting validators to provide a good service we wouldn't need oracles
Z
00:45
Zack
if you can't afford to move your money, it is the same as any other way of freezing your money.
You need to wait for the final spend tx.
00:46
and everyone can see how high the price is now. so they wont use this validator in the future.
00:46
it is the same as if they just refused to publish any more roots.
J
00:46
Josh
anyways this isn't an attack, i'm just saying there's no reason the explorer shouldn't relay the proof to someone who reports that they can't get the proof from the validator
Z
00:48
Zack
they can return it all in the same request sure. doesn't really matter.
J
00:51
Josh
sounds pretty good, the remaining question is whether we can avoid freezes
Z
01:23
Zack
In reply to this message
I think the freezes aren't an issue. It isn't profitable for the validator.
We can have shorter lasting sortition chains, so you get the money out sooner.
J
01:35
Josh
don't we need long sortition chains for bets that take a long time?
01:36
also if I can't change my bet during that period I could lose money on the bet even if I eventually get my money back.
Z
02:21
Zack
yeah, we would need longer sortition chains for bets that take a long time.

Even if your bet gets frozen, you can hedge this risk by betting the opposite way in other sortition chains.
02:23
Also, as long as some market exists in a long-term sortition chain, then that market will have a price.
We can bet on that price from inside the short sortition chains.
J
03:50
Josh
So you'd have a lot of separate bets on different sortition chains with the exact same question?
Z
03:50
Zack
yes
J
03:55
Josh
The problem is we don't want too many validators because that reduces scaling but if one validator goes bad that can freeze lots of SCs
Z
03:57
Zack
if the average validator does one commitment per hour, and we can do 20 txs per second, and there are 3600 seconds per hour, that is like 72000 validators.
J
04:27
Josh
Yeah but we still have to worry about one validator failing and freezing a lot of chains
Z
04:44
Zack
1/72000th isn't very many
J
04:58
Josh
Yeah, we can scale to that but it doesn't mean there won't be just a few validators for other reasons
Z
04:58
Zack
Even if there are few validators, they don't want to put one pubkey for everything on one computer
04:59
They would split it up into sortition chains validated by different servers.
J
05:00
Josh
it might eventually be worth doing t-of-n sigs for these, but that can be done if we add multisig to accounts
Z
05:02
Zack
If the pubkey changes length, a lot of stuff would need to change.
05:02
Currently you don't need an account to be a validator.
You just need an account to publish the list of signatures.
05:02
The list of signatures over a merkle commitment
J
05:03
Josh
Yeah but a lot of the code could probably be re-used; just supporting Ed25519 would do it
05:04
so what's the summary, do you think this oracle plan will work?
Z
05:04
Zack
I think we should reflect on it a little more
05:04
I still don't see why it wouldn't work. And there is good reason it for why it might work.
05:09
did we decide that these ideas don't work?
Z
05:24
Zack
that is a long page
J
05:26
Josh
what if sortition chains didn't choose a winning pubkey, they chose a winning integer. And there was a different decentralized database connecting integers to pubkeys. So even if the sortition chain is frozen, you can still sell your value.

what if all the transfers happen on-chain, but are all unverified until the fraud proof. Like, optimistic rollup style scalability. Waivers could still be off-chain.

what if instead of validators signing a merkle root, everyone who made a payment in this update multi-signs it with a threshold signature scheme.

review if mimble wimble tech can improve sortition chains.
Z
05:33
Zack
mimble wimble isn't useful, because it only encodes quantities, not ranges.
05:34
we don't want to layer the pubkeys and integers like that. because it increases the number of ways you can be forced to hold lottery risk.
05:35
we couldn't figure out how to make OR work with light nodes
05:35
also, I think we can scale a lot bigger than OR
J
05:45
Josh
good summary
Deleted invited Deleted Account
Emänüél 🇧🇷 invited Emänüél 🇧🇷
T
16:03
Topab
Unfortunatly I do not have access to this but it takes on the increasing use in stable coins. When all those get banned Amoveo will be a great alternative https://messari.io/article/the-stablecoin-wars Reading later conversations it seems you are on the way making it accesible, convenient and scalable. Nice to see this
J
20:58
Josh
In reply to this message
The main drawback I can think of is this means everyone has to be constantly online. If you're offline for an hour you could have lottery risk. The validator could withhold only your proof. You could pay others to be online and watch your leaf hashes but you'd have to trust them to stay online.
21:00
So if you don't ask for your proof in that hour, the validator won't get hurt if he doesn't give it to you when you ask for it later. Then he can blackmail you into selling him your lottery risk for a high fee.
Z
21:01
Zack
yeah. there are a lot of moving parts.
* sortition chain validator
* availability watchers
* availability explorers
* oracle
* user
J
21:02
Josh
Maybe you could still create an oracle. It won't freeze the chain but at least it will show that he's cheating.
Z
21:02
Zack
if the validators tries to attack a lot of people at once, he is more likely to get caught fast.
21:03
and he ruins his reputation, even if he gets caught slow.
21:03
we need to imagine that the attacker is participating in several of these roles at once.
There are a lot of combinations to analyze
J
21:04
Josh
He doesn't have to actively attack, he just waits for someone to forget to request the proof in time.
21:05
We have to make sure his reputation gets ruined, that we can prove it even after the hour is up.
21:07
In reply to this message
True, even now in Bitcoin explorer sites are run by blockstream, miners, etc
Z
21:07
Zack
i don't see any reason why showing data is unavailable for over an hour would be different from showing it is unavailable for less than an hour
J
21:07
Josh
The only difference is that the chain doesn't get frozen
21:07
Or it gets frozen too late to help
Z
21:08
Zack
As long as less than like 2% of the value in the sortition chain gets unavailable, it doesn't really matter.
And if he tries to make more than 2% unavailable, there will be a lot more people who could catch him.
J
21:16
Josh
Why wouldn't it matter? Because it wouldn't make sense for the validator to do it?
Z
21:16
Zack
because the amount of money lost would be small
21:17
and his reputation is still destroyed
21:18
its like how finding big prime numbers is impossible.
But finding a big number that you are 99.99% sure is prime is easy.
Don't let perfect be the enemy of good.
J
21:18
Josh
It's still bad for those 2% and for Amoveo's reputation but I agree it's getting less and less likely that would happen.
21:19
I could see validators screwing up in the early days, but they'd probably screw up for everyone
Z
21:20
Zack
even if the validator successfully does availability attacks against the 2%, they can't steal all the money.
At best they can buy it for a discount.

And it would take time to build up reputation so you have a big enough community of users to make the attack worth-while.
So if they only attack 2%, the amount of money they are stealing per sortition chain would be like 0.1%
21:21
which is probably even less than the accumulative fees they would earn over a sortition chain's lifetime
21:21
the explorers also have reputation.
We need to consider attacks were the validators are trying to ruin the reputation of the explorers.
21:22
Also, it would be nice if the availability watchers were in some kind of competition. So if one fails to do his job, he is throwing away money, and a different watcher will take his place immediately.
21:23
if watchers can earn profit from posting unavailable data, we need to make sure that the validator and watcher can't work together to drain money from the users.
21:24
and that they can't work together to harm the reputation of the availability explorers.
21:24
we need to make sure the explorer and validator can't work together to harm the watchers, by tricking them into making false reports
21:25
This strategy still seems promising to me, but there is a lot of work to do to really analyze it all.
21:34
I guess a watcher should only get paid if he was the first to warn about some unavailable data, and that data continued to be unavailable for an hour
21:35
that way the watcher only gets paid in the case where the validator is punished.
21:42
if a validator does not execute an availability attack, but they do allow data to become temporarily unavailable for periods shorter than an hour.
The explorers could record this, and it could harm the validator as well.
People will realize that this validator isn't very reliable.

So this further limits the space of possibilities available for the validator.