19:00
Zack
Yes. The code is outdated too.
19:01
Yes. Starts with one owner.
19:02
Yes. You can give me a fraction of your ticket.
You can divide along probability space, or you can divide along the rules of a turing complete smart contract.
So you could own stable-btc, and send me the long-veo side of the contract.
19:03
No. They all sign a single sortition block tx.
Or maybe in the next version, there will only be one validator per sortition chain.
19:03
Josh
Haha, good line 🙂
19:03
Zack
Anyone can broadcast a valid tx.
The tx is only valid if all validators have signed.
19:07
Ben
Zack Would it be correct to say “Bob creates a sortition chain with a 40 VEO probability space and contributes 30 VEO, receiving 75% of the probability space. Alice contributes 10 VEO to the sortition chain, receiving 25% of the probability space?
19:09
Zack
Someone used 40 Veo to make the sortition chain originally.
It is possible that eventually it could end up in a state where Bob has 30 and Alice has the last 10.
So Bob has a 75% chance to win 40, and Alice has a 25% chance to win.
19:10
Ben
So would it make more sense to say, Bob created the sortition chain with 30 VEO. Bob has 100% chance to win as the only participant. Alice put 10 VEO in the sortition chain, and now has 25% chance to win, while Bob now has 75% chance to win.
19:11
Zack
No. The size of a lottery pool doesn't change when new people join.
If Alice bought 10 Veo of the lottery tickets from Bob, then Bob would have 10 Veo less.
19:11
Zack
We need the size of the lottery prize to stay the same so that the number of on chain txs per sortition chain is minimized.
19:19
Ben
What is the incentive to Operators to participate in the Sortition chain?
19:21
Zack
You pay a fee to have them add someone next in line to own some value, or to give you the merkle proofs you need to sync with the sortition chain so you can spend your sortition value.
The validator can hand off responsibility if they need to stop.
Someone can buy up all the value in the sortition chain, and make a baby sortition chain inside of it, then the old validators job is done.
19:22
Ben
So Bob would pay a trusted Validator a fee to allow Bob to add Alice and give her some value ?
19:23
Zack
The validator is not trusted
19:23
Ben
Trusted by Bob, no?
19:23
Zack
No one trusts anyone in amoveo. That is why we use a blockchain.
19:24
Ben
I mean, why would you select a particular validator to help manage your sortition contract
19:24
Zack
Bob could pay the validator to make Alice next in line to own his value.
Then Bob could sign a waiver giving up his first spot in line. If he sends this waiver to Alice, now Alice owns the value. Because she is first in line and can prove it.
19:24
Ben
in principle I agree, just trying to understand how validators are chosen in the first place by the sortition chain creator, and why they would choose one validator over another
19:24
Zack
High throughput, fast ping, low fees.
19:25
Ben
Okay so purely on technical reasons?
19:25
Zack
High uptime is important too
19:26
Idk what "non-technical reasons" would mean in a conversation like this. We are talking about blockchain tech
19:26
Ben
Good, this can be included in my graphic
20:15
Josh
If the validator stops signing merkle roots you'd have to wait until the end of the sortition chain period to transfer your funds. So you need to expect them to do their job or you will have funds locked up for the duration of the sortition chain.
22:15
K
Is there any downsides to using a % of the mining reward to automatically set up a bet randomly every now and then in which there's a 70-30 chance of both sides of the bet?
22:16
I think something like that would encourage people to start using derivative market regularly as it's essentially free money
22:16
and will keep users coming back
22:17
Zack
doing bets with people is good. User experience will give us the knowledge we need to improve the product.
I don't know what you could mean by "using a % of the mining reward to automatically set up a bet randomly"
22:17
Amoveo currently uses state channels for betting.
22:20
K
I guess not automatically. But lets say we increase the mining reward % you recieve a tiny bit and you use that money to make a bet every now and then
22:22
and you put that money on the side of the bet that has a lower chance of winning
22:23
Zack
I am willing to do test betting at an expected loss even with the current level of reward.
The limiting factor here isn't the money, it is my time.
Time spent doing these tests is valuable, but time spent getting sortition chains operational is also valuable.
22:25
K
If you do 1 bet a week randomly at a random time
22:25
I think that will be enough to make sure people keep checking back to see if there's free money on the table
22:25
should take like a few minutes
22:27
Can make a few posts around reddit too to share the fact that there's free money
22:27
Zack
The Amoveo air-drop
22:28
like, follow, subscribe, and click the notification bell if you want to be eligible
22:31
Thee last character of the hash of bitcoin block 590430 is between 0 and 7 (inclusive).
22:32
Everyone who makes a reddit post about the constant free money bets gets some VEO too
22:32
or posts on twitter about it
22:35
Zack
"Leave a comment on this twitter post for a chance to be able to participate in an amoveo bet with expected profit.
Whoever comments with a real number between 0-100 that is nearest to 1/3rd of the average guess, they win the opportunity. "
22:36
you must be a follower for the chance to participate.
22:38
K
I think we should leave the bet open for all to participate in
22:38
Zack
If the same person keeps winning, then we wont learn as much
22:39
K
multiple people can win each bet though
22:41
Zack
amoveo p2p bets are in state channels. each channel has 2 participants
22:42
"Amoveo mini-airdrop.
One lucky person will receive 1/2 veo.
You must be a follower and like+share this tweet to participate.
Comment on this tweet with a real number between 0-100. Whoever guesses nearest to 1/3rd of the average guess wins.
Limit one guess per twitter account."
22:44
K
This is where ICO money becomes useful. Can pay some big accounts to retweet that tweet
22:45
Zack
then we could have swarms of low quality followers who don't care about Amoveo tech
22:49
K
Can add that you need to post you Amoveo address too to encourage everyone to download it
22:49
True, there might be a small % that are quality who will come back to the platform though
22:55
K
Can include a link where to download the wallet too / generate an account to make it easier
22:57
Zack
my twitter profile links to amoveo github. the light node is linked in the readme on that github.
I would rather have a smaller number of people go through the process of looking at Amoveo's github readme, instead of a larger number of people immediately downloading the wallet and making addresses.
22:58
I think twitter scanned the text of that tweet and is refusing to show it to anyone. haha
22:58
it only has 1 impression in 8 minutes
22:58
normally it would have 100-200
23:06
now when I look at impressions, the number keeps jumping back and forth between 40 and 200.
I think twitter is just having some back end issues, they aren't blocking the tweet.
23:08
K
The easier it is to make a comment and join, the more people will do it, the more it should spread imo
23:09
I got a big account to check out Amoveo, so hopefully they'll help
23:13
Zack
It is also a test of how smart the community thinks we are.
The lower the winning number, the higher our own opinion of our intelligence.
23:14
Normally a guess-1/3rd-challenge is supposed to have hidden guesses.
23:15
But this one has a hidden end time. No one knows when the guessing period ends.
23:46
Zack
looks like demiculus will win
23:50
in my next airdrop I should give away up to 1000 veo.
Pick a number between 0 and 1000.
Whoever picks the lowest number wins that many veo.
23:51
or how about if there are N participants, we pick one at random and give them 1000/N VEO.
and you can participate as many times as you want.
00:11
Zack
We realized that sortition chains should have only one validator, and that sortition ownership objects should have any number of owners instead of just one. So we can do the cycles.
The change I will make to the sortition object is the inverse of the change I will make to the ownership object.
00:15
oh, it was supposed to be 2/3rds of the average. haha
Good thing we started with such a small amount of reward
00:48
Mr Flintstone
im surprised it took this long for someone to do this. soon, other exchanges will follow and probably contracts will be written to settle disputes with the median of several exchange sources. i wonder how long it will take for this to break
00:49
Zack
And what excuse will they give?
"Coin base got hacked! Hacker manipulated the price oracle."
00:50
"One of our new engineers hacked the price feed, and now we can't find him."
00:51
Looks like instinct will win the air drop
03:48
Deleted Account
Hey guys, how's things? Can we have wrapped Tether in Amoveo smart contracts yet?
03:51
Zack
No. That will never happen.
Amoveo only has derivative type contracts, not subcurrencies.
04:01
Mr Flintstone
could have synthetic tether but you’d probably rather use synthetic usd
04:21
Zack
or maybe they would want something that tracks the spread between the two
04:21
derivatives are more versatile than subcurrencies. and they are scalable.
04:46
or at least the oracle part
04:46
oh, it is just an oracle. on ethereum
04:48
Eric Arsenault
nice thanks
05:36
Tromp
What wallet can I use to receive and send right now?
05:36
Amoveo wallet seems to not be able to send
05:36
I wrote it. you can ask questions here and I will help you.
06:03
Zack
like, betting on the relative probabilities of success of their offspring, between different potential pairs of parents?
06:03
that would be a pretty long-term bet
06:04
im not sure what aspects of a person we can expect to become common knowledge, if they haven't been born yet.
06:05
I know designer babies are a hot topic now, but I don't see how futarchy can be useful for that.
07:47
Mr Flintstone
someone commented their private key mnemonic on your mini air drop tweet. a bold move for sure
07:51
Jake
Ha. I saw that
08:06
Zack
those words aren't the private key for their address. idk what they are doing.
08:43
mr x
yes they are at myveowallet
08:43
Zack
i wonder why myveowallet generates a different privkey from the same words
08:49
mr x
your light node doesn't even have passphrase functionality?
08:51
"generate new keys"
09:05
Mr Flintstone
i think it was removed?
09:05
it think there was a bug in it way back in the day
09:05
idk if anyone here remembers the hysterics
09:05
Zack
what was removed? I can generate keys this way right now
09:06
Mr Flintstone
when ppl could brute force veo private keys cuz there was a bug in the password input to private key generation
09:06
Zack
oh, I remember. it converted all the letters to the same letter somehow
09:07
Zack
I think it must have been fixed though
09:07
Mr Flintstone
probably doesnt hurt to double check
09:08
versioning can always screw something up
09:10
mr x
i think it works
09:12
it just prompts before the input field whre you put the passphrase
09:16
the instinct is to press continue and not look ahead xD
09:18
and "generate new keys" doesn't really indicate that here is the brainwallet generation
Roger That invited Roger That
15:02
Sy
I think it used no letters at all and only numbers...can't remember exactly
15:03
Every letter turned to 0
21:45
Zack
I think maybe myveowallet has different rules for passphrases to make it compatible with hardware wallets.
00:56
Crypt Dweller
Greetings all. I hope everyone has a productive day today.
05:50
Zack
It actually has a PoS mechanism embedded in it to make the bets encrypted.
Deleted joined group by link from Group
13:39
Crypt Dweller
This is not the most intelligent thought, but regarding the search for a product market fit, if you can create a user experience as good as Intrade had, but on Amoveo's decentralized, fully secure system, the growth would be unstoppable. I guess the problem is that it's not possible to make bets as simple as they were on Intrade?
16:58
Josh
Zack, in the rng_result, are all the checkpoint hashes posted on-chain or just their merkle root?
19:14
Zack
Rng result is part of finalizing the rng value. We do that after the sortition chain ended. So it is after all the checkpoints.
19:15
Currently we only have 1 vs 1 p2p bets.
19:35
Josh
So which transaction type do the checkpoints go in?
19:54
Zack
Sortition blocks have sortition Merkle roots
20:00
Josh
After the sortition chain ends we need to post an RNG result. This result has 129 checkpoints, which I understand are for helping RNG checkers check the RNG in parallel. Do those 129 RNG checkpoints get posted on-chain?
20:05
Zack
The tx contains 129 hashes. Each 33 bytes.
The tx is posted on chain.
20:05
Amoveo tx types all only exist to get posted on chain.
20:06
Waivers and sortition contracts and channel contracts aren't txs.
They are just evidence that could potentially go into a tx.
20:22
Zack
True bit fraud proofs let us verify an N step computation on-chain in log2 (n) steps.
By putting 129 checkpoints at a time, it only takes log128 (n) steps.
20:22
Which is 7x faster.
20:23
Making the tx 4 kilobytes, I think it is worth it to settle the sortition chains faster. With fewer total txs.
20:24
Josh
Also, we need that in order for the RNG checkers to be able to check in parallel, right?
20:24
I'm wondering if we could have RNG's that would work for multiple sortition chains so that each chain doesn't need to do its own RNG.
20:28
Zack
Yes, but it only really matters for the first round.
The computation is 128x shorter with each round.
20:29
Why not have one big sortition chain, and make more sortition chains inside of it
20:33
Josh
that might be best
21:07
Zack
Money Guy won the airdrop competition.
21:12
Jake
Turns out I am bad at following instructions! 😅
21:12
Zack
better luck next time
21:13
Instinct
Thanks Zack 👌 1/2 a Veo may be a lot in the future
21:15
Zack
180 characters of instructions can be overwhelming
21:16
Jake
It is overwhelming pre-coffee
22:37
Zack
I think for the sortition ownership object, we should have 3 kinds of priority.
1) the height at which you can prove your ownership from. earlier heights are higher priority.
2) if the heights are the same, then whichever ownership object has the higher priority nonce wins.
3) if the heights are the same, and the priority nonces are the same, then whoever can make a claim using a lower cycle-nonce wins.
So if you don't want to use the cycle features, and you just want to own probabilistic value in the sortition chain, you can have a cycle of just one account, you own account. and if you sign a waiver, make it give up ownership for the entire priority nonce.
If you are in a cycle, don't give up ownership to the priority nonce, instead give up ownership of some of the cycle nonces.
00:59
Zack
prolog has a lot of wackiness to make backtracking possible. People are willing to put up with all that, because backtracking is such an amazing feature.
Erlang is basically prolog without backtracking. It still has all the wackiness, like how everything is immutable, and recursion is the only kind of looping, and how it does unification instead of variable assignment or pattern matching. You program with declarative Horn clauses, instead of with functions or procedures.
And yet, Erlang became one of the most successful languages ever, and prolog is barely used at all.
All the weirdness to make backtracking work, it turned out to be an excellent design for erlang's fail-fast error handling strategy, which is a key feature making it's message based concurrency strategy so effective.
04:36
Zack
im thinking for the next round of airdrop, they should need to make a tx spending a little veo to be able to participate
04:37
then after that, posting a p2p contract with certain parameters
Deleted invited Deleted Account
06:55
Mr Flintstone
good ideas!
06:56
maybe this is a more effective way to get people to start using the tools than making EV+ bets
07:03
Zack
I am thinking of doing it in baby steps, so we don't overwhelm them with a too difficult task.
10:44
Zack
Yes, trustless real-time price feeds are almost certainly impossible.
Luckily, they are also not important for any blockchain applications.
In order to enforce derivatives contracts, all we need is an oracle that can eventually report what the price was at some point in time. Even if the oracle takes a week to put that data on-chain, it doesn't matter.
If you want to get your money out sooner, then just sell your derivative contract for VEO.
It will be cheap to pay someone to hold the contract for a week and get the veo out at the end.
10:47
Paul Sztorc figured this all out back in 2013. It is depressing that people still don't get it.
But I guess it is a good thing for Amoveo, since that means less competition.
10:49
Topab
That sounds reasonable
11:30
Mr Flintstone
i think trade offers can act as a real time price feed of the value of the derivative at least
11:32
Zack
on short time scales, I think the set of open offers can be manipulated
13:36
Crypt Dweller
It's honestly surreal that a project that is as transparently sketchy as Aeternity still manages to retain a $30m marketcap. It would be good for the cryptocurrency market as whole to undergo an even deeper depression to shake out these useless company-tokens and shake off the well justified association of crypto with scam in the general public's mind
13:41
Zack
Even if their team and tech is worthless, I think they have a lot of money in the bank from the ICO.
Warren Buffet's investing strategy, value investing, it is popular today.
Not that I know all the details about how much cash they have left, but it wouldn't surprise me if they had $30 million.
In which case it makes sense that the tokens would be worth that much, because there is some expectation that their savings will eventually be spent on pumping their tokens.
Captain Man invited Captain Man
18:33
Noxemo
Hi, How many devs are working on Veo at the moment? Also is the total supply listed on CMC accurate? Thanks
Kirobi | Give2Earn invited Kirobi | Give2Earn
20:49
Zack
I am working on VEO, so at least 1.
Does Josh count? He is asking technical questions.
21:03
shakarama is more like a propaganda/psychology engineer. not a developer.
21:09
more like a head priest than a salesman
21:19
Josh
Dev in training 😊
21:20
Here's another question: what happens if two players submit a random number at the same time? Which one wins?
21:21
Zack
the random number generation process is deterministic. So, as long as they are both honest, they will submit the same random number.
21:22
Josh
ah right, so which one gets the reward?
21:23
as soon as I see somebody else posting the number, what's stopping me from posting my own tx copying the number to try to win the reward?
21:23
Zack
there is no reward for publishing the random number result first.
21:24
the incentive to publish the random number result is because whoever won the sortition chain needs it to get published so they can get their money out of the sortition chain.
21:25
if someone copies your result and publishes it before you, then they save you from having to pay a tx fee.
21:30
Josh
hmm, that's interesting
21:33
I guess in the usual case, there will only be a few big owners by the time the lottery is finalized. So they should all have motivation and capital to have fast CPUs.
21:34
Zack
the VDF isn't an expensive process, and you don't need an especially fast CPU.
It is just a slow process.
21:34
Josh
Right but twice as slow if you have an older CPU.
21:37
Zack
to prevent RNG manipulation attacks, the VDF process needs to last long enough so that we can't revert blocks to restart it with a different seed.
So, 6 blocks of time, ~1 hour is fine.
Even if your CPU is 10x slower than the fastest, that means you need 10 hours to calculate the RNG.
Once someone else has submitted a RNG solution, it will eventually be possible to use a GPU to either verify that the solution is correct, or show that the solution is wrong, and the GPU verification will be around 128x faster than the CPU calculation.
We don't have the GPU code yet though.
21:39
it is very similar to GPU mining software
21:42
Josh
Are there any specialized chips that are 100s or 1000s of times faster than a consumer CPU at hashing in serial?
21:43
Zack
No. We are hitting physical limitations.
It isn't possible to do serialized hashing much faster than a typical consumer cpu.
21:44
Josh
cool, did you write anything up about that research?
21:44
is it based on thermodynamics or something?
21:49
Zack
when you erase a bit of information, it releases some heat. The amount of heat released is based on the size of the transistor.
There is a lower limit for how small transistors can get, and we are nearly there.
Computers get slower as they get hotter, so the computational capability of a transistor is limited by how quickly we can get heat off of it.
I link to some papers in the document about our RNG design
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_random.md
21:56
You can get some futarchy-type evidence to come to the same conclusions by looking at the relative prices of different CPU with different clock speeds, and by looking at historical data connecting clock speed with price.
21:57
I think there has also been some experiments where they offered big prizes to whoever could calculate the VDF most rapidly. And no one was able to calculate it faster than the fastest known CPU at that time. It was only like 3x or 5x faster than a typical consumer laptop CPU.
22:00
GPU, FPGA, and ASIC chips are able to mine bitcoin faster than a CPU, because bitcoin mining is parallelizable.
Those kinds of chips are all massively parallelized internally.
The VDF we are planning to use, it is not parallelizable. You can't start on the next step until you know the result of the previous step.
22:01
The current CPU speed limit for serial sha256 is around 5-10 million hashes per second.
22:03
Most VDF research today seems focused on making a version of VDF that can be verified quickly using only a single-threaded CPU.
They are already in agreement that serialized Sha256 works as a VDF.
loay jabas جبس invited loay jabas جبس
22:16
seems like the record was set in 2014
22:18
Zack
8.7 Gigahertz for the world record.
or 4 Gigahertz for a good gaming CPU.
22:20
Josh
My macbook from 2013 is 2.3GHz
22:21
Zack
It isn't just about clock speed.
Different CPU can do a SHA256 calculations in a different number of cycles.
But if you increase the number of transistors in a CPU to support more native operations to allow for the SHA256 to happen in fewer cycles, then you are increasing the total number of transistors that need to get erased in every cycle, so you are producing more heat, so the clock speed will need to be lower.
22:22
It is really convenient that we are finally pressed up against physical limitations for a certain kind of computation.
22:26
Josh
Yeah, although even without that I suppose we could rely on Moore's law and just keep upping the difficulty.
22:30
Josh
Saw that, nice and simple.
Deleted invited Deleted Account
23:04
Josh
Hmm, this probably wouldn't be good because there are often hours with only one block. We'd either need to wait a lot more blocks, or reduce variance by having more blocks per hour.
23:04
Zack
Moorse law broke down for cpu speed.
Anyway, I think the long term strategy is like this:
1) the software should publish rng results as soon as possible by default.
2) we should occasionally reward whoever managed to publish first, which creates an incentive to reveal how quickly it can be calculated.
3) we should maintain a safety margin in the length of the vdf, to make sure it is prohibitively expensive that someone is doing cpu research in secret to attack us with a new design.
Waiting 5 extra hours to close a sortition chain is not a big deal, since only one person is withdrawing, only one person is waiting.
23:06
Waiting extra blocks here is not a big deal. Even 24 hours wouldn't matter.
Only one person is waiting.
23:07
"the software should publish rng results as soon as possible by default." -- what does that mean exactly? we're already publishing the rng in rng_result_tx.
23:09
"we should occasionally reward whoever managed to publish first, which creates an incentive to reveal how quickly it can be calculated." -- this is vulnerable to my copying attack.
23:09
Zack
That tx type is accepted as valid by the sortition branch of amoveo.
Eventually we will write more software that used the vdf library. So if you are participating in a sortition chain, you can find out if you won.
Whoever is using this software, we want it to be the case that they share their result as soon as it is known. By default.
23:10
You can make a smart contract with the mining pools, so they pay you to reveal, and then they can include the secret in a block so they can get rewarded.
23:12
Oh right.
You can put the hash of your solution into a block. To commit the fact that you have the solution first.
23:12
Josh
maybe you could use a commitment tx, this would include a hash of rng + secret. A few blocks later you can claim the reward by providing the secret.
23:12
Zack
Signed with your private key
23:14
Josh
there are already a ton of txs related to sortition chains, i don't think adding one more hash is a big deal.
23:15
Zack
We have proof of existence tx already
23:16
Josh
i was talking about the space the tx takes up, not about adding a new type
23:16
Zack
Yes. One additional proof of existence tx for every several thousand sortition chains, the on chain cost is negligible.
kranh men invited kranh men
01:03
Josh
>>> math.log(600 * 30 * 10e6, 128)
5.3413151357594195
01:04
I'm getting 5.34 instead of 4.87 for this calculation
01:07
Zack
yes, you are right
១០. បញ្ញា ភាតរយុទ្ធ invited ១០. បញ្ញា ភាតរយុទ្ធ
MR ALOUD invited MR ALOUD
Deleted invited Deleted Account
Kimlay Sao invited Kimlay Sao
Deleted invited Deleted Account
سوران هاشم invited سوران هاشم
14:31
Toby Ganger
There’s simply no volume. Crazy
14:32
The slow descent into irrelevance by building the best social technology that no one in any society knows about.
15:23
Topab
Why is this according to you? Is not enough being the best to succeed I guess you are trying to say. However, Amoveo use by less tech savvy is still far away. But actually not even developers are using it
15:27
Deleted Account
Let's make a simple usability test.
I have USDT and I want to make a bet that on June 15th Kim Jong Un will not be supreme leader of North Korea.
I'm willing to buy BTC or ETH, but not VEO, because it's too volatile and has almost no volume and I'm definitely not going to send coins to HitBTC.
How can I make this happen?
15:29
Živojin Mirić
but what's a reliable source on who is supreme leader?
15:30
Deleted Account
Good question. We need all the questions and the possible solutions.
15:59
Ben
amoveo has currently no realy usable interface, the best we got it the amoveo wallet from exantech
16:02
Deleted Account
I remember 2 years ago people were buying OTC VEO for $300...
16:02
Ben
diffrent age and at that point people had high hopes in regards of adoption, which never happened
16:03
the underlying tech is still superior from my perspective
Deleted joined group by link from Group
16:12
Deleted Account
My point is that superior tech is irrelevant if you can't put it to use.
Example: half of crypto shits on Ethereum, yet it works and it is used every day even by those who shit on it. If not for anything else, just for sending tokens like Tether.
Deleted invited Deleted Account
16:25
mr x
You can do stable coin or whatever denominated sortition chains with full power of the contract language? Hope this is not nonsensical...
16:35
Deleted Account
Is this project dead?
17:20
I P
whats current price?
17:23
Šea
Never dead, only worthless
17:23
I P
i mean it lost only 95% of value while many other stuff lost 99.9%
17:24
Deleted Account
Why is there no actual derivatives on this thing?
17:32
Ben
because the usability is so low that maybe only 10 People have the knowledge to get that setup
17:35
Živojin Mirić
If this project dies human civilization dies!!!
17:39
mr x
sortition chains leads to rethinking of ui anyway?
17:53
Deleted Account
Also, the longer you wait with implementation, the higher the chance is that something similar will show up as a simple to use alternative. And it doesn't even have to be superior tech.
18:00
Josh
It's the foundation reward active yet? How much is it currently worth per month?
18:22
Josh
Zack, am I doing this math right? If I'm a "liquidator" (need to come up with a better name) buying up everybody's sortition chains, and I want to charge a 0.1% fee and I manage to buy up 30% of each sortition chain, I would need to do 20 sortition chains to expect to break even.
18:22
>>> math.log(0.001, 1 - 0.3)
19.367088707438644
18:35
Looks like the current amount in the dev reward is 12,089 veo which is about $360,000.
18:36
It's about $2,580 per month at current rates.
18:37
that's based on this:
18:37
Block reward
0.1038239 VEO
18:38
Developer reward coefficient
19.99%
18:38
But I'm not sure how it got so high, according to the calculation it should only go up $30k per year.
19:24
Ben
the block reward is dynamic and was in the beginning way higher
19:25
that does not mean that we will get an UI...
19:25
Josh
That explains it, thanks.
19:28
It is pretty low, only $3 per block. That's not a lot of security.
19:28
actually more like $2.40 after deducting the dev reward
19:34
Ben
keep in mind that the Price is on an ATL
19:35
and Zack is not driven by money.
19:36
Josh
Still, $2.40 per block, or $150 after 6 confirmations is pretty low
19:36
People should probably wait more like 12 confs
19:37
Zack himself says we should want him to be incentivized to work on Amoveo.
Deleted invited Deleted Account
20:33
Deleted Account
Why is Zack the only Dev working on this project? Ideally there should be at least 3 entities working on different aspects, like wallet, experimental markets, etc.
20:34
Živojin Mirić
I figure there is no interest
20:39
Josh
What do you mean should be? Who's stopping anybody?
20:40
I'm actually interested why people here are interested in Amoveo.
20:41
Živojin Mirić
most people here are speculative bagholders
20:41
Josh
We need people who understand why it's less broken than other blockchains.
20:42
Živojin Mirić
VEO is not broken, stop plis
20:42
yu have potential to be higher rank
20:44
Deleted Account
"Should" as in that would be healthy for the project.
20:44
Zack
Yes. We could have a sortition chain denominated in stablecoins.
20:44
mr x
I'm just skeptical of blockchains that put other shit than the native token in them
20:44
of we can stick oracles in trustlessly
20:45
then we can do cool shit with combining them with the native token
20:46
mr x
the light node ui is pain
20:46
Zack
I get 1/6th of block rewards.
20:47
Idk what you mean by "break even".
There aren't any costs. It is a profitable activity.
20:49
Deleted Account
If there is so much money stacked in the Dev fund, why don't stakeholders vote on projects and hire developers? I'm curious, not criticising.
20:51
mr x
but still imo anyone who hasn done a p2p bet to completion just to familiarize himself with the concepts
20:52
is jsut an impatient baghodler probably sitting at qtrade
20:52
Zack
You can use futarchy to make decisions about Amoveo's source code, or what I work on.
You can't tell me how to spend my money.
20:53
Deleted Account
I don't want to spend anyone's money. Btw is the Dev fund assigned to you only?
20:55
Zack
Talking with you about sortition chains lead to some serious improvements in the design.
having people asking questions and trying to understand makes a big difference.
20:59
Josh
😊Thanks, good to hear.
21:01
I mean getting rewarded for their risk. They have an 0.1% chance of losing all the lotteries. In that case it wouldn't be profitable.
21:01
Zack
I worked with a couple blockchain companies before. With people who were employed to understand what I was building.
I was always so disappointed in my coworkers. They were so eager to do something visible to justify their next paycheck, but completely uninterested in learning what we are trying to build. I eventually needed to waste time deleting all the pointless bloat they wrote.
On the other hand, people like Josh or Mr Flintstone, who are volanteers who don't write code, but just try to understand and make suggestions on how it could work better, these kind of people have been extremely helpful.
21:02
If you have 30% of the lottery tickets in one lottery, then there is a 70% chance that you lose.
21:02
Josh
Oops, quoted the wrong thing.
21:04
Zack
Buying up lotto tickets at the end for a 0.1% fee, on average this is a profitable activity.
But in the short run, if you only have 30% control of eah lottery you can easily lose a lot of money.
21:08
I think most jobs in blockchain are just so the company can brag about how many developers they hired.
It normally doesn't matter if the devswrite usable code or not. The devs just need to convince the users that they are writing something useful, and the blockchain company is legit.
21:09
Josh
Yeah that's what I was getting at.
21:09
>>> math.log(0.001, 0.7)
19.367088707438644
21:09
If you want your risk to go down to 0.1% you need to capture 30% of 20 sortition chains.
21:11
0.7 probability of losing each time, to the power of 20 is 0.999
21:11
Zack
Your risk of being net negative on the investment?
I don't think your may is right.
Wouldn't you need to sum over binomial coefficients, or use a bell curve chart or something?
21:12
So that means there is a 0.1% chance that you win all 20 times, right?
What are you trying to calculate?
21:13
Josh
It's an 0.1% chance that you will lose all 20 times.
21:13
Zack
I think you need to win at least 6 of the 20 times to break even
21:14
If you own 30% each time
21:14
Josh
Yeah you're right, I didn't account for the main expense which is buying up the actual value.
21:15
Zack
I'm actually hoping the specialist will own more like 98% of the tickets each time
21:15
Josh
The reason I wanted to explore the math is to see how hard it is to be a liquidator.
21:16
Zack
If it is hard, then they charge higher fees.
If it is easy, then someone new will undercut their fees.
21:18
Josh
Sure but I think it's pretty easy to figure out approximately what the fees should be.
21:18
Zack
The size of the fee is related to the amount of time that the money is locked up for. The background interest rate. The Veo price volatility risk. And finally the lottery risk.
21:18
Josh
Without doing the math, we don't know if the fees would be 50%, which would make it unusable.
21:19
Zack
People love staking their money on ethereum to earn interest.
21:19
Josh
well the background interest rate is around 0 these days.
21:20
i was just starting with the lottery risk but i think that's most important.
21:20
Zack
I think Veo price risk will be more significant at first
21:21
A rich person can hedge lottery risk by having lots of other similar investments
21:22
I guess there are people who hold Veo anyway.
So maybe we can convince some of them to specialize in buying up all these tickets at the end.
21:23
Probably I will be the only sortition operator, and the only person buying up tickets at the end, at least for the first few months of sortition chains.
21:23
Josh
I think so, especially since this should help the veo price.
21:24
Zack
I don't want to encourage our small investors to take risks they don't understand and get wiped out
21:27
Ben
the Dev fund belongs to ZACK only
21:27
Josh
Is there a way to invest in a managed fund? I set up a liquidator account and manage it but people can put up capital and get returns.
21:28
Zack
If it were centralized and trustful, I guess that is a kind of hedge fund.
I don't think it can be trustless.
21:30
Deleted Account
Yeah I see now. This is a problem, but none of my business. This is the only bit of info one needs to understand why the project is where it is.
21:32
Ben
i don't think that it is a problem in particular that Zack is getting that reward, he is doing kind of the heavy lifting.
21:33
Ben
the problem is that zack has 0 interest to build a Framework around amoveo that would get the attention of Average joe.
21:33
at least not as of now.
21:33
Deleted Account
It's not only one problem, but a lot of separate problems.
21:37
Mr Flintstone
if the first application on sortition chains starts out as a lottery, maybe we dont need to worry so much about this, as small slices of what was once pure lottery space may start to become stabelcoins and other derivatives
21:40
Zack
Oh yeah. Lotteries are in demand on their own.
21:41
I think there isn't a good blockchain lottery yet, because doing it on-chain would be a lot of bloat.
21:45
Mr Flintstone
there are “no loss” lotteries programmed on ethereum but the rng source isnt good enough to support large value at stake imo
21:46
Plus what you said about bloat, it couldnt support millions of users at the moment
21:48
Zack
If people want to get rid of lottery risk, then that means there are lottery tickets that are a net positive investment.
When the main stream lotteries flip to being a positive investment, a lot of people start buying
22:05
Josh
Yeah good point, although I think even without that the sortition fee would be pretty low.
22:06
Zack
gambling lotteries are normally seen as a vice.
It is ironic that we can use them to make futarchy.
22:07
Josh
the problem is they're illegal in many jurisdiction or at least require a licence. so creating a sortition chain and selling pieces could be illegal.
22:08
Zack
if it is illegal, that makes our job easier.
Less competition.
22:09
historically, when lotteries were illegal in USA, they used to buy tickets from the Irish lottery
22:14
Josh
yep but it is a risk of using the blockchain
22:15
Mr Flintstone
it is incredible how ppl building things on blockchains just think they are immune to jurisdictional regulation. like here is a lottery product on ethereum advertising engineering jobs in jurisdictions where this is not legal
https://www.pooltogether.com/careers
22:16
Zack
hahaha
there are laws against gambling, but I don't think any country has laws against making gambling software.
22:16
As long as you aren't talking about politics, it seems like speech is more or less free, world wide.
22:25
Josh
there are more and more calls to ban cryptography, and cryptography did have restrictions in the US in the past
22:30
Zack
You don't need to use encryption to use Amoveo.
22:31
There are like 200 countries. If we could get popular in even one, that would be great.
So I think we don't need to worry about any legal limitations at this time.
22:35
Even if crypto and gambling became illegal in every country, there will be cities that refuse to enforce these laws.
Also, there are limitations on how long these things can be illegal.
It is like how when cars were invented, England had ridiculous laws for them. like requiring more than one driver, and having a flag man walk in front of the car and wave a flag around.
Countries with bad laws that restrict the economy from succeeding, those countries eventually lose control to countries with better laws and healthier economies.
Finance and encryption are both very useful, I think that an economy with freedom to use these tools will out-compete an economy that lacks them.
22:36
Josh
i agree, but if people could get in trouble for selling sorition shares, they should be aware of that
22:37
Zack
well, I am not a lawyer in any country.
22:38
I think it is the citizen's responsibility to know their own jurisdiction's laws. It is not my responsibility to learn the laws of every part of the planet to give warnings to everyone.
22:39
It is hard enough reading legalese in english. haha
22:41
I wonder if it matters which country I put the server in. The server for operating the sortition chain and trading lottery tickets.
Lin Lanser invited Lin Lanser
22:58
Josh
It probably does matter. They'd have no problem shutting it down in the US if they cared enough.
22:59
Zack
if all they did is shut the server off, that is no issue at all. I can set up a new one very quickly.
23:01
Josh
Costa Rica
Costa Rica is home to many companies in the online gambling industry. Despite this fact, there’s actually very little in the way of related legislation. Companies do have to be licensed to operate legally from within the region, but specific betting and gaming licenses aren’t required. They just need a general license, which is relatively easy to obtain. Overall, there’s a distinct lack of regulation here.
23:05
I imagine if the US cared, for instance if you had customers in the US, they'd try to go after the operator.
23:06
For instance, they didn't like Liberty Reserve providing payment services to US customers, so they had the owners extradited from Spain.
23:06
In that sense, it doesn't matter where the servers are.
23:06
Zack
if a government forced the VPS operator to give them access to the server, and they confiscated all the veo on that server, I think that could be a very good thing for Amoveo.
It would give us legitimacy.
23:08
lyzer
That's cool your based there ?
23:08
Zack
I bet I could set it up so the private key is on a server in my house, and it keeps contacting the sortition serve to sign contracts.
That way the sortition server wouldn't actually have any money on it
23:08
Josh
I think it would go in both directions. It would scare some people and it would offer legitimacy. The arrest of Ross Ulbricht probably helped Bitcoin in the end.
23:08
but nobody was suggesting that using bitcoin itself is illegal.
23:09
Nope, just found that on the internet.
23:09
Yeah that's a good idea in general.
23:10
But if they really want to they can do a whole investigation and find out who's behind the contract.
23:10
And then send an extradition request
23:11
lyzer
Ah got ya didn't know that info but one of the crypto projects im invested in is doing remittances from there
23:11
Makes sense with the ease of regulatory aspect
23:27
Zack
Every extradition treaty is unique.
if there are 200 countries, then there could be up to 20100 different extradition treaties. haha
23:28
staying out of legal trouble is different from avoiding breaking laws.
23:28
Josh
they can also arrest you if you ever visit the US or another country that has easier extradition laws
23:39
Zack
regardless of what the laws are like now, we are headed towards a future where money is on the blockchain, and lotteries are used for scaling.
00:01
Josh
Yep, let's get there as fast as we can
00:06
I'm not sure this would be good. We'd want competition so they might own less than 50% each time. Of course we'll see once there's a market. Although if a monopoly had an advantage this might be bad for competition. I'm not sure they will have an advantage, I think it should be pretty easy to do this if you're only getting 30% of each lottery.
00:09
Zack
What I would want to see is many sortition chains.
Each one settles with a single individual owning >98%.
But there are multiple different people who are buying up 98%.
They compete to offer lower fees, and they are limited by how much money they have in new young sortition chains that they can swap.
00:10
It's like how there are many different restaurants in a city. And each one serves food that is 100% cooked in that restaurant.
The fact that one meal is 100% cooked by one restaurant doesn't mean that the restaurant has a mononpoly.
Because there is no market for that single meal. There is a market for meals in general.
One restaurant only controls a small fraction of the meals available in a city.
00:13
meals from different restaurants are somewhat replaceable goods. Hungry people are going to eat something, and once they are full they will not.
Similarly, different people allowing for exiting the sortition chains are replaceable. if you can atomic swap with one person to exit, then you don't need to do it with anyone else.
So as far as monopolistic risk, it is not an issue if one person buys up all the tickets at the end of one sortition chain. He has no way to exploit the users.
00:19
Josh
I agree, but to take the restaurant analogy, I might like to sell my SCs to Bob and you might like to sell yours to Alice; if we both have part of the same SC Bob might wind up with 50% and Alice with 50%.
00:19
In the end it's probably not that important
00:23
Zack
If one person has more already, then the cost of lottery risk to add one more Veo is lower for them.
If 2 people owned it in a 49/51 split, then they can both profit if the poorer person swaps all his value to the richer person for a very small fee.
00:23
If people keep making trades to minimize their personal lottery risk, eventually each lottery has one owner.
00:25
Josh
it's possible but there could be transaction costs that change that in practice. only way to know is to see what happens in the free market but either way it should work well.
00:25
Zack
argentina capital controls are getting harsh. It is practically impossible to get derivatives contracts on their peso now.
00:26
these specialists are on-line 24/7 to try and collect all the tickets and profit by consuming and hedging lottery risk.
We can precisely calculate the entire cost.
00:26
Atomic swapping isn't that mysterious
00:27
Josh
I was talking about other kinds of transaction costs like marketing, repuation, legal, etc
00:27
yeah that should make it more lucrative
00:28
Zack
you don't need any of that, and none of it would benefit you for this task.
00:28
Josh
it's amazing people still have to use a trusted centralized service for this
00:30
Zack
lets say one service had a great front-end and good reputation for buying up lottery tickets at the end.
Then people would use their service a lot for convenience.
But this convenience specialist can earn more profit by offloading it's lottery risk to lottery-risk-hedging specialist.
The convenience specialist will sell their stake in the sortition chain as soon as possible, to free up more liquidity to facilitate more people conveniently exiting.
00:31
Josh
makes sense, reminds me of re-insurance companies
00:32
Zack
It is most efficient if each participant has their own capital working towards whatever they have a relative advantage in.
The person who makes the best interface to exit the sortition chain is probably not the same person as whoever is most capable of hedging lottery risk.
00:33
I am guessing it will be a market where people can trade coins between the 2 sortition chains.
And the people who can hedge best will be willing to buy at a slightly lower price to undercut the competition.
00:34
so there will be lots of markets like these between different sortition chains. and because of the relative cost of lottery risk to different participants, it is like there are arbitrage opportunities between the markets for them.
00:36
If everyone keeps swapping to try and minimize risk and maximize profit, we end up with each sortition chain finalizing with only 1 person owning the whole thing.
00:36
Josh
basically, normal people will just continuously be rolling over their sortition chain holdings
00:36
Zack
yes, that is the expectation
00:36
Josh
the wallet should do it automatically but maybe notify you if the fee gets over some threshold
00:37
Zack
you need to at least come online once per rollover period. because it needs to use your private key to sign some stuff.
00:37
Josh
your wallet would have your key depending on the setup
00:38
the wallet could be programmed to only do relatively riskless things automatically, like roll over to a new sortition chain, but it wouldn't do spends without your permission
00:39
Zack
yes. I imagine there would be different wallets for different use cases. and that some would be very simple, hiding almost everything.
00:39
just a balance, and a way to send and a timer for when you need to come back online by
00:39
Josh
also this is great for small purchases, so the amounts might be low
00:40
the worst thing would be for someone to forget to roll over
00:40
Zack
or the best thing. if they win the lottery.
00:40
Josh
yes, the worst thing would be for someone to forget to roll over, assuming he loses the lottery
00:41
Zack
we could probably set up notification services, so they will get an email or a phone call or something
00:41
Josh
which is a pretty good assumption for a small amount on a sortition chain
00:41
yeah, i think part of amoveo keeping things off chain is that the wallets should be pretty sophisticated
00:41
Zack
the person who wants to buy your value, he has an incentive to notify you. so maybe the service could even be free.
00:42
Josh
the wallet should be able to notify you unless you're offline for a long time
00:42
even then, it knows when the sortition chain ends
01:07
Toby Ganger
I will mention this one more time in case anyone is listening. One can not separate adoption, price, and the quality of a coin/network. In crypto, it is the speculators that bring new eyes and users to a coin’s network. Not only does each additional user make the network more functional but it is from this pool of new users that further development comes. While most are speculators, some are looking for an interesting project for which they have skin in the game.
If there is no attempt at making this product visible to speculators, it will never gain the network and development it needs to be properly functional. It will be great tech that no one can use.
Zack has said before that he doesn’t care about price and therefore doesn’t care about marketing. This sense of ideological purity renders this network powerless, for the price is a reflection of its user base and therefore its functionality.
01:25
Toby Ganger
How does any product acquire brand recognition and new users? Some form of public relations. “Here public, this is what we’re working on and why it’s going to be a game changer for everyone” “here’s our easy-to-use UI so that anyone can come use it” Right now he’s building theory not a network.
The way I see it, network building is one of the most important parts of development. Without it you have nothing because you need the network to use the product and to even discover what the product’s use cases are. So if one is receiving a large development fund and not devoting time or resources to building the network they are neglecting the responsibilities of a developer.
01:30
Josh
There's only 2k a month from the dev fund these days, you can't pay a lot of salaries with that.
01:31
But you're free to buy veo and develop nice UIs and market it and then benefit from the price going up.
01:54
Crypt Dweller
I think Zack has said this before, but I will try to summarize from memory: He is building the difficult, foundational components of system first, while it is easier to do hard updates and tinker with the design before an onslaught of users comes. Then once he's laid the foundation we can work on marketing and UI and all that. The stuff you call "theory" is not that, Zack is programming his ideas about the best solutions for scaling and oracles, he is actively coding his "theories" into reality. I think the implementation of UI will be relatively easy after he finishes the heavy lifting of completing the system design. Think of all the blockchain projects with shiny UI and aggressive marketing efforts, but serious security vulnerabilities or relatively useless technology, and how few projects are like Amoveo that have intense technological innovation and potential but an unpolished exterior. Zack is going against the herd and doing the hard stuff first--there is a lot of potential value in this approach.
01:55
Josh
Yeah, I agree with this.
01:56
Crypt Dweller
In other words, Zack is basically a modern day philosopher-king 🙂
Zayn Alali invited Zayn Alali
03:26
Toby Ganger
Two problems with that…
1. Like I said before…part of the process of discovering use cases and building up the technological ecosystem of a network is having more and more people come into the network that have ideas, incentive, and skills to facilitate that.
2. The idea that all of the tech needs to be built before the network can be built is wrong because of the reason stated above, but also because you need the network to constantly be using and interacting with the tech to find out what it is, refine it, use cases, to give it functionality and to discover new means of functionality.
And as someone who is not a developer…just an economist and musician…there’s not much I can contribute to the development other than pointing out the economics of social technology or spend time making Welcome To The Blockchain Part 2 (The Amoveo Song) which would obviously be ridiculous
04:06
Another reason we need sortition chains
04:07
Zack
There is a constant struggle in any organization.
Between the success of the organization itself, vs the the goal that the organization was formed to solve.
Over time, every large group of people seems to institutionalize. They abandon their original purpose, and shift to focusing on growth of the institution itself.
If there is ever a choice, between either doing something that will help Amoveo succeed, or doing something to help make scalable blockchain-enforced derivatives a reality, I think we should make the derivatives.
04:08
Josh
If you're an economist you can try to find flaws with Amoveo designs. You can try using the current tech and start up contracts and oracles. You can do marketing.
04:08
I think Zack's time is best spent on the core tech. Not sure what else you want other people to do.
04:12
Toby Ganger
Believe me if I found flaws in its design I would have either spoken up long ago about it, or I would no longer be here. The issue is not with the tech. It’s brilliant.
I am quite literally pointing out an economic problem with the development of the tech which is lack of development of a network alongside it. If this were Bitcoin in 2009 and there were no developers fund then the network has to grow organically. But it’s 2020 in a highly competitive environment and a large percentage of overall tokens designated as part of a developer’s fund...then the majority of the burden for developing that network lies with that developer. I spread it by word of mouth but it’s not enough because without larger attention they can’t even really use it.
04:22
Josh
Ok, good to hear you're excited about the tech 🙂
04:24
I agree that there's a lot to be done to make the tech easy to use, I just don't think we should expect Zack to do everything. My current approach is to try to get other technical people interested. I want them to try to find problems and if they can't, get excited about the tech so they get spread the word.
04:25
If a bunch of us get together we can raise some money for a UI team. It would be awesome to do that with an assurance contract or something.
Deleted invited Deleted Account
05:57
Toby Ganger
Then perhaps we should adjust the dev reward downwards and assign a certain amount of the extra funds available for this sort of promotion..
05:58
Josh
The dev funds are only 2k a month, that's not going to help you much.
05:59
Let's all do what we can.
06:03
Mr Flintstone
once there is a lottery MVP i think the steps forward would be clearer
06:16
Josh
Got any ideas?
06:17
Zack
the ability to spend lotto tickets is probably the next feature after that.
blindzoneplayer invited blindzoneplayer
Deleted invited Deleted Account
08:12
Mr Flintstone
General strategy would be to break the life cycle of participation into clear steps then abstract as much of this into a few simple steps as is possible using a UI. so it’s hard to know until you actually do it the first time at the most granular level
08:16
probably need to make blocks faster, currently 5% or more of the time it would be unacceptably slow UX because of block times randomness
Bakseypor III invited Bakseypor III
09:32
Toby Ganger
That’s more than I get…haha
Deleted invited Deleted Account
09:44
Zack
I couldn't sell it without crushing the price of Veo.
It is either going to be worth 0 to me, or a whole lot more than 2k.
10:31
Jon Snow
When will sortition chain be released?
11:05
Toby Ganger
Same here unfortunately. Not that I want to sell...but if I wanted to...it wouldn’t even be possible...not nearly enough volume or book depth
Budi Santosa 陈贤明 invited Budi Santosa 陈贤明
Amid Huseynov invited Amid Huseynov
14:52
More lightning network privacy issues
Deleted invited Deleted Account
Deleted invited Deleted Account
Mário Rodrigues invited Mário Rodrigues
Deleted invited Deleted Account
Jehluli09 invited Jehluli09
Deleted invited Deleted Account
Daniels Verbeckis invited Daniels Verbeckis
Muhammad Abu Esa invited Muhammad Abu Esa
Deleted invited Deleted Account
02:37
Zack
ive been thinking about how to encrypt a message so that anyone on a list of potential recipients is able to decrypt it.
This problem is the same as calculating some shared secret that we all know in common.
1) choose 256 random bits to be the main shared secret.
2) make an ephemeral key pair.
3) calculated the individual shared secrets between your ephemeral private key, and each of the N potential recipients.
4) calculate the list of encoded secrets by XORing the main shared secret with each individual secret on the list.
5) use the main shared secret as the RNG seed to encrypt the message.
6) publish the encrypted message and the list of encoded secrets somewhere publicly.
So now if any recipient wants to decode the message. they start by combining the ephemeral key with their private key to calculate their individual shared secret.
Then they XOR this with the encoded secret in the list that was published with the message.
This reveals the shared secret, the shared secret can be used to decrypt the message.
02:40
im thinking of making an OTR group chat javascript page, where you use your amoveo private key. so you can be sure that you know who you are talking to.
Erlang makes chat apps simple, and we already have so much crypto tools set up.
I think it could be a cool feature for the light node.
I don't think there exists a product like this today.
OTR group chat is not available.
Daneth Hen invited Daneth Hen
Puth i Chamroeun invited Puth i Chamroeun
04:50
Josh
Wouldn't this be proof that the message came from somebody in the group?
04:51
Zack
once they reveal the ephemeral privkey, then anyone can forge a message.
04:52
Josh
what step is that?
04:56
Zack
a couple minutes after step 6.
04:58
Josh
ok that's the part i was missing 😛
04:58
Zack
The legality of some applications of derivatives is grey. I feel like we would be able to speak more comfortably if we could move some of these telegram conversations into an OTR group chat.
05:01
Josh
you still have to worry about network analysis
05:03
can anybody prove that i'm writing these telegram messages?
05:03
we don't need to prove to other that it's really us
05:03
so why not just do it without encryption and signing?
05:04
if anybody could fake they're you I'd be pretty impressed
05:31
Josh
If a validator stops updating the merkle root, everybody has to do final txs on-chain at the end of the sortition chain. Won't that be very expensive, possibly more expensive than the value they have in the sortition chain?
05:42
Zack
No. Only one person wins. They are the only ones who publish on-chain.
Sortition final spend tx doesn't go on chain until after the sortition claim tx for whoever was holding the frozen funds.
05:43
So, the Nash equilibrium is only one per top-level sortition chain.
No reason to publish a sortition final spend for a claim that you know can't win.
It is a waste of a tx fee.
05:46
trading -> final spend -> rng calculation -> sortition claims -> sortition evidence -> sortition result
05:47
The final spend happens before rng, so we don't know who's going to win
05:47
The point is to get rid of lottery risk, right?
06:04
Zack
that final spend is when they sign the tx off chain.
The tx only gets published on-chain if they actually win the lottery.
06:05
oh, now I remember why if the validators work together they can force you to take on lottery risk.
06:09
if all the validators work together, they can force you to take on lottery risk.
a person will only accept a final_spend_tx payment if they can be sure that the sortition claim it is connect to actually has a chance to win the lottery.
unavailable data might show that someone new is in line. So the money could provably be spent to them, and then the final_spend_tx would be worthless.
But, we can overcome this.
in the payment atomically connected to the final_spent_tx. there can be a clause saying that if a particular kind of waiver is created, then this payment is canceled.
06:21
oh, that doesn't work. because most times they don't win the lottery, so the evidence wouldn't get exposed
06:22
yeah, I guess we do need lots of validators
06:22
this time ill document it better so we don't forget.
ផ្លាស់ប្ដូរដើម្បីភាពជោគជ័យ invited ផ្លាស់ប្ដូរដើម្បីភាពជោគជ័យ
06:27
Josh
I guess I don't understand final spend.
06:27
If it's not on-chain how does the person you're sending to know you're not double spending?
06:28
Zack
because if you make 2, then the money gets destroyed
06:28
like, 2 that aren't identical, and you sign them both
06:28
if you win the lottery, then the prize pool is all burned
06:29
Josh
Ok, I didn't see that in the docs
06:29
Zack
whoever provides the second piece of evidence gets a small reward
06:30
Josh
But the person you're sending to might not get their money either
06:33
Zack
ok, I think I got it.
The people who receive final spend txs. they need to come together and check if any have received a final-spend for value that overlaps with what someone else had received.
In that case, they can both undo the payments atomically linked to the final spends.
06:34
and the double-spender loses their value.
06:37
Josh
Yeah, since it will probably be owned by one guy he won't have to do any cooperation
06:38
Another possibility is to have a period of time for submitting these final spend claims online. They're only valid if at the end of the time there was only one claim.
06:40
Zack
I don't see how that is different from how it works now.
I have been using "claim" to mean a tx with an ownership proof in it.
and "final_spend_tx" for the other tx.
06:41
Josh
When does the final_spend_tx happen?
06:41
Zack
after sortition_claim_tx, and before sortition_timeout
06:42
but they need to have been signed before the RNG process had started
06:43
Josh
How would we know that?
06:43
That they were signed before?
06:43
Zack
we don't.
The users will behave that way for their own self interest
06:44
Zack
if the RNG value is already known, then someone could know if this lotto ticket will win or not.
So they might try to take advantage of people who don't know.
06:45
Josh
So if two conflicting final_spend_txs get posted on-chain the chain is forfeited?
06:45
Won't that mean that the atomic swap won't happen?
06:46
So the winners won't have to cooperate
06:48
Zack
if 2 conflicting final_spends go on-chain, then the $10 000 prize for that sortition lottery is burned.
and the $1 payment atomically linked to the $1 final spend tx also doesn't happen, yes.
>winners wont have to cooperate
you lost me.
06:49
ideally we want to undo all the payments that are atomically linked to double-spent final_spend txs.
even for the people who did not win the lottery.
06:50
people who did not win the lottery are actually the majority
06:51
Josh
Yeah this part is confusing
06:53
Zack
so everyone who received a final_spend_tx, and lost the lottery, they need to some together and see if any double-spend had occured. so they can undo the atomically linked payments.
06:54
Josh
I better get to sleep, maybe we can continue this tomorrow
06:55
I need to understand how these atomic swap payments work
06:56
Zack
waivers have a turing complete smart contract
06:56
you can program them to be valid under whatever condition you want
06:56
and channels in a different sortition chain are programmable with the same VM
07:02
Josh
If I have $1 of value on SC1 and the validators aren't updating, I find someone with value on SC2, get put in the queue behind them and then do an atomic swap between my waiver on SC1 and his waiver on SC2. Now we need to get him next in line in SC1 and that's done via final spend. Is that right so far?
07:02
Zack
final spend doesn't put him in the queue to own value next.
07:03
if I win, then at the last minute he can use the final spend to send my winnings to him instead
07:03
if the validators aren't publishing merkle roots, then we can't add anyone to any line to own value.
07:05
Josh
Ok, makes sense. So how do I get my $1 if lose the lottery?
07:05
Zack
it is already on the other sortition chain
07:06
Josh
It's an atomic swap for the final spend tx that probably won't get posted?
07:07
Josh
So if I'm already on the 2nd chain, how does the other guy roll that back?
07:09
Zack
Lets say Alice was frozen, and she is selling to Bob.
So on SC1, Alice makes a final spend tx giving her value to Bob. on SC2 Alice and Bob have a channel, and Bob offers to give Alice as much value as she is giving him on SC1, conditional on Alice not creating any waivers for that value.
Mark Smith invited Mark Smith
07:09
Zack
As long as Alice doesn't make a waiver, she can't give up her first spot in line, then she can't spend the value, so Bob will get it.
07:12
Josh
How does she get the value if she didn't double spend him?
07:13
Zack
from the atomically linked channel payment on SC2
07:14
Josh
That only activates after SC1 finishes?
07:15
Zack
we could have a clause like "if it is after block H, and the channel hasn't closed yet, then the money goes to Alice."
07:16
Josh
And if she did double spend him?
07:16
Then he can provide evidence in the smart contract?
07:16
Zack
the other clause activates "if Alice signs a valid waiver for this part of the probability space, then the value stays with Bob."
07:17
yeah, Bob provides the signed waiver as evidence with the smart contract
07:17
Josh
I thought she was double spending him by selling two final_spend_txs
07:19
Zack
that is another case we need to handle, yes
07:19
if the validators sign on-chain merkle root commitments and don't share data, then it is important Alice can't make waivers.
if Alice makes 2 final_spend_tx, it is important that she doesn't get paid on SC2.
07:23
Josh
So if there's missing data and we can stop Alice from making waivers, does that solve the lottery risk issue?
07:25
Josh
Back to one validator? 😃
07:32
Josh
Ok now I can get some sleep
07:32
Thanks for all the explanations
Deleted invited Deleted Account
08:25
Zack
it is helpful when you ask questions, the documentation keeps getting better.
Deleted invited Deleted Account
Nuon Udom invited Nuon Udom
Sakku Jose invited Sakku Jose
Carlitos invited Carlitos
Haytham Elniel invited Haytham Elniel
Deleted invited Deleted Account
سليمان الضاحي invited سليمان الضاحي
Itachi San invited Itachi San
17:24
Josh
Do we need channels for this or can we use smart contracts in waivers? I thought we were getting rid of channels.
18:11
Thought it may be of interest
18:28
Zack
We don't need channels. 2-cycles accomplish the same thing.
18:32
Josh
Great, that's what I thought.
18:33
it's probably too early to think about this but i wonder how complex these scripts get, might be worth making them easier with opcodes
18:34
Zack
Chalang is pretty expressive
18:39
Josh
it's turing complete but more opcodes might reduce script sizes and make it easier to write scripts; but it's too early to add any new opcodes, just thinking outloud
18:41
Zack
in chalang you can make a contract with thousands of clauses all Merklized.
So if one participant in the contract breaks one clause, only that one clause needs to get published in order to show who won the contract.
Chalang supports merklized abstract syntax trees.
18:42
Ben
How would that one clause being published be enough to show who won?
18:46
Zack
For example, if we are playing rock paper scissors.
It would involve a commit reveal.
There could be 9 total clauses.
1) If I play rock, and you play scissors, then I win.
2) if we both play the same thing, it is a draw.
3) 0 is rock, 1 is scissors, 2 is paper. If you try playing any other number, then you lose.
...
If the outcome is case (3), then we don't need to include code for case (1).
18:47
If the outcome is (1), then we don't need code for case (3)
18:47
Basically, you only need to publish the parts of the contract that actually get executed. You can prune the code that doesn't get run.
18:47
Josh
cool, didn't realize that
18:48
Zack
We do it with how functions work in chalang.
Every function is named by the hash of its contents.
18:49
Ben
And you pay for space and time with veo?
18:51
Zack
Amoveo smart contracts don't use any consensus state space. They are executed on-chain once to decide how some money should get distributed.
You do pay a fee that is larger if it takes more time to execute the tx.
18:51
Ben
There's a discrete number of computations/operations in a chalang contract that the vm must process and cost gas of some kind though, right?
18:52
Zack
Yes, there is a gas limit written on the tx.
The miner can see how much a fee you are paying, and can see the gas limit, so they can choose whether to include your tx.
18:54
If you only execute one small clause, then you won't need much gas.
18:54
There is also an upper limit on how much gas you can use for one contract. It is set by a governance variable.
18:54
Ben
To prevent infinite resource usage?
19:00
Zack
We don't want a block to take too long to verify
19:05
Maybe using governance to change the maximum contract run time isn't an important feature.
I tried to give the governance system control over lots of different constants. So hopefully we can fine-tune amoveo without needing many hard updates.
19:05
Maybe some of these numbers will need to be adjusted for reasons we don't yet understand.
19:29
Zack
haha, I almost banned you.
People post so many fake "Elon Musk 5000 ETH giveaway!"s
19:37
Elon gives good advice.
Remember that humans are usually wrong, so we should spend more time trying to prove ourselves wrong instead of trying to prove ourselves right.
This is basically the fundamental idea of science. Trying to disprove your own hypothesis.
And that we should judge an idea by it's logical soundness, instead of by the reputation of who said it. That is the foundation of the enlightenment. We can use reason to understand our environment.
جكاره؟ 💔.. invited جكاره؟ 💔..
Deleted invited Deleted Account
Muhammad Sultan invited Muhammad Sultan
Aleksandr invited Aleksandr
Deleted invited Deleted Account
23:01
Josh
There's way more to the sortition finalization than I realized, pretty mind blowing.
23:02
I didn't totally understand how optimistic rollup is connected. Is there any code for that yet?
23:04
Zack
I tried to find some connections between the philosophy behind optimistic rollup and the sortition chain design. but I think it wasn't a helpful direction to explore, so I disconnected that document from the sortition chain documents.
23:15
what are your thoughts about multisig accounts? i find that useful for securing private keys.
23:17
alternatively, schnorr sigs would work
23:29
Zack
yeah, they can be nice.
It isn't directly applicable to Amoveo's value proposal, so it is pretty low on the priority list of features.
23:36
I think it would allow threshold signatures and also batch verification. I think you'd be able to check 64 sigs at a time very quickly.
23:37
Zack
checking signatures faster would be nice. I think they are shorter too, right?
00:16
Josh
"Signatures fit into 64 bytes." "Public keys consume only 32 bytes."
00:18
I think bitcoin's are 71 bytes?
Tajin Hasnat Riad Nawabgqnj Health Complexd Dianjpurmbbs Dmc invited Tajin Hasnat Riad Nawabgqnj Health Complexd Dianjpurmbbs Dmc
01:23
Zack
im thinking for the group deniabilit messager, we want to break apart all the (main secret) XOR (individual secrets), and send those as encrypted messages to each participant individually.
That way we aren't necessarily leaking who is the list of people we are messaging.
You could message one person in the group, or everyone in the group, and the recipients don't know the difference.
01:32
So like, the encrypted message is published somewhere once, so anyone can download it.
Then tools to decrypt it are sent as encrypted messages to everyone who you want to be able to read it.
01:44
I'm not sure it's so useful for this kind of chat though
01:44
I'm not worried about someone impersonating you
01:44
Although I suppose that's a problem on Twitter
01:45
Zack
if you are discussing with someone about a smart contract you will make together, it is nice to know that the person talking to you is who you will make the contract with
01:45
Btw, why not have a rental fee on accounts instead of a delete reward?
01:46
Zack
I figure everyone will be using memoryless full nodes eventually.
So the cost of adding one more account is basically zero.
01:46
the cost of maintaining one more account
01:47
the only person who needs to remember something extra is the owner of the account. It doesn't give any ongoing cost to full nodes.
01:48
Amoveo blocks include all the merkle proofs for all the data you need to verify the block.
So you don't need to maintain any database of channels or accounts or anything, if all you want to do is verify blocks.
01:48
Josh
So why give them a deletion reward?
01:48
Zack
do we? I think that might have been removed
01:48
oh, I think we got rid of delete_account_tx all together
01:49
Zack
yes, fork #20 got rid of them
01:49
Josh
Ah ok, was going by that page.
01:49
Zack
got it. ill update the docs
01:49
Josh
Ok that's awesome
01:50
Zack
it was a tough decision to make.
It means an amoveo tx is more than 10x bigger than a bitcoin tx.
But I think it works well with sortition chain, because the number of on-chain txs will be very low.
01:51
that is why we can verify Amoveo blocks concurrently.
01:52
It also makes block verification very fast, because you don't need to touch the hard drive.
Block verification can be 100% in RAM.
01:53
deleting accounts was bad, because if anyone re-created that same account using their old private key, the nonce connected to that account would start at 0. so old txs could get re-broadcast.
01:56
The big trade-off is that including all the merkle proofs means 10x more data on the wire to sync the blocks, but the advantage is that you don't touch the hard drive.
So, this strategy makes sense for blockchains where accessing the hard drive is the bottleneck, and they have at least 10x more bandwidth available than they are using.
01:58
In my experience, bandwidth costs are falling fast. fiber optic cables makes it very cheap.
Scanning a hard drive sequentially is also very fast, like if you were re-syncing sequential blocks from a hard drive.
But accessing random parts of a hard drive to read from or write to a merkle tree, this is slow. I think this is the bottleneck for most blockchains.
02:31
Josh
Yeah I agree with that
02:32
What's the best doc to read about how txs work now with the merkle proofs?
elmer santos invited elmer santos
02:52
Zack
Maybe look at a block.
The proofs.erl page might be helpful. You can ask specific questions here.
02:52
Each tx type has rules about how to make the proofs
KHEAM SEAK invited KHEAM SEAK
Deleted joined group by link from Group
Deleted joined group by link from Group
17:25
Josh
I wonder if that idea for exposing double spends on the 2nd SC can have other uses.
17:28
Hmm I don't think my original idea would work.
20:06
Zack
yeah, like attacking PoS blockchains.
We can make smart contracts that reference events happening on the PoS blockchain to properly enforce bribes.
20:15
Josh
that's not what I was thinking but sounds interesting
20:16
another thing I was thinking about is what if we only had sortition chains in amoveo, not regular accounts; even mining rewards would come in sortition chains
20:18
Zack
so like, ever block reward would start a new sortition chain containing 0.15 VEO?
20:18
im not sure how that would be helpful
20:19
We could probably set it up so when a sortition chain ends, instead of paying out to the winner's account, it just creates a new sortition chain where the winner owns 100%
20:20
but then the sortition chain would stay the same size forever, right?
20:20
we already have the ability to claim your winnings from a sortition chain, and publish a tx creating a new sortition chain, all in the same block.
20:21
so making it mandatory to do both things together is only getting rid of features, not adding anything new
20:25
Josh
my motivation was: (1) reducing the need to transfer funds from a regular account to buy funds in a sortition chain, this is a relatively big on-chain tx; if all funds are in sortition chains, all transfer txs will be off-chain, the only on-chain txs would be sortition txs; (2) simplifying concepts: before we had accounts, channels, SCs, now we'd only have SCs.
20:44
Zack
yes, you can do atomic swaps between sortition chains.
Eventually it should even be possible to do atomic swaps between Bitcoin and a sortition chain. So you can buy veo, participate in a smart contract, and then cash out back to Bitcoin, all without having a single byte about you on Amoveo. Not even your account address is recorded.
20:46
Josh
Another possible advantage is that it builds up the sortition chain market from day one and not just when on-chain fees get high.
20:47
Zack
I think people will use whatever tools we make convenient to access from the wallets
20:47
Josh
also, the privacy advantages from SCs are stronger if everyone is using SCs
20:48
Zack
SC has privacy advantages?
20:48
Josh
yeah, your txs aren't on-chain
20:48
and they're cheaper so you can do lots of fake sends
21:06
Josh
another thing I was thinking about is I'm not so sure about payment hubs; in amoveo they only give you instant payments, not scalability and to get that instant payment functionality for X coins, you need to lock up those X coins and wait until they're locked up; your hub has to lock up X coins just for you for the amount you want to instanty receive; there's a lot of extra middlemen, machinery and capital lockup for all this
21:07
Zack
It is a significant improvement over a lightning network of 2-party channels
21:07
Josh
one alternative is to have very frequent blocks, say one block per second; the downside is there will be 600 times more headers that light clients will have to download and process, which sucks; but if we have fairly frequent checkpoints maybe that's managable and then we don't need payment hubs
21:08
another advantage to this is it lowers the barrier to becoming a solo miner
21:08
Zack
the network of hubs isn't just about instant payments. It is so you can instantly participate in a trading batch in any market without needing to lock money into that market ahead of time.
21:09
If you need to wait for an on-chain tx and confirmations before you can trade, then you will be too late. Someone else will buy what you wanted before you can.
21:10
Block time is set by futarchy. So if you think faster blocks are better and you want faster blocks, you should use the futarchy governance process to make the change.
21:11
there is a network delay cost of mining.
((delay to broadcast a block)/(average block time)) * (1 - portion of hashpower that you control)
So faster block times punish smaller mining pools and solo miners.
21:13
We want to number of sortition chains to be very big.
If a sortition chain needs to have an on-chain merkle commitment in every block to be usable, that would limit how many sortition chains we could support at a time.
I want sortition chains to be useful even if they only have one on-chain commitment per month. That way we can be as scalable as possible.
21:14
Josh
this wouldn't work unless we used a blockdag like spectre
21:15
you could still have tons of sortition chains, this would only affect the top level of sortition chains, right?
21:16
Josh
i know iota is broken but i didn't realize that was about blockdags in general, i'll read that
21:16
Zack
no.
If the same validator is operating many sortition chains, a single merkle root can confirm for all of them.
But if you have baby sortition chains with different validators, they need a different on-chain merkle root.
21:18
Even if one person was acting as the validator for all the sortition chains, he wouldn't want to use a single private key for everything.
Putting a single private key onto many different computers is not secure.
And he would need many computers to process all those payments on all those sortition chains.
21:19
Josh
the parent doesn't need to check the whole baby tree, he just needs to check the baby root sig
21:19
Zack
Anyway, simply making the blocks faster doesn't help finality at all.
The amount of finality on a tx is (number of confirmations)*(block reward per confirmation)
21:20
idk what you mean. what is a "parent"? what is a "baby root sig"?
21:21
Josh
this isn't about DAGs it's about PoS; I searched amoveo-docs for blockdag, and dag and nothing came up
21:22
Zack
so like, if we made blocks 10x faster, and reduced the block reward per tx by 10x, then the average amount of time you need to wait doesn't change. you need to wait 10x more confirmations, and each confirmation happens 10x quicker.
21:22
Josh
it's not supposed to make finality faster, it's supposed to solve the orphan problem
21:23
Zack
my argument is that DAG is secretly a kind of PoS.
which is similar to the gnosis ring-batch review I made.
21:23
Josh
the parent SC; baby root sig is the baby's validator signature of the root of the merkle tree of the baby SC
21:24
Zack
you suggested faster blocks as a way to improve sortition chains. This is an argument for why faster blocks will not improve them.
21:24
a SC can't "check" anything. it is a bunch of data structures, not a person.
21:25
Josh
it helps because of the continuity; currently you have zero security for 10 minutes, then you have some security, then every 10 minutes you get exponentially better security
21:25
with blockdag you have some security after 1 second and every second you have exponentially better security
21:25
the amount of time you have to wait depends on how much security you need for the tx
21:26
Zack
I think DAG offers zero security.
21:27
if we use the hub strategy, you can have total security instantly.
21:27
Josh
the bitcoin chain is just a special case of DAG, so that means bitcoin has zero security
21:28
yes but there are tradeoffs like capital lockup and freeze risk
21:29
Zack
you can start with any secure tool, and then if you generalize it enough, you end up with something insecure.
21:29
making something more specific preserves security assumptions. making it more general can break security assumptions.
21:29
Josh
valid point but you have to show what in the generalization breaks the security
21:30
the parent SC validator checks it when he constructs his merkle tree and signs the root
21:30
Zack
We can only atomically connect different smart contracts if we use channels and hubs.
If you use on-chain smart contracts, or sortition chain smart contracts to try and run markets, then the miners can front run you.
21:30
I did write a paper about why DAG doesn't work.
21:31
the sortition chains are independent.
If the validator of a parent sortition chain had to be aware of all the child sortitoin chains, then it would not scale.
a baby sortition chain has the same relationship to it's parent as it has to any other sortition chain.
21:32
Josh
why not? it already has to check the signatures of all the ownership requests, what's the difference?
21:33
do you have a link?
21:33
Zack
I sent it. about IOTA.
21:33
what is the difference between what?
21:35
Josh
I don't see how that applies to Spectre which is 100% PoW.
21:37
between checking the sig on an ownership request and updating the merkle tree to add that ownership leaf and checking the sig on a new baby chain root and updating the merkle tree to chage that baby chain leaf (it's a leaf in the parent merkle tree and a root in the baby merkle tree).
21:40
the baby sortition chain is a kind of ownership leaf.
Adding a baby sortition chain is the same process as putting an account in line.
The baby sortition chain stands in line too.
only, the baby sortition chain cannot give up it's spot in line.
If I make a payment on the baby sortition chain, the validator of the parent sortition chain doesn't have to know, he doesn't care at all.
21:40
I am guessing that they don't want anyone to understand what they made.
21:40
Josh
there are lots of blog posts about it
21:42
a lot of those pages are about simulations and mathematical proofs, the explanation is actually pretty simple.
21:43
right but he could update his merkle tree to incorporate the new root, that way the baby chain validator wouldn't have to post an on-chain tx
21:43
Zack
are there 2 SPECTREs? it seems like this is related to GHOST and ethereum uncles?
but you were talking about DAG.
21:44
Josh
in this context, dag just means directed acyclic graph
21:44
ghost is based on early work from these guys but ethereum implemented it wrong
21:52
Zack
I was designing it that way at first, but it has issues.
1) if the validator of the parent SC stops signing roots, then all the baby sortition chains get frozen.
If I want to receive a payment on a baby sortition chain, I need to be sure that I am actually second in line.
So I need to download the entire history for that part of the probabilistic value space.
so that means I need a merkle proof of my part of the probabilistic value space for every single on-chain commitment.
2) we can't tell the difference between a parent validator refusing to include the correct root for a baby sortition chain vs the baby chain's validator refusing to provide the correct root. So when things go wrong, we don't know which validator to blame and stop using.
21:56
my understanding of GHOST is that by including uncle blocks a PoW blockchain can have faster blocktimes, but there is a trade off that they have less total security for a given level of block reward, because an attacker building a fork can include his blocks on both sides of the fork an get paid on both sides.
21:57
Josh
GHOST doesn't use a dag, it has this weird uncle system, so spectre is a big improvement
21:58
I think spectre has a higher level of security for a given block reward than bitcoin because we're not wasting the orphans
21:59
ok, if that was your original design I already feel good about thinking of it 😉
21:59
Zack
if the block rate is 10 minutes per block, there are almost zero orphans
21:59
Josh
yeah so for a 10m block time the security would be the same
22:00
"1) if the validator of the parent SC stops signing roots, then all the baby sortition chains get frozen." -- true
22:00
Zack
orphans can be included on the attacker chain too.
So it makes attacks cheaper.
22:00
main chain blocks are orphans for the attacker chain
22:02
Josh
these are drawbacks but eliminating the on-chain txs is huge, so are we sure it's not worth the tradeoffs?
22:04
Zack
https://medium.com/@drstone/an-overview-of-spectre-a-blockdag-consensus-protocol-part-2-36d3d2bd33fc > It utilizes a recursive voting procedure based on the precedence of blocks in any topological sort of the underlying DAG. In this voting procedure, every block submits a vote for every pair of blocks. We will tally up these votes in order to decide the set of accepted transactions at any moment in the execution of the consensus mechanism.
They are admitting that there is a voting protocol inside. Which means this is a hybrid PoW/PoS protocol, like I had written in my review.
22:06
Josh
bitcoin also has voting in that sense, each block is voting for the previous block
22:06
Zack
What many blockchain designers fail to consider are the soft fork bribery attacks.
A soft fork is an update made entirely by censorship.
A soft fork can be used to do any kind of update to a blockchain protocol. it can switch PoS to PoW, or PoW to PoS, or move the money around, anything at all.
22:07
So if it cheap to bribe validators to cause a soft fork, then it is not secure.
22:07
in bitcoin if your block is orphaned, you don't get a block reward.
22:07
Josh
they are using voting just to mean references to previous blocks
22:08
Zack
bribing a bitcoin miner to mine orphans is as expensive as the block rewards they would have received on the main chain.
22:12
soft fork attacks allow you to steal the money without having to do any double-spends, and without rewriting any history.
22:22
The attack against DAG is like this:
bribe some of the miners to add a new rule about what kinds of txs they accept.
These miners will not build on top of any block that breaks the new rule, but they still publish their blocks right away.
Honest miners will build on top of attacker's blocks, because the attackers are obeying the entire rule set that the honest miners know about.
eventually, enough honest miner blocks are being orphaned, so they switch to the new ruleset so they can get better block rewards.
In bitcoin you could only achieve this by paying at least 50% of the block rewards for an extended period of time.
with DAG you still get paid even if you censor the honest miner's blocks. So the cost of the bribes is very low.
22:26
This kind of analysis is not valid.
There could be many txs that get undone simultaneously, the potential profit of an attack isn't limited by the value of only your tx.
Even a low-value tx needs a lot of finality to become confirmed.
22:26
Josh
this is interesting, i'll have to think about it
22:31
i don't think they talk about that attack in the paper, which is a bad sign
22:36
Zack
I think I am the only person who writes about soft fork bribery attacks, haha.
This is what PoS is vulnerable to as well.
22:36
Josh
but i'm not sure spectre has orphans at all
22:36
Topab
I like the OTC idea you proposed Zack. Do you think it's workable in the short term?
22:37
Josh
if you mine a valid block, all the nodes will accept that block, it doesn't matter what the other miners do
22:37
Zack
what idea? you mean off-the-record messaging?
or are you talking about the existing P2P derivatives tool, which we had called "over the counter derivatives"?
22:38
there are rules about removing contradictory txs though.
22:38
Josh
yeah but that doesn't invalidate the block
22:38
Zack
as long as the attackers can censor txs, they can change the rules and steal the money.
22:39
Josh
they can't because i can mine an uncesored block and all the nodes will accept it
22:39
the other miners can't stop me
22:39
Zack
if the majority of other miners are preferring to reference a block that contains a contradictory tx, then the txs in your block will get censored.
22:40
Josh
no, only the conflicting tx gets censored, not all the other txs
22:40
and a conflicting tx is a double spend
22:47
Zack
what is the incentive to get votes on top of your block at all?
22:47
Josh
maybe there isn't an incentive, you just need to be recognized by the nodes
22:51
Zack
Is that even computationally feasible?
It seems like the inter-dependencies of which txs are contradictory with each other could be really complicated.
A small reorganization in recent state could require re-processing large amounts of history to re-calculate which of the txs are now valid and which are censored.
22:54
Josh
i think they talk about how it's hard and that they have an efficient implementation
22:55
Zack
according to the spectre paper:
> each miner is required to(i)reference recent blocks, and to(ii)publish his blocks immediately.
but, we can't tell the difference between attackers who are failing to publish immediately vs recent honest nodes aren't being referenced by the attacker.
because of the speaker/listener fault equivalence.
22:56
Josh
i don't think you get punished for not publishing immediately, that's just the "honest" behavior
22:56
Zack
so, there is an assumption that miners will obey rules.
What if I bribe them to not obey?
22:56
Josh
what's the incentive in amoveo to include any transactions in a block?
22:57
Josh
i thought there weren't tx fees
22:58
Josh
ok i thought i read that somewhere
23:00
maybe the faster you publish a spectre block the better chance you have of getting the tx fees for those txs
23:00
but i am starting to get convinced that this is too complicated
23:02
Topab
Sorry, I got confused. I thought this was OTC instead of OTR. I want to buy some more veo but given the low liquidity it's not possible.
23:05
Zack
https://github.com/zack-bitcoin/otr_messager I started building it here.
But really, I am more interested in learning how to make better API.
Currently all the API for Amoveo are like, I request something, and immediately get a response.
But I want to be able to request something, and the HTTP request lasts for like 30 seconds ,so if it the thing I want appears in those 30 seconds, it can be immediately sent to me.
This is important for making block propagation and tx propagation happen faster, and I think it will result in better UX experience of sortition chains.
Although it looks like adding the final touches to make OTR group chat possible wouldn't be much more effort.
23:06
https://eprint.iacr.org/2016/1159.pdf on page 17 section C they are talking about censorship attacks.
soft fork bribery attacks are a kind of censorship attack.
But they don't go very deep into details.
A 66 page paper, and the part that matters is only 1/2 page. haha
23:09
But it seems like they are making an assumption that the majority of miners will honestly report about which tx they had seen first.
The idea that miners are even capable of being aware of all the txs, to be able to know which came first. That assumes that every miner is looking at every txs and checking for contradictions with every other tx.
Which means tx processing between nodes is not concurrent.
Which means it wouldn't be able to process txs faster than a normal bitcoin PoW protocol.
Also, assuming that miners will honestly report which tx they had seen first, even if there is not financial incentive to enforce them to report honestly, that is a vulnerability based on my model of trust theory
https://github.com/zack-bitcoin/amoveo/blob/master/docs/basics/trust_theory.mdIf the cost to execute an attack is zero, then it is not secure.
23:11
Josh
i don't think it matters much which transaction they saw first, since this is only an issue for double spends.
23:12
Zack
any tx could potentially get double spent
23:13
if preventing double-spends requires them to honestly report on which tx they saw first, and any tx can potentially get double-spent, then that means they need to be aware of all the txs and when they first saw them.
23:13
oh, I guess they are just reporting which block hashes they saw first, not the individual txs
23:14
but i also don't think there's that much to gain from all this
23:14
Zack
still, we can't assume that they will honestly report on the order that they had seen block hashes, if there is no financial incentive.
23:17
It was also nice to review the Amoveo crypto tools, and erlang basics to build this.
23:20
Josh
would websockets help with that?
23:29
Zack
it seems like this is what websockets were designed for.
But I got it working with normal http requests.
what is nice about http requests is that they work for browser-server relationships, and server-server relationships, so I don't need to write 2 api.
I guess I should try out websockets to find out if they are better.
And I should probably try out using sockets for communications between full nodes.
23:31
JSON-RPC over HTTP is really common. You can use things like CURL or WGET with it.
23:49
Zack
https://sookocheff.com/post/networking/how-do-websockets-work/Seems like websockets are only better than long polling because less server resources are tied up.
But an erlang thread is so light, it is practically free anyway.
I feel it isn't an important upgrade at this time. And that websockets could result in worse maintainability.
23:54
Josh
Yeah websockets have their own issues
23:57
I think it's worth weighing these tradeoffs. This would allow really massive scaling.
23:58
in the current design, baby chains only give us off-chain advantages but still require the same on-chain footprint as top-level chains, right?
23:59
Zack
it isn't just a trade-off, it makes it broken.
If a validator stops participating, we need to know which validator did it, so we don't use them as a validator again.
23:59
yes, but the on-chain footprint can be very light.
one tx per week could still be a useful sortition chain.
00:01
Josh
you mean one tx a week would be useful for a top level chain? because for lower level chains we're going to need to be adding ownership records all the time to join payment hubs.
00:01
and even to top up our SCs to the hubs
00:02
Zack
top level/lower level are the same
00:03
being able to refill channels more frequently would be nice.
If you have a channel with a hub, and someone in that hub is also in a hub in a different sortition chain that is about to have an on-chain commitment, you could swap your value from the chain that wont have a commitment for a while, and put it into the chain that is about to have a commitment.
00:06
Josh
why can't they just use a new pubkey? how would we know it's them?
00:07
Zack
if you aren't going to use Amoveo for a few hours, maybe you would be willing to swap your tokens from a fast sortition chain into a slower one.
That way someone from the slow sortition chain has a chance to do things faster while you are gone.
I need to do a little work to make sure setting up the channel can safely be done in only a single on-chain commitment.
Maybe each sortition chain will make commitments in pairs. 2 blocks in a row, then a long period without a commitment.
00:08
if he uses a new pubkey, then he needs to build reputation over again.
I guess that if a new pubkey makes a sortition chain, people wont be willing to pay as high fees to buy value in it, in comparison to someone who has been a good validator many times.
00:08
a validator can use their old key to sign over a new one, if they want to use the same reputation between different keys.
00:09
Josh
but they have no incentive to freeze the chain anyway
00:09
Josh
so if they don't care about doing something stupid why would they care about losing their reputation?
00:10
Josh
it's not rational to freeze the chain, only an irrational player would do it
00:10
Zack
irrational, or unskilled
00:11
keeping a server active requires some kind of skill
00:11
you could accidentally spill a drink on it, and not have a backup of your private key
00:13
if someone can cause systemic errors in Amoveo, then they could short VEO on some other blockchain.
00:13
if we can't identify and exclude which validator is causing problems, then the problems will keep happening.
00:14
Josh
so I can build up a great reputation in amoveo and become a big validator, then short veo and freeze everybody
00:15
Zack
you can freeze the sortition value for a few weeks. then everyone can use final_spend txs to get their money out
00:15
and then they wont use you as a validator again.
00:16
Josh
right but if the attack paid off I'll just build up my reputation again and do the attack again
00:16
Zack
I guess if one person was the validator for many sortition chains, and he used multiple keys in different computers, then it might make sense to have him do a single on-chain commitment for all his sortition chains at once.
00:17
if the damage is only temporary, would it have a measurable effect on price?
locking up VEO reduces the supply of available veo. It could even make the price go up temporarily.
00:17
Josh
but that means there's an advantage to scale of having one entity own a lot of SCs, which means we'll end up with a monopoly
00:19
it could, it shows amoveo isn't as smooth as expected, it could disrupt a lot of real life things
00:20
Zack
If only one person owned all the SCs, then there would be at most 1 commitment per block.
but a block can fit hundreds of commitments.
So the cost for more people to start being validators for SCs is the same as the cost of the existing validator.
If the cost of a new competitor joining the market is the same as the existing service provider, then that is not a dangerous monopoly.
monopoly is only dangerous if there is a big moat against competition, so that the existing provider can exploit his users.
00:21
and if Amoveo smoothly recovers from the disruption, that could show how powerful Amoveo is and have a positive impact on the price.
00:21
The validator who freezes the sortition chain, he is forgoing a lot of future sortition-fees he could have earned.
00:22
the size of the disruption is proportional to the amount of fees he is forgoing
00:23
Josh
that's interesting; i'm not sure if that's true, it's like a terrorist attack
00:23
Zack
why would you use a sortition chain with a validator that you know has frozen a sortition chain in the past?
00:23
Josh
he can keep on attacking a few times to show that amoveo keeps breaking down
00:24
he would attack with a new pubkey after building up a new reputation
00:24
Zack
how can he attack a few times, if he loses all the customers the first time?
00:24
as long as some other people are being validators and not doing these attacks, eventually they will have all the customers.
00:25
A validator can choose to reveal their human identity, if they wanted
00:25
Josh
then they'd be susceptible to regulation
00:26
if we're not worried about sybil attacks this gets pretty easy
00:27
Zack
a validator could use a prediction market to show that a sortition chain wont get frozen.
00:28
Josh
hmm, so anybody betting long veo could hedge their risk with that?
00:28
Zack
A validator could reveal their identity to specific people.
If the owner of the biggest mining pool recommends a particular validator, that would help them get more customers.
00:28
betting long-veo is different from betting that a sortition chain will freeze.
00:29
Josh
that's why you hedge
00:29
you're betting that veo goes up, assuming it doesn't get frozen
00:29
Zack
We could have a single prediction market connected to 1000 different sortition chains. so if any one of them get frozen, that activates the prediction market
00:29
you can bet that a sortition chain will get frozen, and have the bet denominated in stable-BTC synthetic assets.
00:30
the prediction market could be denominated in stable USD contracts
00:31
Josh
who would bet that a chain would be frozen?
00:32
Zack
if the price is good enough, anyone would
00:32
Josh
if you know the validator is on the other side? only if you think he might spill his coffee.
00:32
or if you can turn off his computers
00:33
Zack
if it costs me 0.00001 veo, and I can win 1 veo
00:33
the market price will always reflect the odds of the event occuring.
00:33
Josh
only if there's that chance that it gets frozen
00:34
but by taking the other side of the bet, he's incentivizing you to hack him
00:34
Zack
there was already an incentive to hack him. he has a private key connected to money
00:35
Josh
if it's only connected to the validation, the most you can do is freeze people not take any money
00:35
Zack
there is a cost to being a validator in that you need to buy up lots of VEO and lock it into a sortition chain for a long time.
If no customers make constracts in your sortition chain, then you are left holding unsellable VEO for the lifetime of the sortitoin chain.
00:36
Zack
so that prevents sybil
00:36
Josh
yeah it's expensive to build reputation
00:37
Zack
you can build reputation by starting wth very small sortition chains
00:37
but if you lose your reputation, you are left holding a big one.
00:38
Josh
you're not left holding the chain if you've managed to sell it all off
00:39
maybe you're more trustworthy if you have a bunch of chains with the same pubkey that aren't sold off yet
00:39
Zack
retirement attacks are a mixed equilibrium anyway.
As long as the frequency of attack is very low, it isn't an issue
00:39
the frequency of attack is higher if you can build reputation faster, and if you can profit more from attacking, and if the trading fees are lower.
00:40
freezing funds might have some small effect on the price of veo, so the potential for profit is low.
00:40
Josh
it's also a function of how much you're making on SC fees
00:41
Zack
Users could look at historical graphs relating the cost of SC fees with how frequently funds get frozen, and choose a sortition chain with a fee size that is tolerable for the amount of risk of freezing that they can handle.
00:41
there should be some limit above which it never makes sense to freeze
00:43
Josh
maybe the freeze market could also work; if I can hedge my long veo with freeze protection, I'm not hurt if the price of veo goes down because of a freeze; that means it's more expensive to buy shorts and less profitable to do the attack
00:44
Zack
trades in a freeze market are still enforceable, even if it gets frozen.
00:44
Josh
i know, this is a defense against the freeze attack
00:45
Zack
a sortition chain could have a smart contract dividing up the space of value in it. so the validator is holding 20% all the time, and if it gets frozen, then everyone who was frozen gets compensated 25%, and the validators money is gone.
00:46
Zack
what about the case of partial freezes though?
Like, if the validator refuses to put anyone new in line for one particular part of the probabilistic value space?
00:46
Josh
isn't the problem that we can't prove it's frozen?
00:47
Zack
I guess I could publish my request to have someone new put in line, and make an oracle asking if my request will get fulfilled before a particular block height, and that would prove that it had been frozen
00:47
or maybe gossip is better.
Just send around the message that I have a request that isn't being fulfilled
00:48
Josh
i think we'd need to know that the validator has access to the record
00:48
Zack
well, an unmeasurable partial freeze wont change the price of veo anyway, so the validator couldn't profit
00:48
Josh
i guess anybody betting that it won't be frozen will send it to the validator
00:49
Zack
ill be back in like an hour
02:34
Zack
Another kind of attack that can happen in blockchains is where you walk the line between finalizing 2 different possibilities.
Like, if you build one block on fork A, then one on fork B, then one on A, then B, then A...
So the txs that conflict on either side can't get finalized.
It seems like in the case of DAG, this kind of attack could create computational issues. Because the computation to know which txs are valid can get very complicated.
02:35
--------------
about the sortition chain commits.
I think I was wrong before when I said we wouldn't be able to tell which validator was causing problems. There are ways for the honest validator to show that they are honest.
02:36
And the issue
@jmharvey mentions, about how there is a linear on-chain cost for the sortition chains is true.
So maybe it would be better if the child sortition chains could pass their commitment to the parent chain.
02:44
But I guess we will be really really big before this matters, right?
So we can just kick the can down the road, and do that upgrade later?
02:46
If each sortition chain can have the network capacity of bitcoin, and they each have 1 on-chain commitment per day. and there are 130 blocks per day that can each hold 1000 txs.
That is 1000 * 130 * 5 tx per second is 650 000 txs per second
02:51
Mr Flintstone
updates can be politically intractable but as long as there is a culture around markets making decisions for us probably is fine
02:53
Zack
if everyone on earth did 1 tx per day, that is only 100 000 tx per second.
If we can at least achieve that level of scalability, we should be good enough for now.
02:56
Mr Flintstone
galactic scaling will have to wait!
03:00
Josh
But 1 tx per day is pretty limiting. If I need to top up my payment hub, I can only do that once a day?
03:00
Zack
5 tx per second per sortition chain is not a good estimate.
Unlike bitcoin, the sortition operators are centralized, and they don't need to spend 90% of the time passing messages between miners.
I think they could do at least 1000 tx per second.
bringing the total to 130 million tx per second.
Which should be enough for at least the next couple of generations.
03:00
which would be 1000 txs per person per day, given the current population of earth.
03:01
I guess people in this forum are more rich than the median human, we could probably afford 100 000 txs per day pretty easily
03:01
Josh
I'm interested in how the validator would prove he's honest
03:06
Zack
so the baby-sortition validator, he signs the merkle root for the next on-chain commitment, and he sends it to the parent-sortition validator who ignores it.
Then the baby-sortition validator sends the same signed root to a bunch of users, so we can all see that he tried to do the update.
The other users can send the signed merkle root to the parent-sortition validator, and see that it is not accepted.
03:48
Zack
it is easy, because we don't have to actually prove any of this on-chain.
We just need a way for the users to know which validators shouldn't be used for sortition chains in the future.
03:49
So why not just scale this way?
03:49
Anybody who doesn't want to risk the parent freezing their SC can do a main chain SC
03:52
Zack
It is definitely worth considering. I think we should reflect on the idea a little more before deciding.
I think the reason I had rejected it before, is because I had thought that it was secure to seperate the sortition validator's job from the on-chain committer's job.
So there would be 2 specialists.
And then I ran into data availability issues, so I thought that meant each sortition chain's validators had to commit on-chain individually for their sortition chain.
But now it seems like as long as the validator of the main chain is the one doing the committing, it could work.
03:53
So lets say Alice is the main sortition chain validator, Bob makes a baby sortition chain inside, so he is level 2, then charlie makes a baby sortition chain inside Bob's chain, so Charlie is level 3.
I am wondering, does charlie send his merkle root to Bob, or Alice? does it matter?
03:56
Josh
If he makes it in Bob's chain he has to send it to Bob
03:56
Josh
Bob has to update his root and sign it, Alice can't do that
03:57
Zack
As long as I can prove that Charlie had assigned me ownership to some probabilistic value space before he had assigned the value to you, why would it matter if the proof involves Bob or not?
Deleted joined group by link from Group
04:00
Josh
My mental model is that it's not one big tree. It's 3 separate trees. Alice's tree ends with a leaf which is Bob's signed merkle root. Then Bob has a whole tree with a leaf that's Charlie's merkle root.
04:03
Even if Alice could, she wouldn't want to because if she wanted to control a huge tree she wouldn't accept baby chains.
04:05
Zack
an on-chain merkle root, it just contains who is added next in line.
If I am first in line, and you want to become 2nd in line, then the sortition operator would stick you in the next version of the tree, and I would not be written in the new tree at all.
my ownership proof is connected to an older commitment that occured at an earlier block height.
04:06
Once Alice makes Bob's baby sortition chain next in line to own some value, she can't take that away from him. Even if she listed someone else as the owner for that value later on.
04:08
If Alice was going to record Bob's merkle root on-chain, it wouldn't even be a part of the normal ownership merkle tree.
She would have a different merkle tree of all the roots from baby sortition chains, and then combine that tree's root with the ownership merkle tree's root to produce the master root. and she would put the master root on-chain.
04:17
Josh
I'm a little lost here. But how would Alice change her tree based on Charlie's chain, without Bob?
04:18
Zack
Alice can make a merkle tree out of all the signed ownership tree roots from people like Charlie, and post that on-chain.
If I can show that Charlie signed a merkle root giving me control of some of the probabilistic value space in Charlie's sortition chain, it doesn't matter what Bob thinks.
04:21
the draw-back of letting Alice publish Charlie's root directly, is that Alice can selectively freeze Charlie's sortition chain without freezing Bob at the same time.
04:21
idk if that matters though
04:23
maybe this upgrade isn't worth thinking about.
Seems like getting something operational soon is more important than solving this problem.
04:25
Josh
Right but is it even worth having baby chains at all?
04:29
Zack
yes.
the ongoing cost of on-chain merkle proofs is currently proportional to the total number of validators.
the settlement cost, including the RNG process and potentially processing smart contracts on-chain, is only linearly related to the number of level 1 sortition chains.
if we didn't allow for baby sortition chains, then the settlement cost would be proportional to the total number of sortition chains.
04:31
one validator can be a validator for many sortition chains at once.
so the number of sortition chains can be a lot bigger than the number of validators.
04:33
Josh
ok, good point. but the settlement cost might be tiny compared to all the updates during the chain operation.
04:34
i think in the beginning chain operators will publish every block (if there's an update). it will be almost free and customers won't want to wait to join the SC.
04:35
Zack
The updates are a constant trickle. Each one is a signature over a 32 byte merkle root. And we only need one or two per day for the course of a month.
On-chain settlement could involve posting large smart contracts on-chain, all in a short period of time.
04:37
At first it will probably be just me operating several sortition chains.
So I could do one commit per block for all my sortition chains at once.
04:39
Josh
Only if there's a challenge, which there probably won't be because nobody would gain anything.
04:41
Zack
We measure scalability based on the worst case.
Otherwise an attacker who can push us into the worst case can break scalability.
04:41
So we need to assume that lots of false claims will be made for each sortition chain, and that the honest winner will need to provide evidence for all those claims to show that they are false
04:44
alright, back to the original plan
04:45
hmm, my only thought is that baby chains might introduce a lot of complexity and edge cases at this point and there's still plenty of scaling for now, so they could be introduced in a second phase.
04:59
Zack
It doesn't seem complicated to me. We have this code written with passing tests.
If we don't support baby sortition chains from the beginning, then we might easily do an update that makes it impossible to add later.