12 April 2020
00:15
Deleted Account
Hi
Is amoveo Scam ?
Z
00:18
Zack
In reply to this message
I didn't sell any Veo yet.
I put a lot of work into amoveo over these last 2 years.
I was studying the tech for 4 years before that, and preparing to make amoveo.
00:18
There was no premine. No crowd sale. No ico.
00:18
No advertising budget.
00:21
Hahaha
00:30
Deleted Account
In reply to this message
Good, you dont sell because there Is not liquidity and a good exchange ?
Z
00:43
Zack
I want to be a trillionaire.
I'll wait until amoveo is the next world reserve currency to sell.
JS
01:44
Jon Snow
In reply to this message
A serious question, how long can you support yourself working on this without selling your VEO?
A
01:50
Alex
In reply to this message
And by sell, he means buy. When VEO is the world reserve currency, he will be using it to buy goods, as it will never truly be "sell-able"
Z
02:36
Zack
In reply to this message
probably indefinitely.

Even if all my other investments disappeared, it wouldn't be hard for me to find a 3-hour per week job to cover my expenses.
I live a simple lifestyle, and my skills are fairly valuable.
Lots of people running startups have day jobs.
02:36
In reply to this message
right
CD
02:48
Crypt Dweller
That's great to hear
02:48
I was just wondering the exact same thing after reading Ross Ulbricht's latest post
Z
07:23
Zack
https://slatestarcodex.com/2014/04/28/the-control-group-is-out-of-control/
Interesting article on the failures of science.
We can mine some good arguments for futarchy from this.
C
12:14
Craig
Zack, you are content with a simple life working on your project.

But you imagine being a trillionaire one day.

How do you imagine your lifestyle when you are ultra rich? What will your projects be at that point?
Deleted invited Deleted Account
12:21
Deleted Account
hi
12:21
project still alive?
JS
12:38
Jon Snow
In reply to this message
As long as Zack is still alive
12:41
Deleted Account
why not active?
JS
12:43
Jon Snow
In reply to this message
It’s never active
12:43
Deleted Account
so its like dead
Z
12:55
Zack
In reply to this message
I would probably keep working on Amoveo.
Maybe I would specialize in some use-case of Amoveo.
TG
14:32
Toby Ganger
At some point Zack will realize that marketing is part of development when it comes to a network based technology or it will continue to descend into obscurity.
J
15:01
Josh
Zack isn't stopping anyone from doing whatever marketing they want to.
S
16:10
Sy
Still too many hardforks for marketing, you guys are so impatient...
16:10
What do you want to market? The user friendly UI?
16:11
Someone just halved veo...wow
M
16:16
Minieep21
books are completely empty
I
16:18
Instinct
In reply to this message
😂
16:32
Deleted Account
any exchanges list this yet?
16:32
hitbtc doesnt count
S
16:37
Sy
Qtrade, vinex
16:37
And afaik hitbtc does actually work
16:42
Deleted Account
u can withdraw?
16:43
ill check those others
16:43
ty
J
17:13
Josh
has there been any discussion of trading on amoveo itself? if we could do a wrapped version of btc we wouldn't need a centralized exchange.
Z
20:16
Zack
In reply to this message
the p2p derivative tool works well.
The issue is more that it is hard to measure the current price of Veo.
So a BTC contract that is priced in Veo wont be very precise.

It is kind of a chicken and egg problem though.
If BTC stablecoins were more popular, that would also create a more reliable price signal of VEO.
C
20:29
Craig
As a trillionaire you would be the most powerful person on Earth, no?

You could use that wealth to make some big changes. Either as a futarchy whale or by spending money conventionally.
Z
20:33
Zack
There will probably be more trillionaires by then.
20:33
How else am I going to buy one of those platinum coins?
20:36
I think for me, it is more about the journey than the destination. It's not that I want to be rich. I just want to use my life to accomplish something really difficult.
20:37
hahaha
20:39
0.00001 VEO.
C
20:40
Craig
Just funny to hear someone be like

"I don't care about money! That said, I expect to be a trillionaire in ten or twenty years"
20:41
I know that not the most accurate paraphrase!
Z
20:41
Zack
well, I think my odds of success are not very good.
C
20:41
Craig
Yeah, expect is a strong word
J
20:47
Jake
Hey guys, I just stumbled across this project yesterday. Currently doing a small scale deep dive at the moment and so far I am super interested to see this project develop!
J
21:25
Josh
In reply to this message
What if we assume there is no other market setting the VEO price and this BTC to VEO market is where the price discovery happens. I remember reading about ways of doing markets where you want good price discovery with limited liquidity but I forget where.
Z
21:26
Zack
In reply to this message
that can work as long as there is a constant stream of people making new contracts like this.
New contracts determine the price at which old contracts get settled.
21:27
For the price of VEO to stabilize, we need some kind of consistent users.
21:27
or a confident market maker who is willing to buy/sell near some consistent price
J
21:31
Josh
Hmm, I think what I remember reading was about Uniswap.
Z
21:34
Zack
In reply to this message
maybe we don't need the extra phase at the end.
If we have the rule that each pubkey can only make a single claim of winning, then it isn't possible to spam the blockchain with tons of claims.
21:40
"This AMM has a particularly desirable feature where it can always provide liquidity, no matter how large the order size nor how tiny the liquidity pool. The trick is to asymptotically increase the price of the coin as the desired quantity increases."
Z
21:44
Zack
Having an on-chain market is a bad strategy. Miners can front-run.
It is really weird to use a blockchain if you aren't even going to make it secure. Blockchain technology is so expensive.
If people want to trade in a market that depends on trust, they might as well use a centralized one.
21:46
on-chain market's price can be manipulated by miners as well. So we can't use them as a reliable price signal.

You can use blockchain tech to enforce the security of a market without putting that market on-chain. Then it is actually trust-free.
s
21:47
sanket
how do you track on chain market price? I mean doesn't there need to be an oracle to track it, and for that there needs to be a price discovery
Z
21:48
Zack
In reply to this message
I don't understand what you are asking.

oracles don't "track" anything. an oracle is for bringing some publicly available data on-chain.

Also, I don't know what "on chain market price" means.
J
21:49
Josh
In reply to this message
I was referring to the market making mechanisms of Uniswap that seem to be good when you have low liquidity, not the fact that's on-chain.
21:51
btw, i'm going over the amoveo code; so much more fun to read Erlang than Bitcoin C++ stuff. and it builds really quick.
Z
21:51
Zack
In reply to this message
A typical tool for trying to get a price from a low volume market is the LMSR logarithmic market scoring rule.
21:52
invented by the same guy who invented futarchy
21:53
In reply to this message
great. feel free to ask questions if anything is confusing.
s
21:55
sanket
In reply to this message
Oh sorry. I got confused with multiple topics. All's fine now
J
21:59
Josh
In reply to this message
Nice, looks interesting.
22:05
Deleted Account
In reply to this message
How much amoveo have in your wallet ?
60/70% of Total supply?
Z
22:05
Zack
In reply to this message
I implemented LMSR in the first version of Augur.
but "lmsr" doesn't come up in their white paper, and I am not seeing anything recent about it on their forums.

I think the gas costs for market makers on ethereum was too high. so they went with a normal order book. Here is a thread on reddit about this https://www.reddit.com/r/Augur/comments/92p2sp/creating_liquidity/
S
22:06
Sy
In reply to this message
16.666% plus some change
Z
22:06
Zack
In reply to this message
about 16.7%
22:06
Deleted Account
In reply to this message
Not a lot, i think more
S
22:07
Sy
An account balance doesn't really care about what you think...welcome to Blockchain
22:08
Deleted Account
In reply to this message
When you convert in real fiat and became a milionar, It Is important.
S
22:09
Sy
Makes as much sense as the last statement...
22:09
So 16.6% in veo is less than in fiat?
22:12
Deleted Account
In reply to this message
I thought that Zack had 60/70% of Total supply.
With this volume and without a good exchange he cant sell or convert the amoveo in real fiat.
So the fact that he Is milionar, Is relative.
J
22:13
Josh
Z
22:13
Zack
is a milionar someone who has 1 milibit, or someone who can buy a lion?
F
22:15
Fića
In reply to this message
Lul
22:16
Deleted Account
In reply to this message
In the past i had some shitcoins that incresed X100 with a single pump....i could convert but the support of exchange said me that there aren't volume.
So i had 20.000€ virtual without a real meaning 😅
F
22:17
Fića
Yes that is how markets work
22:17
Deleted Account
The same is your situation
F
22:18
Fića
Well i think Zack can buy at least 1 lion with his Veo (fortune)
22:18
Deleted Account
In reply to this message
Yes, if the seller want Veo
ŽM
22:19
Živojin Mirić
I think VEO is Best coin
F
22:19
Fića
In reply to this message
Im pretty sure we can find someone here that has a lion and is willing to accept VEO for it
ŽM
22:20
Živojin Mirić
In reply to this message
I will ask friend
F
22:20
Fića
In reply to this message
Thx, lets get him that lion!
Z
22:20
Zack
In reply to this message
uniswap is such a terrible design.
on-chain, so it is vulnerable to front-running from miners.
It only allows for markets between 2 sub-currencies, so it can only work for blockchains that use multiple subcurrencies, which is a broken design.
Much better to have a single currency, and use it to trade risk in whatever people care about.

If you break a currency up into smaller non-fungible subcurrencies, they are all more volatile than if you used a single currency.

And ultimately, there is very little market demand for hedging risk in various subcurrencies.
What people really want is to hedge risks for things like oil or cotton or orange juice. The kinds of risks that come up when they are trying to run a business that serves real customers.
22:20
Deleted Account
In reply to this message
Search in Emirati, probably there Is a crazy
22:22
We are rich when our crypto have a lot of volume.
For example: if i have 100k on eth i could sell in any time.
If i have 100k in shitMako and the volume Is 500€ i have 0 € in real
F
22:23
Fića
Its not exactly 0, its more like 100-250ish
Z
22:23
Zack
In reply to this message
furthermore, having on-chain subcurrencies forces you to go with a design that has on-chain mutible state. to store the account info about the subcurrencies.
Which prevents scalability.
s
22:26
sanket
In reply to this message
Have you seen synthetix.io ?
They create synthetic assets, whose prices are tracked via chain-link oracle and allow people to trade between any asset
s
22:29
sanket
Its so fascinating when you are reviewed all this new things that are being developed.
22:29
How often do you update the docs for these reviews?
Z
22:30
Zack
In reply to this message
if someone complains that it has a mistake because it is out of date, I update it.
22:31
In reply to this message
sometimes other projects have good ideas. I want to use all the best tech for Amoveo, so I need to be aware of what is available.
s
22:31
sanket
"ynthetix currently has a market cap 200x smaller than Eth, so the interest rate you need to pay someone to lock up SNX is approximately Sqrt(200) = 14.4x higher than you would need to pay someone to lock up the same value of Eth."

How did srqt(200) came up?
Z
22:31
Zack
interest rate is related to volatility.
volatility is related to the sqrt(market cap).
s
22:31
sanket
Also, I think they use chainlink now for almost every asset - https://feeds.chain.link/
Maybe you can update the "Oracle" section of the doc.
s
22:32
sanket
Yeah. that I have read.
J
22:36
Josh
In reply to this message
Sure but do you have a critique of their Constant Product Market Maker? That's the part I'm interested in.
Z
22:44
Zack
In reply to this message
for what situation?
are you thinking of using this as a trading strategy on qtrade or some exchange?
22:58
@jmharvey

lets plug into some examples.
If the market has 100-A coins, and 100 B coins.
I want to buy 20 B coins.
(100 - 20) * (100 + Cost) = 100 * 100
100 + Cost = 10000/80
Cost = 125 - 100
Cost = 25

So I would pay 25 A coins to buy 20 B coins.

Uniswap has no order book. So lets say I wanted to buy 1000 B coins, and I was willing to pay 5 A coins to get 4 B coins.

I would have to make an on-chain tx to buy 20 B coins.
Then wait for someone else to make the opposite trade so the price goes back.
Then I make an on-chain tx to buy 20 more B coins.
Then I wait for someone to make the opposite trade.

And this cycle would continue until each of use has done 50 on-chain txs.

So in this example, assuming I am willing to pay 20% above market price to buy B coins, it only takes 50 on-chain txs to make the purchase.

Now lets consider the case where I am not willing to over pay by such a large amount.
if I buy only 10 B coins per round.

(100 - 10)*(100 + cost) = 10000/
cost = (1000/9)-100
cost = 11.1

So in this case I am only over-paying by 11%. And it would take 100 on-chain txs to make the complete purchase.

In practice, traders are usually unwilling to pay even 1% fee.

So lets try to get a generalized formula out of this.
If the on-chain locked up liquidity is L.
And I am willing to over-pay by P.
and I want to buy B many coins.
the number of on-chain txs is T.

L*P ~= amount purchased per tx.
T = B/(amount purchased per tx)
T = B/(L*P)

So if you want to buy $10 000 of something in 1 tx, and you are only willing to over-pay by 1%, then uniswap would need around $1 000 000 locked up.

Having lots of money locked up in the contract is expensive by the interest rate. Especially since uniswap is using low market cap subcurrencies.
ŽM
22:59
Živojin Mirić
In reply to this message
you have read but did you truly understood?
Z
23:00
Zack
In reply to this message
Uniswap's constant product market design either has massive lockup costs, which makes it expensive by the interest rate.
or it has prohibitively high trading fees.
23:01
The only known way to have secure markets is with single price batches https://youtu.be/mAtD0ba-hXU
J
23:02
Josh
I used it at a point where it was cheaper than most centralized exchanges for MKR/ETH for fairly large txs. It's possible that was subsidised by liquidity providers.
23:02
My thought was to use it for an off-chain decentralized exchange. In that case trading fees would be low.
23:03
"transform your VEO into stable BTC on Amoveo." -- is there a doc on this?
J
23:04
Josh
thanks!
Z
23:04
Zack
In reply to this message
the trick is to split up the exchange into 2 smaller steps that are possible.
We will eventually be able to trade VEO for BTC stablecoin contracts on Amoveo using single price batches.
Then you can atomic swap the BTC stablecoin for BTC on Bitcoin, because they maintain the same price there is no issues of front-running or arbitrage or anything like that.
J
23:10
Josh
ok, so this stable coin relies on a price oracle; but what if we don't have an external price feed and we want to determine the price based on the preferences of the actors in this stable coin market?
Z
23:11
Zack
In reply to this message
if there is no price to be stable against, then you can't make a stablecoin.
J
23:12
Josh
there's always a price I'm just trying to figure out how to discover it
23:12
I suppose people would be betting on the oracle
Z
23:13
Zack
if the amoveo oracle is working correctly, a single person reports the correct outcome, and no one makes any bets in the on-chain oracle.
23:18
If there was more trading in Amoveo, then someone with skills as a market maker would start market making.
They would notice people buying VEO at too high a price, and selling at too low a price.
They would make trades more in the middle to profit by arbitrage across time. this would lower the volatility overall.
23:18
There are a lot of open orders on qtrade already. There are people acting as market makers now
23:19
but the demand for market makers is low right now, so the spread is wide.
23:19
as demand for trading increases, profit for market makers will increase, and they will undercut each other's prices, and the BTC-VEO price spread will shrink.
23:42
Deleted Account
I see now....volume in 24h....24€ lol
"good" Is the exchange hitbtc
I have bought Callisto, another shitcoin, on that exchange
23:44
Probably if i put a order on 5/6€ It Will be completed
Z
23:47
Zack
hitbtc has done a bad job for us.
qtrade has done the best job.
23:48
Deleted Account
In reply to this message
Why? They want money/btc?
I know that binance want a lot of money for a listening for example
Z
23:49
Zack
Hitbtc often prevents withdraws.
23:49
If you send them money, you might not get it back.
23:51
Deleted Account
In reply to this message
Wow i dont know, and i bought in the past some shit and transfered to coinomi
13 April 2020
J
00:45
Josh
With all these trustless centralized market makers, is there a risk that the popular ones will become targets of governments and get regulated?
Z
01:06
Zack
In reply to this message
with trusted markets, it takes a lot of time to build up reputation. People don't want to use a new market, they want to use a popular one.
With trustless markets, there is no risk. Even if you are the first person trading.
01:08
In reply to this message
the other day you asked about when we would use the different kinds of smart contracts in sortition chains.
Something I should have mentioned:
sortition contracts are expensive to prove on-chain. because the entire smart contract needs to be posted on-chain.
This means if you want to own some value, you need to remember all of the smart contracts for the entire history of that part of the value in the sortition chain.

we can use waivers to simplify this history.
So, if I had a long contract, and some data became available so that the contract says I no longer own this value.
I could sign a waiver agreeing that I no longer own this value.
If I give you this waiver, then you don't need to maintain a copy of the smart contract. All you need is the tiny signed waiver.
J
01:12
Josh
What's my incentive to sign the waiver? I guess you could pay me a fee for that.
01:12
Or rather I give you a fee to sign the waiver.
Z
01:13
Zack
In reply to this message
paying a fee is possible.
Also, if I am spending value to someone, I want the entire value to arrive.
If I send you $1, but you need to pay $0.10 to claim it, it is kind of like I only sent you $0.90
01:15
and if I am doing a swap of different contracts with someone, we both end up holding value that used to be the other person's. So we both want the data we need to remember to claim our proofs to be small.
J
01:15
Josh
Does the sortition chain operator have to sign the waiver?
Z
01:15
Zack
no
J
01:16
Josh
In reply to this message
True. Also it could be built into the wallets and it wouldn't be worth it for people to change that.
Z
01:16
Zack
but you do want to send the signed waiver to the operators right away.
That way the operators know that you are the new owner of the value
01:16
In reply to this message
yes, it could be automated
J
01:16
Josh
Ok, so it's an instant money transfer.
Z
01:17
Zack
if you are first in line, you can sign a waiver to instantly step out of line. and whoever was 2nd in line becomes 1st.
J
01:17
Josh
Is that how you'd do point of sale, or would you use LN style channels?
Z
01:18
Zack
I am guessing that people will use stablecoin denominated channels to do instant micropayments to buy coffee
J
01:18
Josh
Who would the channel be with? Just a hub?
Z
01:18
Zack
but it might be a lightning network - probabilistic payment hybrid system
01:19
like, maybe everyone has a channel with a hub, and the hubs do probabilistic payments between each other to maintain balance
J
01:19
Josh
Yeah.
Z
01:19
Zack
sortitoin chains could support trillions of channels. maybe it is easier to just make a channel with whoever you are purchasing from
s
01:20
sanket
In reply to this message
has this been tried?
J
01:20
Josh
But if I'm going to a restaurant on a trip, I'm not going to have a channel with them.
Z
01:21
Zack
In reply to this message
if it is the kind of restaurant where you pay at the end of the meal, you should be able to make a channel while eating
J
01:22
Josh
Hmm, that might even work for a quick coffee. Your phone automatically opens a channel when you walk in.
01:22
By the time you have to pay it might be ready.
Z
01:23
Zack
it might not involve a channel.
I tell the operators to make the restaurant 2nd in line for some of my value, locked to a contract that needs my signature.
Then at the end of the meal we calculate the total, and I sign over the amount that I want sent.
01:24
and they sign a waiver giving up control of any excess that I don't want to give to them
J
01:25
Josh
So you'd be in 1st place, they go to 2nd place, then you go to 3rd place?
Z
01:25
Zack
yeah. maybe channels are simpler actually
J
01:26
Josh
Well if you have a few small waivers ready to go, you can instantly give the coins to anyone and you won't need change.
Z
01:26
Zack
if they refuse to give up their spot as 2nd in line, then your money can get stuck so that they are the only people you can send to
01:27
you can still do the final-spend tx, so you don't have lottery risk. but your money is trapped for the rest of the sortition chain's life.
J
01:27
Josh
Yeah you can still send it just not via waivers
Z
01:28
Zack
you cant send it with a sortition contract either.
if you ask the validators to put someone new in line, they will be in the third spot in line.
J
01:28
Josh
Can't they be conditionally 2nd in line based on knowing a secret?
Z
01:29
Zack
if they don't know the secret, and I want to send the value to someone else. it is not possible to prove that someone doesn't know a secret.
J
01:30
Josh
It's possible to prove that they do know a secret, and they'd only be 2nd in line if they prove they know it
Z
01:31
Zack
or you can do it so they only own the value if the secret is unknown. So I can prove that they don't own the value by revealing the secret.
01:32
by putting a smart contract inside the waiver
J
01:32
Josh
Can't you cheat them in that case?
Z
01:33
Zack
another thing we can do is commit a secret into a root-hash on-chain.
So now you can prove that a secret existed at a certain moment in time.
We can have smart contracts that require you to prove that a secret had existed before a certain block height.
01:34
and we can set it up so you only need to commit a secret on-chain if they refuse to cooperate with updating normally.
like how channels work.
01:36
In reply to this message
it's impossible to reveal a secret that you don't know.
J
01:38
Josh
Oh I was thinking I'd know the secret and give it to them to pay for the coffee.
Z
01:39
Zack
that tool probably doesn't make sense for the coffee example. I am trying to give you an idea of the space of possibilities.
J
01:39
Josh
They'd sign up for 2nd place based on the hash of my secret, and they'd only give me the coffee if I give them the secret
Z
01:41
Zack
so, they can use the secret to validate a waiver that gives up my first spot in line? is that what you mean?
01:42
so then, if I choose to not buy the coffee, I would need some way to show that they don't know the secret.

So they would have needed to sign a waiver that gives up their second spot in line, if the secret is not recorded on-chain before a certain height.
J
01:42
Josh
No it activates their 2nd spot. I give them 2 things, a waiver of my 1st spot and the secret to active their 2nd spot
Z
01:42
Zack
and they might need to be 3rd in line too. That way we can simplify it, so they don't have to actually put the secret on-chain, as long as we cooperate
01:43
it is possible to do anything, but it can get complicated with all the waiver and counter-waivers and smart contracts referencing each other
01:44
but this strategy is good, because there is no shared mutable state. so it can be scalable.
J
01:44
Josh
There are no counter waivers in this example but looks like there would need to be more smart contract logic than there is now
Z
01:44
Zack
so many parts are turing complete. there are probably lots of ways to do the same thing.
J
01:44
Josh
But maybe it can be done with scriptless script type sigs
01:47
I think point of sale is pretty important for adoption so I'm interested in what the best approach would be.
01:48
Payment hubs might not be too bad.
Z
01:48
Zack
Yes.
I have a bunch of tests cases for sortition chains.
I'll make one, or a few, for point of sale specific cases.
J
01:48
Josh
Cool
Z
01:49
Zack
I suspect that there won't be a one size fits all solution. That different people will want to do it differently.
J
01:49
Josh
Yeah for sure
01:49
I'm in the Bitcoin ATM business and different operators do it differently.
01:50
Depends on a lot of factors
Z
01:50
Zack
Cool. Good to know
J
04:30
Josh
Zack, I don't know if this has been described before but instead of paying $6.50 for coffee I can hand out a $100 coin with a 6.5% chance of winning. As long as I give out enough $100 coins over the course of a month, it'll even out. The merchants will have even less of an issue with it. I can do the same thing for small txs at exchanges.
04:42
Hmm, this might be exactly sortition chains but it's kind of a different way of using it I think.
Z
04:54
Zack
In reply to this message
Yes. This is what I meant when I said "probabilistic payment" .

Delayed probabilistic payments is how sortition chains get their scalability. And we can put a instant version inside sortition chains.

I suspect that consumers won't use the instant prob payments directly.
Instead they will have channels with hubs, and the hubs have prob payments between each other.
J
04:57
Josh
In reply to this message
I was thinking about this in response to your comment. I think with this kind of probabilistic payment they wouldn't have to give me change.
04:58
Hubs could work but if we can avoid them with waivers that might be even better.
Z
04:59
Zack
putting them next in line is very similar to creating a channel.
04:59
the money gets locked up. only one person can be 2nd in line at a time
04:59
and waivers are only used to step out of line.
J
05:00
Josh
Does getting in line require an on-chain tx?
Z
05:00
Zack
its a kind of one-way channel
05:00
it requires the validators to sign a root containing the tx, and for that root to go on-chain
05:01
could be one root for millions of sortition chains
J
05:01
Josh
well if i set up a direct payment channel with a restaurant, doesn't that require an on-chain tx just for that?
Z
05:01
Zack
the channel is inside of the sortition chain.
05:02
if the channel wins the lottery, it gets create on-chain containing all the money from the lottery winnings.
05:02
and then it can be settled like a normal channel. any contracts we have made are valid
05:02
any channel contracts
05:03
so they are turing complete state channels mostly compatible with the current channel system
J
05:03
Josh
so when i set up the channel, the validators have to sign the root of the change to the sortition chain?
Z
05:03
Zack
yes.
J
05:03
Josh
ah ok, so yeah very similar
Z
05:04
Zack
thats how you put the channel next in line to own some of the value
05:04
in the bitcoin community, they call this kind of design a "probabilistic channel factory"
J
05:04
Josh
i see so that's way more flexible
05:05
the part i was missing was that even this new channel is really cheap because it's part of a big tree with tons of other updates
Z
05:05
Zack
right. maybe I should make that more clear in the docs
J
05:05
Josh
does this kind of update take longer than a regular tx?
Z
05:06
Zack
it depends how often that pool of validators publishes root.
05:06
if they publish less often, they pay fewer fees
05:07
they could publish every block. at first they will because our blocks are empty now.
05:07
but someday, if there was many different teams of validators, it will make sense for some of them to only publish a root like, once a day, or less often.
05:09
I set it up so a single root published on-chain can put up to 256 more people in line for any part of the probabilistic value space.
J
05:12
Josh
Once they publish the root, are there any other delays or do we just wait for enough blocks for good confirmation?
05:13
Actually, even if they don't publish right away, the sig might be enough for starbucks to trust the payment since I can't double spend them anymore.
Z
05:16
Zack
Adding people to line like this, it is only using immutable state. people keep getting added to the line, and we record a bunch of waivers for people in line who don't count.
So the validators, they are only adding new info to the tree. never removing or changing.

So I am thinking, the validators can sign the current progress of their merkle tree that they are updating for the next block.

And if anyone can show that one of these updates contains info that was not committed to in the on-chain sortition commitment, then that sortition chain is frozen. they can't make any more on-chain commitments. everyone needs to wait for the final-spend period to have a chance to get their money out.

So we can use fraud proofs to enforce off-chain progress in the sortition chain, and make it able to update instantaneously.
It has the drawback that retirement attacks are possible. the validators could undo one on-chain commitment period.
05:24
idk, it has a lot of complications.
Like, what if the validators suddenly make a bunch of commitments in a row, so there isn't time for someone to notice that their data wasn't included
05:25
so, would we need to undo many commitments instead of just one?
it seems like the period of time they could undo would be large
05:26
or maybe whenever the proof of cheating is shown, we just pause right there.
05:27
if we could update them instantly, that would really be an awesome feature
J
05:27
Josh
Yeah sounds like there are some timing attacks. I was just saying that once the validators sign the root, the possibility of me double spending the merchant goes away and now they just have to worry about the validators all double spending this $6.50.
05:27
It's a different risk profile.
Z
05:27
Zack
oh yeah, that is true as well
J
05:28
Josh
it could be worse than that though because starbucks could get thousands of small payments that are all in the same sortition chain and they could lose them all
05:28
but they would have more reason to think that wouldn't happen
Z
05:29
Zack
all the hackers stealing coffee simultaneously across the globe
J
05:29
Josh
but they'd need to bribe the validators
Z
05:30
Zack
if the validators don't have any consequence for lying about these things, i don't think we can trust them at all
05:31
someone could bribe them $0.01 to sign something
J
05:31
Josh
they have a consequence to their future business
Z
05:31
Zack
if the sortition chain gets shut down, then no one will want to use those validators again.
If the validators sign something, it doesn't matter to most people
05:32
or at least, the cost is hard to model
J
05:32
Josh
they make money by opening more and more chains, so being a cheater would be very costly to them
Z
05:34
Zack
if one person's contract doesn't get included, but the validators spend some of their profits on propaganda.
J
05:34
Josh
but that person can prove that they cheated
05:35
he has the signed root
Z
05:35
Zack
they have a signature from the validators saying that they agreed to include a tx in a block yes. but I feel like most people wouldn't understand or care very much.
And they are susceptible to propaganda.
J
05:36
Josh
sure but i can imagine certification organizations like UL
05:36
they will put out reports on the best validators
05:36
flag bad ones
05:37
starbucks certainly wouldn't want to deal with bad validators
05:37
or any merchant
05:37
in fact, wallets could download fraud proofs
Z
05:38
Zack
In reply to this message
thats an interesting idea.
J
05:38
Josh
there wouldn't be any to download because it would be a death sentence to validators
Z
05:39
Zack
In reply to this message
game theoretically speaking, a mixed solution that takes advantage of retirement attacks is more likely
05:40
people build up reputation, and then use it to take as much profit as they can
05:40
unless the tx fees are high enough to convince them not to
05:40
but then it would be expensive from tx fees.
05:40
maybe the extra cost is worth it for the speed
J
05:41
Josh
why retire if you're making a good profit?
05:41
all N validators have to retire at the same time
05:41
but yeah that could happen
05:42
how about a security deposit that gets slashed if there's a fraud proof?
05:42
if they're in it for the long haul that shouldn't be too costly
05:43
but i guess it would reduce competition
Z
05:44
Zack
In reply to this message
I want to be able to put the sortition chains inside each other recursively
J
05:44
Josh
In reply to this message
Maybe a two phase commit would help here
05:45
they commit the final root to the block chain, then everybody has a period of time to present fraud proofs before it's finalized.
Z
05:47
Zack
so, would the validators only put a single merkle root on-chain, per sortition chain? haha
J
05:48
Josh
yeah, why not?
Z
05:49
Zack
you have some great ideas. it is making me wonder if I built sortition chains wrong.
J
05:51
Josh
I'd bet on me missing some details, I don't have a great grasp of this yet
Z
06:03
Zack
I think we can't do too much time without committing on-chain, because the validators could be writing 2 versions of history at that time.
And the blockchain has no way to know which version of history was available first.
06:04
so I think it is always possible for the validators to undo whatever promises they had made since the most recent on-chain commitment
J
06:08
Josh
every time they sign a root, it could also reference the chain of previous signed roots
Z
06:08
Zack
that doesn't stop them from building 2 chains
06:09
In reply to this message
this is the same trick we are doing to say it is secure against being forced to take lottery risk
06:10
in the case of lottery risk, they can't actually steal any money. it is not profitable.
in the case of undoing some history, it could be a profitable attack. it could enable a double-spend. So I am not sure if we can use the same trick.
06:10
it is a good idea. maybe it could work. I will think about it more.
J
06:14
Josh
thanks. i still feel like there's a way to do the fraud proof. aren't these just updates to a particular sortition chain? the chain could be anchored by the previous on-chain committed update. how would they build 2 chains?
06:58
Deleted Account
im intrigued by the claim that option trading is possible on amoveo
06:58
i saw it referenced in the github
06:58
lhas this been done yet?
Z
06:59
Zack
with this tech, forwards contracts usually make more sense. but any kind of derivative can be used more or less the same as the rest
07:00
Deleted Account
thats awesome - im gonna keep reading
07:01
07:01
this word was new to me
Z
07:01
Zack
right. and we only have cash-settled contracts. you can't put physical assets directly on the blockchain.
07:02
forwards contracts are symmetric, so it works well with P2P
07:02
options are popular because only one side of the trade needs to be trusted.
So you can have one big trusted institution with many small untrusted customers.
07:02
with blockchains, no one ever needs to be trusted. we have escaped this limitation
07:03
Deleted Account
so hypothetically on amoveo you can have collateralized crypto for a deal that gets released depending on the conditions or parameters of the contract?
Z
07:04
Zack
yes, that is a basic explanation of state channels
07:04
Deleted Account
"state channels" - another new phrase to me, ty
07:06
what draws me to amoveo is the rawness of the code & project - its reminicent of early btc days when all there was to use is github and basic experimental php sites on IP addresses w no domains

gonna keep readin on how2money
07:06
cuz seems legit
J
07:07
Josh
In reply to this message
Yeah, I get the same feeling
07:09
It's the feeling that there's the potential for a massive things to be built on this but nobody sees much yet.
Z
07:10
Zack
that is the trick to being a good investor.
Finding something that is under-valued.
J
07:10
Josh
Right.
07:11
In reply to this message
Getting back to this, am I missing something about anchoring the chain?
07:11
I didn't understand what you meant about operators creating multiple chains.
Z
07:12
Zack
whatever rules we have to for fraud proofs to prevent double-spends, they could just follow all the rules seperatly, on 2 different versions of history.
We can't know which one was available first, unless it's hash was put into an earlier block.
07:13
so maybe one was available first, and you received a payment based on the first one.
But at the last minute they release an alternative version where you didn't get paid.
07:13
so this means that any updates made during the period of time between 2 on-chain commitments might be undone.
J
07:14
Josh
I have a path pointing back to the last block and the path is signed by them. If they publish a different path back to the last block they are committing fraud.
Z
07:15
Zack
right. and so some history gets undon
07:15
undone*
07:15
we can't know which version of the history is better, so we can't do either of them
07:16
this enables double-spends. so it is a profitable attack. so the attack coordinator can pay bribes to the validators to overcome the loss of their reputations
07:16
if it is possible to do retirement attacks like this, then the cost of using the service is excessively higher. because we need to pay high enough fees to convince them not to attack us.
J
07:17
Josh
Ah ok, I see the attack, I was focusing on the wrong part.
Z
07:17
Zack
it would be better to use a cheaper version of sortition chains, with payment channels and probabilistic payments between hubs.
This still allows for instant payments, but doesn't enable any retirement atacks.
J
07:24
Josh
So there simplest way that works is I have a channel with my hub and the coffee shop has a channel with their hub and the two hubs have channels between them.
Z
07:24
Zack
yes
07:25
actually, I think we can't put instant probabilistic payments inside the sortition chain with the current design.
How are you supposed to make an arbitrary person next in line for your value?
J
07:27
Josh
Which payments have to be probabilistic?
Z
07:27
Zack
it would have been nice to connect the hubs together with probabilistic payments, but it isn't necessary
07:28
we can keep making lots of channels between them
J
07:28
Josh
What's wrong with one big channel?
Z
07:28
Zack
like, with more than 2 people?
J
07:29
Josh
I mean the channel between the big hubs
Z
07:30
Zack
if there are N other hubs to make channels with, that is like N^2 / 2 channels.
J
07:32
Josh
Eventually they might need extra hops
Z
07:33
Zack
right, and extra hop means less channels.
but they can get unbalanced even more easily
J
07:34
Josh
And it's even more centralization
07:36
I gotta get some sleep, thanks for going through all this with me.
07:36
Exciting stuff
Z
07:36
Zack
im glad to have your questions. it is very helpful
J
07:37
Josh
Thanks, good to hear :)
07:49
Deleted Account
Why is amoveo only listed on hitbtc
07:49
Would be nice to buy it elsewhere
Z
07:49
Zack
it is on qtrade.io
07:49
don't use hitbtc
07:49
Deleted Account
Cool, thanks
07:50
Any plans on getting it elsewhere?
07:50
huobi/binance, etc
Z
07:50
Zack
no plans
07:50
Deleted Account
gotcha
07:51
The spread on qtrade is huge
Z
07:52
Zack
yes. there isn't much trading now.
Z
13:22
Zack
It would be really nice if we could get the faster probabilistic payments into the sortition chain.
If anyone has any ideas.
J
17:33
Josh
In reply to this message
I didn't quite understand why the recursive sortition chains kill this idea.
17:40
In reply to this message
What do you mean by lots of channels between hubs? Won't you still need O(n^2) channels?
17:44
In reply to this message
why do you need to make an arbitrary person next in line?
17:49
In practice, I think really instant payments with new accounts you haven't seen before are less important than the cost of transactions. If transactions are really cheap, you can set up lots of optimistic channels and waivers with any potential merchant. If you don't use it it doesn't matter because it's almost free.
17:51
In many situations where you're dealing with a new counterparty and you need fast transactions, the other side of the transaction isn't necessarily instant either. Adjusting block times to be quicker (1 minute instead of 10 minutes) could make this a non-issue for most in-person transactions.
J
18:12
Josh
"If this attack does occur, it is not profitable for the attacker, and we know who did it, it was the validators." -- why can't this be profitable for the attacker? Can't he blackmail me into paying me some of the value I'm going to lose?
18:15
Cant this be addressed by having a challenge-response period during finalization where people can make them prove they have any piece of data?
Z
21:23
Zack
In reply to this message
I want to avoid any sortition chain design that has security deposits, because if we have a depth of like 4 generations of sortition chains inside of each other, we would need 4 layers of security deposits.
It prevents the infinite scalability goal, because every layer of sortition chains deeper increases the fraction of the money in the sortition chain that is unusable.

Speed is nice, but having infinite bandwidth for txs is more important.
21:23
In reply to this message
yeah, we could have many small channels, and re-make them at every on-chain sortition commitment.
21:26
In reply to this message
if you want the ability to spend your instant probabilistic payment to anyone.

We want to start in the state where I am the only person in line for some value, and end in the state where you are the only person in line for some value.

the only actions I can take are:
1) instantly step out of line.
2) ask the validators to put someone new in line after me.
21:27
In reply to this message
yes. a faster block time might make sense.
21:32
In reply to this message
so like, if some of the validators decided to halt progress of the sortition chain until someone sent them X amount of money.
We all have the final-spend tx, so we aren't holding lottery risk.
the validator really don't have much to offer to convince us to pay a bribe. our money is just temporarily stuck in one place.

You can have money in many different sortition chains, so not all of your money is necessarily frozen.
21:33
In reply to this message
the validators can just refuse to sign new blocks to stop progress. no challenge response will solve this.
J
21:46
Josh
I'm confused about the missing data attack. Let's say an operator creates a new leaf but doesn't tell anybody about it and then publishes the new root. Now I might not be able to give a merkle proof because I don't have the right hash. Doesn't this mean I can't even transfer my lottery ticket in the final-spend stage?
Z
21:47
Zack
if only one validator signs something, it doesn't matter. all of them need to sign a root for it to get recorded on-chain.
21:47
if all of them work together, they can freeze your money so that even the final-spend doesn't work to unlock your money. you are stuck with lottery risk.
J
21:48
Josh
Yeah let's assume they all sign it.
21:48
Right so they could blackmail me.
21:49
Btw, is this the only reason we need multiple validators?
Z
21:50
Zack
so like, if they make a merkle commitment, but only give out merkle proofs to people who pay a fee.
21:51
In reply to this message
yes
J
21:51
Josh
In reply to this message
Exactly
Z
21:51
Zack
In reply to this message
if they did this, they could keep doing it over and over. If I pay the fee once, they could immediately black mail me again.
J
21:54
Josh
Most practical blackmail schemes have that issue but they still happen.
21:54
They might get a reputation for blackmail honesty
Z
21:54
Zack
If they have any reputation besides a reputation as good sortition validators, they won't be hired to do any more sortition chains.
21:55
If this is their last sortition chain anyway, there is no way to build a reputation as honest blackmailer
J
21:55
Josh
Right so this is already an exit scheme
21:55
Yeah that's true
Z
21:55
Zack
It is a single iteration game. No time to build a reputation as honest blackmailer
J
21:57
Josh
So then why do we need multiple validators if this attack doesn't work? And why should I trust that these validators aren't working together?
Z
21:58
Zack
you can make a sortition chain with 1 validator.
What is nice about multiple is like, if I have a validator that I trust, and you have a validator that you trust, then we can both use any sortition chain that includes both of those validators in the validator set.
21:59
most proof of stake systems requires 2/3rds honesty of validators for security.
sortition chains only need 1 of N to be honest.
J
22:00
Josh
Yep although introducing reputation worries me because that reduces easy competition which makes it more likely that the validators with good reputation can get big and regulated.
Z
22:01
Zack
the validators can't profitably attack you.
So they just need a reputation as someone who doesn't cause meaningless destruction.
22:01
it is different from having reputation as someone who doesn't profitably steal
J
22:02
Josh
It's different but could still lead to big popular validators
22:03
I wonder if there's a way to stop this missing data attack. Then the security level goes up and we don't need multiple validators.
Z
22:04
Zack
In reply to this message
I don't think so.
The cost of launching a new sortition chain is practically zero. People can have their money divided up among many different sortition chains.
J
22:05
Josh
You need capital to start the chain and it has to be enough to make the fees worthwhile, so it depends on what the blockchain fees are.
Z
22:06
Zack
In reply to this message
if there is a way to punish validators for not revealing some data, then that means the validators would need some value locked in the system. and this would make it expensive for us to put sortition chains inside each other recursively.
22:06
In reply to this message
the fee of a single on-chain tx to make a new sortition chain? it is very low.
22:07
making a new sortiton chain inside of an existing one is basically free
J
22:07
Josh
In reply to this message
You might not need to punish them, just not finalize the new commitment that blocks transfers.
22:07
In reply to this message
Ah right, didn't internalize that part. That's cool.
22:09
However if all the big chains get regulated they might censor opening new chains.
22:09
But I guess you'd only need one top chain that's not censoring.
Z
22:11
Zack
In reply to this message
so everyone participating in the sortition chain would need to be online 24/7, watching if the validators don't give them a merkle proof for a new on-chain commitment.
I think it would still necessarily be vulnerable to griefing. because we can't tell the difference between someone unnecessarily asking for the validators to provide data that is already available, vs someone asking for data that the validators have hidden.
22:11
In reply to this message
you can make new sortition chains on the main chain too. a tx fee is very low.
J
22:12
Josh
In reply to this message
Yeah I don't know how it would work but I don't think you'd need to punish the operators. So maybe it's still possible.
Z
22:13
Zack
the existence of griefing attacks makes it prohibitively expensive vs designs that don't have that vulnerability
J
22:14
Josh
In reply to this message
It is now but I'm imagining a world where everyone is using this. Governments could try to attack the chain by bidding up transaction fees.
Z
22:16
Zack
In reply to this message
Since sortition chains scale infinitely, the on-chain capacity is always a couple orders of magnitude bigger than the demand for on-chain space.

So an attacker who wants to buy up all the space would need to pay a couple orders or magnitude more than defenders pay to get their txs included.
J
22:18
Josh
In reply to this message
Yeah, good analysis
Z
22:18
Zack
Like, if the on-chain capacity is 100 txs. And I only need to include 1 tx.
I only pay 1 fee. But the government would need to pay 100 to block me
J
22:19
Josh
In reply to this message
I guess that would get messy.
Z
22:20
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master//basics/trust_theory.md I think I already showed you this? It explains why if the system is vulnerable to attacks, the fees are higher.
J
22:21
Josh
I was just rereading that today
22:22
In reply to this message
Is the point of this so a hub doesn't have to lock up a lot of capital in the n^2 channels?
Z
22:25
Zack
The hubs could be connected by lots of channels. That is an option.
But it would scale much better if we could use prob payments to connect them
22:27
I'm thinking it might be possible to do instant prob payments.
If I have 1 Veo, I could divide it up along contract space.
So we could pre-load 100 different potential accounts that I can send the 1 Veo to, depending on how some contracts resolve.
We set up the contracts so I can sign messages and give it to the potential recipients, and they have a chance that it allows them to unlock the 1 Veo for themselves.
22:29
But maybe it doesn't work. If one recipient thinks he received the value, would he need to gather waivers from all the other potential recipients?
J
22:36
Josh
I didn't understand it in enough detail to comment.
22:38
But my thinking is that payment hubs are good for 2 things: cheap txs and instant txs. We already have cheap txs so we only need them for instant txs. But why do we need instant transactions?
22:39
I'm having trouble thinking of a use case that wouldn't be adequately solved by quick blocks, like 1 minute.
Z
22:40
Zack
if all the sortition chains needed to have an on-chain commitment in every block, it wouldn't scale much
22:40
the blocks would fill up
22:41
channels are a decent solution.
with sortition chains we can create trillions of new channels all at once.
But we would have some liquidity issues for how much money can move around during the time period between 2 on-chain merkle commitments
22:43
money that is locked in one channel cannot simultaneously be locked in another
J
22:46
Josh
In reply to this message
Right this would require on-chain updates every block. But not all sortition chains would have to update every block, there would be special fast ones that give you fast txs for a premium fee.
22:46
Hubs also have costs from the capital lockup requirements.
Z
22:49
Zack
In reply to this message
it is an application of sortition chains that doesn't scale infinitely.
So eventually, it is features that aren't available to the majority of users.
22:52
well, Amoveo is really a platform for massively scalable financial derivatives.

Having massively scalable instant payments is an interesting problem, it is also important for humanity. But it outside the scope of this project.
22:53
maybe for the case of quick payments it is acceptable to have lots of little blockchains instead of one giant one.
fungibility is less of an issue if you are only holding the money for a short time to make some payments.
Like how casinos have chips.
You buy some local currency for fast spending based on where you are located.
J
23:10
Josh
If Amoveo is successful it should be easier to trade those fast tokens for more secure tokens.
Z
23:14
Zack
Yes. Atomic swapping for derivatives on amoveo.
Amoveo could be a glue between all the smaller faster local currencies.
J
23:15
Josh
Yeah that makes sense. You might see a store that accepts a few different fast little currencies. The stores near each other would tend to accept the same ones since that's what the locals would have.
23:16
And these currencies could be fast and cheap because they don't have to scale too big.
23:17
The main problem with this approach is exchanging them so that's why we'd need Amoveo.
23:18
A lot of this is already happening with local fiat currencies.
23:18
You go on a trip and you need to get some local currency. The local distributor needs to get foreign currency to buy stuff from abroad.
Z
23:19
Zack
Paper currency really has a lot of advantages. You don't need Internet.
It can process payments massively parallelized.
23:21
Local businesses in a city could work together to make a currency for that city.
Like Starbucks gift cards
J
23:23
Josh
So why hasn't this happened?
Z
23:24
Zack
Why hasn't what happened?
J
23:26
Josh
Locals making their own currency.
Z
23:27
Zack
We are in an era of explosive experimentation in currency creation. There are thousands of cryptocurrencies.
23:27
This is a place to talk about Amoveo. Not speculate about why more people aren't making currencies.
23:29
almost every country does have a local currency
J
23:40
Josh
In reply to this message
I'd reply but apparently it's off topic now.
MC
23:45
M Chuck
What do I need to change in order for iOS app to show my balance?
23:45
Doesn’t seem to be working since fork
Z
23:58
Zack
In reply to this message
i recommend using the light node that I wrote https://github.com/zack-bitcoin/light-node-amoveo
Here it is in a web page http://159.89.87.58:8080/home.html
23:58
@denis_voskvitsov looks like it still isn't working?
14 April 2020
DV
00:00
Denis Voskvitsov
it was like hour or two today when it might be unavailable from some locations, but now it should work. let me check
00:03
works for me right now
@CQuan12 could you please check it now?
MC
00:59
M Chuck
In reply to this message
Working now! I haven’t checked in like 4 months, crazy coincidence it was during the down time
DV
01:00
Denis Voskvitsov
you're welcome and sorry for the inconvenience. you can ask your questions on our wallets in dedicated group btw: @amoveo_wallet
Z
02:18
Zack
In reply to this message
thinking more about the probabilistic payments idea.
What if we use burn addresses?

Lets say there are N probabilistic payment hubs.
I have some value, and I want all N of these hubs to be next in line to receive my value.
So I make log2(N) pairs of secrets.

For any pair of secrets, if both are revealed and recorded on-chain before a particular height, then the burn address wins the money.

If I reveal 1 secret from each pair, it is like an N-bit binary number. This binary number can point to one of the N hubs. that hub receives the payment.

I think this still doesn't work, because you would need to get waivers from all the hubs who did not receive the payment before it becomes spendable.
02:20
maybe instead of revealing secrets, the payment should be signed by all the hubs.
so when the payment occurs, the rest of the hubs are simultaneously relinquishing ownership.
02:28
How about if I make all N hubs be in line to own my value, one after the other.
If I want to make a payment to hub number M, then I request every other hub besides number M to sign a waiver, until only M is after me in line.
Then I sign a waiver.
Now M owns the value.
02:29
If a hub doesn't cooperate, then we stop interacting with that hub in the future.
The other hubs can't steal your value, they can only cause it to get somewhat frozen.
02:29
if the Nth hub in line refuses to cooperate, then this value can only get spent N-1 more times.
02:30
I think this could actually work.
02:30
A team of hubs is kind of like another kind of side-chain built on top of sortition chains.
A payment hub pool.
02:32
when you sign the waiver to step out of line, the waiver can have a smart contract in it.
So this kind of payment can be part of an atomic swap, or it can be part of a lightning payment.
02:35
the drawback is that if any one hub in the pool gets shut down, a lot of money gets somewhat frozen.
I wonder if we can improve on this further.
02:37
I guess if you are stuck holding a lot of somewhat frozen money, you could atomic swap it with someone to buy completely unfrozen money.
There is probably someone who just wants to hold veo until the sortition chain ends. they could earn a little extra profit to do this.
02:38
so the cost of a hub getting shut down would be minimal.
02:39
@jmharvey I think I found a solution for massively scalable instant payments. better than channels between hubs.
02:44
In reply to this message
oh, this is wrong.
You can't spend it any more times. it is completely frozen.

The block height you were put in line is more important than the priority nonce you were given.
02:45
you would need to wait until the final_spend_tx period, and you could sell it then.
02:46
so if a hub went offline, the failure mode is the same as if one of the sortition validators went offline.
02:46
I still think this might work.
02:55
what gets really complicated, is if one pool of hubs is using a mixture of different sortition chains.
J
04:37
Josh
What's the scenario for this? let's say there's hub A with customer X, and hub B with customer Y; X wants to instantly pay one veo to Y, so X -> A -> B -> Y; X sends 1 veo over the channel to A, B sends 1 veo over the channel to Y and A sends 1 veo to B via probabilistic payment? Can this all be done atomically?
Z
04:38
Zack
yes, all atomically
04:39
the channels contain probabilistic value too. it is all probabilistic value the same way
J
04:39
Josh
So this way the hubs don't need to have channels with all the other hubs
Z
04:40
Zack
if it is just 2 hubs, it is not as interesting.
but A and B could be 2 hubs in a team of 10 other hubs.
If you lock your money into the hub pool once, now you can spend it to anyone else in the hub pool. but you need everyone in the pool to sign a waiver for this to work.
04:41
you can spend it instantly, and have the payment connected to a smart contract to make it atomic with other smart contracts
J
04:42
Josh
Seems like the penalty of getting kicked out of a lucrative pool would outweigh any reason to deny the waiver.
04:43
Plus the payments are probably pretty small, so there are a lot of them.
04:44
Which means the uncooperative hub won't even be doing much damage before it gets kicked
04:44
Payment channels also have these issues.
04:44
This should mean way less locked up capital for the hubs
04:48
Hub A could tell the other pool operators that hub B isn't signing the waiver; the other hubs could send a message to hub B that they're going to kick him out of the pool unless he signs the waiver; after some timeout B could get kicked from the pool.
Z
04:49
Zack
if a hub member stops participating, then the money in the hub is frozen until the sortition chain is ending, and it is the final_spend period
J
04:51
Josh
isn't it just that particular probabilistic payment?
Z
04:52
Zack
every hub member is in line to receive every other hub member's money
04:52
every time any money is moved, they all need to sign waivers
04:54
if hub A wants to send a little value to the 5th hub in line,
Then hub A needs to get hubs 1st-4th in line to all sign waivers.
04:55
that way when hub A signs a waiver, the money goes to the 5th hub, as it is supposed to.
J
04:55
Josh
right but you could randomly shuffle the order, that way one bad hub won't block all the payments
Z
04:56
Zack
I guess 256 priorities per contract wasn't enough
04:56
In reply to this message
yeah. maybe it would be random. or maybe they would list more trusted peers first.
J
04:56
Josh
yeah ones that have been around longer
04:57
but the pool would find out very quickly that a hub isn't cooperating
04:57
in a few seconds
04:57
but i guess there would already be a lot of prepared payments
04:58
yeah could do a lot of damage because the hub would have to wait for new payments to be confirmed
Z
04:58
Zack
they would find out quickly, and then the hub's money is frozen until the sortition chain ends
J
04:58
Josh
yeah i guess about half the money would be frozen
Z
04:59
Zack
so, the names on the priority list, they would be a cycle.

A B C D A B C D
If any one of them refused to sign a waiver, then it freeze the whole thing.
It doesn't matter if a more trusted person is first.
05:00
but this is the same way it works for sortition validators.
J
05:00
Josh
if i want to send to A and D is blocking, why can't I?
05:00
I mean B
Z
05:01
Zack
you can send to A. then A can send to C.
Then lets say C wants to send to A.
D could block this.
05:01
when you step out of line, everyone else in line is still there. unless they sign a waiver
05:02
adding more people to the line means waiting for a merkle root to get recorded on-chain. and for confirmations.
J
05:02
Josh
Ah so you would repeat this cycle a bunch of times?
Z
05:02
Zack
yeah, that way the same money could move around many times
J
05:02
Josh
yeah
05:03
ok so you might be able to do one last payment with it but then it's blocked
05:03
that's a problem, the hub can do a lot of harm
Z
05:03
Zack
yes.
but since the names are cycling in a circle, it doesn't really matter who you start with
05:03
it is the same security model as the sortition validators though
05:04
if any one of the sortition validators stops participating, the money is frozen until the final_spend period
05:04
sortition chains don't have to last that long. we could have them retire after 2 weeks.

But if you want to have a smart contract that lasts a long time, it needs to be inside a sortition chain that lasts at least that long.
05:05
so, if you are betting on election results in 3 months, the sortition chain needs to last at least 3 months
J
05:05
Josh
2 weeks is a long time for a hub pool to be shut down
05:05
but you can straddle the payments so that every day a tranche expires
Z
05:05
Zack
they don't need to put all their money into the hub pool at once. and they can be participating in pools with different people at the same time
05:06
they can make a new hub pool very quickly if they need to. as soon as the next merkle root is recorded on-chain
J
05:07
Josh
how do they send an exact amount with these payments?
Z
05:07
Zack
In reply to this message
I don't understand this
05:08
In reply to this message
when they sign the waiver, they are giving up control only of the fraction of the money that we want to spend.

Lets say the sortition RNG is producing a value between 0 and 1.
Then a hub might control some fractions of this value [[0.34, 0.37],[0.5, 0.6]]
and the waivers might be referencing only this part [[0.34, 0.345]]
which is worth (0.005)*(lottery prize).
05:09
the waiver can have a smart contract, and this smart contract can reference the RNG that is used to settle the sortition chain.
J
05:10
Josh
But those amounts would have to be defined ahead of time, then you'd choose which one you want waivers for?
Z
05:11
Zack
they don't have to be defined ahead of time.
they can make the smart contract in the waivers immediately before signing them
05:11
the sortition chain is like a lottery. it chooses a random number, and that number determines who wins the prize from the lottery
05:11
if you buy 100 lottery tickets, they might have consecutive numbers
05:12
or they might be in a few chunks, and each chunk is consecutive
J
05:12
Josh
In reply to this message
There would be a lot of probabilistic payments and they'd expire at different times. So you'd always have some money freeing up soon if they get frozen.
Z
05:13
Zack
oh right. if each sortition chain lasts 10 days, and we start a new one every 2 days, so they overlap. you can migrate some kinds of contracts from younger to newer sortition chains
J
05:13
Josh
In reply to this message
ah ok, even better
Z
05:16
Zack
If we had a bunch of non-consecutive chunks, and we wanted to simplify our contracts, we could swap equal-value parts with each other to make it simpler.
It would be like defragmenting a PC.
05:22
it would be annoying to own value that had previously been used in a hub.
It would have a massive number of waivers in it's history.
Z
06:56
Zack
I wonder if it is possible to use some kind of ring signature, so that a single small waiver could be used to show that many different pubkeys have all stepped out of line.
Z
10:45
Zack
given a short signature, and a pubkey. can you verify that this pubkey signed, without needing to know any of the other pubkeys that were involved with the signature?
Z
11:49
Zack
http://159.89.87.58:8090/main.html
Here is the website so you can post channel offers and browse through existing valid channel offers.

https://github.com/zack-bitcoin/amoveo you can learn more about amoveo here
Zack pinned this message
Z
11:54
Zack
In reply to this message
this is kind of important. we should find a cryptographer.
Ill ask my professor from university.
Deleted invited Deleted Account
J
20:40
Josh
I might have an idea but I haven't thought it through yet. Instead of a queue of who's next in line you could have a binary tree where the leaves are the hubs and each level up aggregates the hubs below it. To prove that everybody else waived their rights you just need an O(log n) merkle tree style proof of threshold signatures.
Z
20:45
Zack
What I'm really looking for here is a link to some paper explaining a kind of threshold signature/ring signature that could be useful to us.

Guessing at designs before we know what cryptography is possible isn't helpful.
J
20:47
Josh
Why can't this be useful? It's based on standard threshold signatures in common use.
Z
20:48
Zack
Does "threshold signature" mean that any n of m people from the list are needed to create the sig, and we don't know which n of the m had participated?
20:51
In reply to this message
I seriously doubt we can get rid of the queue of who is next in line.
The data structure works this way because all the contracts are immutable.

But it might be possible to collapse many waivers into fewer waivers.
20:55
In reply to this message
I'm starting to think that it isn't possible to combine the signatures this way because of information theory.

Each pubkey is a lot of info.
We can't fit all that info into a single sig.
So you would need the entire list of pubkeys to verify that one had participated.
Or the signature would need to be as long as the list of pubkeys.

I would be happy to be wrong about this.
J
21:04
Josh
In reply to this message
Yes but in this case it would be n-of-n, where n is the number of hubs in the group on a level of the tree.
21:06
The tree is static for a given set of hubs. Each time want to waiver everyone but one hub we create a waiver with log n sigs and commit that.
Z
21:11
Zack
"Waiver everyone but one hub"
Idk what this means.
21:12
An on-chain claim to win the lottery only has 1 pubkey that will win.
To show the claim is false we only need to publish a waiver for that 1 pubkey.
21:12
The reason we want to combine waivers is to collapse this history inside a sortition chain.
So if you own value in the sortition chain, you don't need to store as many bytes of waivers.
⛏ Aka Dri 🛠 | MEATEC invited ⛏ Aka Dri 🛠 | MEATEC
J
23:48
Josh
I wrote it out in some more detail. Still not sure about it since I still don't have all the details of all the sortition structures straight in my head.
23:48
We have n hubs with pubkeys H1...Hn. We build a binary tree where the leaves are H1..Hn and a higher level node K is the pubkey of the n-of-n threshold sig requiring signatures from all pubkeys that are leaves under K. For example, the node whose children are H1 and H2 will be called H1:H2 and signing a message with this pubkey will require hubs H1 and H2 to sign.

When a hub signs up for a place in line to own part of the sortition space, it submits its enhanced pubkey, which is the list of all pubkeys on the path from its leaf to the root of the tree, not including the root. For example in the set H1..H8, the enhanced pubkey for H3 is [H3,H3:H4,H1:H2:H3:H4].

Let's say everybody before H6 wants to sign waivers in order to give H6 control. Usually we would need to store signatures for H1 through H5. In this scheme, we only need to store signatures for H5 (signed by hub H5) and H1:H2:H3:H4 (signed by hubs H1...H4), which is O(log n) signatures instead of O(n) signatures.

If H3 later submits a sortition claim, H6 needs to prove it's false. H6 does this by submitting the signature of H1:H2:H3:H4 over the waiver message. Since H1:H2:H3:H4 is in H3's enhanced pubkey, this proves H3 is committing fraud. If H5 submits a sortition claim, H6 can submit the waiver signed by H5. There is no waiver signed by H6 so nobody can prove that H6's claim is false.
Z
23:55
Zack
so with this design, you need to tell the blockchain the entire list of pubkeys involved, and the signature is longer.

Ideally we want the on-chain aspects to stay O(1).

I don't see how this design would reduce the side of data you need to remember to own some of the probabilistic value space.
23:57
In reply to this message
im thinking cryptography was the wrong approach to solve this.
What we need is for the sortition claim data to be available when we process the waiver smart contracts.

That way, your waiver smart contract can know the block height and priority nonce of the claim it being applied to.
This allows you to use a single pubkey for multliple spots in line. you can use a single signature over a single waiver to give up multiple different positions you have in line.

This way the history cost is only linear with the number of participants in the hub, no matter how long the hub lasts.
23:59
oh right, chalang can already look up stuff from the on-chain consensus state space. So this is already possible.
15 April 2020
J
00:08
Josh
In reply to this message
Why does the blockchain have to know all the pubkeys? H3 submits a claim, part of that claim is its enhanced pubkey, that's all the blockchain needs to know. The enhanced pubkey is O(log n) times bigger than a regular pubkey. I don't think the signature has to be longer.
Z
00:12
Zack
O(log(number of participants in the hub)) per on-chain sortition waiver would be ok.
But what are the off-chain costs to owning some value in an active sortition chain?
00:14
In reply to this message
this solution seems really good.
on chain cost stays O(1).
off-chain cost is only O(number of participants in the hub). no matter how much money flows around inside the hub.
J
00:15
Josh
Yeah but I think you can combine the approaches to get on chain cost of O(1) and off-chain costs of O(log n) for n hubs.
Z
00:16
Zack
what is the log(n) data I would need to remember for owning value in a sortition chain?
00:16
these hubs already scale linearly with the number of participants, because all the participants need to talk to each other.
So if the history is also scaling linearly, it is not a big deal.
J
00:17
Josh
In reply to this message
the waiver signatures up the signature tree path from leaf to root.
00:19
In reply to this message
yep but this is O(n) per probabilistic payment, so don't we need to multiply that by the number of active payments?
Z
00:21
Zack
In reply to this message
i dont know what "active payment" means.
00:21
if you are talking about one bit of value being spent multiple times, the history doesn't get longer because new waivers from the same pubkey can replace the older ones.
00:23
if you are talking about one person making multiple payments, yes if you split a consecutive list of lottery tickets into 2 shorter sublists owned by different people, the waiver signatures they need to keep track of can diverge.

the hub participants can also work together to defragment the proofs. by swapping value with each other so they each own fewer bigger consecutive chunks.
00:29
In reply to this message
I think this only works if everyone is signing the same thing.
But what we want is for hubs to be able to give up control of very specific parts of the probabilistic value space.

So maybe for this design, we need to put all the updates into a merkle tree, and then all the hubs sign the merkle root.
so the master pubkey is O(log2(number of hubs in the pool)), and then you need a O(log2(number of waivers for this hub pool))
00:30
and using the other trick we can get the number of waivers down to O(number of hubs in the pool)
00:42
in the non-cryptographic design, for every part of the value space you own, you need 1 signature from each of the hubs. O((# hubs in pool) * (# chunks of value you own))
These are 2 numbers that we can keep fairly small.

it seems like with the cryptographic design, you need to remember some merkle proofs to show that the waivers you care about are inside the signed tree.
O((# chunks of value you own) * log2(# chunks of value owned in the pool) * log2(# hubs in the pool))

(# chunks of value owned in the pool), this is something that we don't want to restrict to being small.

I think it is likely the the non-cryptographic version is better both for on-chain costs, as well as in the number of bytes of history you need to know to own some sortition value.
Z
01:06
Zack
building these trees to update the state also takes time.
They need to sign things and pass the signatures around in order.
with the non-cryptographic version, it would cost O((# hubs)*(# payments routed))

with the cryptographic version, messages passed around is O((# hubs in the pool)*(# payments routed)*log2(# hubs))
01:07
I wonder if the storage requirement is very different for the hubs
J
01:20
Josh
In reply to this message
How big is this waiver with multiple spots? Would it also have to include multiple parts of the value space? Naively it would be O(number of spots) but you can make it O(1) by just writing the last spot. So 6 instead of 1,2,3,4,5,6. Can you do the same thing with the value space? I'm wondering if we can have one waiver that everybody signs off on that includes all the spot places and value spaces collapsed into a waiver of size O(1).
Z
01:23
Zack
If 2 contracts are adjacent and owned by the same member of the hub, the hubs can work together to combine it into 1 contract
01:27
We can put the waiver into a merkle tree of it is complicated. So we only need to prove the part that matters.

But like, if I have some value where 102 people have stepped out of line, and you have some value where 43 people have stepped out of line, and it isn't consecutive, and we don't assume anything about anyone else's contracts, then if we wanted to make a single waiver to give up ownership of both these things, it would need to reference the start and end of both our chunks.
And we would each need both the signatures.
So making a multi-waiver is more expensive than normal waivers.
01:28
The only way to Merklize the signatures is if we make a massive multi-waiver that combines everyone's waivers
01:29
Putting the waiver into a merkle tree is only o(log2 (# chunks)). Doing it all in one contract would be o (# chunks).

I still think the non-cryptographic version will be cheaper.
J
01:38
Josh
In reply to this message
I'm trying to understand this. When you sign one waiver to give up multiple spots, aren't you giving up multiple probability ranges? Are we sure these can be combined? How do we know you didn't just get some probability space from somebody else's waiver?
Z
01:40
Zack
The line to own one chunk of value is a cycle. abcabcabcabc.

Each time you appear in the cycle, it has lower priority.

So if you sign a waiver for priority 100, then you are giving up all the spots in line with a priority of less than 101.
01:41
The waiver has a turing complete smart contract. You can program it to be valid for any combination of probability ranges you want.
But then the contract is longer, and this contract is part of the history you need to remember to own the value.
01:43
Turing completeness means you can say stuff like ((if it is in range A) and (priority is smaller than 30)) or ((if it is in range B) and (the priority is less than 63))

You can program anything
J
01:48
Josh
Ok but say I'm signing a waiver for priority 100 and each of those spots had a different probability range. worst case, my waiver will be 100 * (size to represent probability range) which is O(number of times I make a payment) instead of O(1).
Z
01:49
Zack
With bitcoin if you divide up a tx and get change, you are increasing the utxo set
01:49
It is similar to that
01:50
Once you spend some value, you don't need to remember anything for it.
The new owner needs to remember its history
J
01:53
Josh
This is from the point of view of the hub receiving the value. He has to remember all the waivers so he can provide proofs against any counter claims. But if some hub before him passed this around n times, the size of the waiver he has to remember from that hub might be O(n) not O(1) since it has n probability ranges (if they can't be combined).
Z
01:54
Zack
They can be combined though.
Just keep swapping with other people in the hub until you have adjacent chunks
01:55
We can do these swaps instantly with waivers
01:55
Defragment
01:55
Like with ntfs file systems
01:56
Collapsing history seems easy. It is less expensive than remembering the massive ownership merkle tree of everyone who is in the cycle over and over
01:57
I wonder if we can fold the cycle on itself somehow
01:58
Like what if there is a sortition ownership contract that is valid for priority P where (P mod 23) == 6
01:58
Then someone else could have (P mod 23)==7
And we could have a pool of 23 hubs this way
01:59
dividing priorities into modulus this way is not supported by the current ownership tree. I wonder how we could add it
J
01:59
Josh
In reply to this message
These waivers still have to be remembered so we have to account for them in the waiver storage space.
Z
02:00
Zack
In reply to this message
If I signed a waiver giving up control of everything before priority 100, and then I sign one giving up control before 105, then no one needs to keep a copy of the 1st waiver.
02:01
So it is only O ((# hubs) *(# number of value chunks you own))
02:05
so you only need to remember the most recent waiver for each validator for each part of the probabilistic value space that you own
J
02:19
Josh
Let's walk through this. Say there are ranges A,B,C where H1 owns A and C, and H2 owns B and value(B)==value(C). H1 wants to defrag by swapping C for B with H2, so they do a waiver where H2 relinquishes B and now H1 owns A and B, let's called the combined range AB. Now H1 relinquishes AB so that H3 can own it. H3 has to remember the AB waiver but also that defrag waiver. So it's not O(1) anymore.
02:28
In reply to this message
If H1 wants to give up range D to H27, H1-H26 can all sign one message, that they're giving up ownership of D. So this still means only O(log n) storage for all hubs combined, for each waiver.
Z
02:33
Zack
initial state:
H1 owns A and C.
This means H1 has N-1 waivers to show that no one else owns A, and N-1 waivers to show that no one else owns C.
H2 owns B. so H2 has N-1 waivers showing that no one else owns B.

final state:
H1 owns AB.
this means that H1 has N-1 waivers showing that no one else owns AB.
H2 has N-1 waivers showing that no one else owns C.

transition:
A bunch of people give waivers for AB, and for C.
Now H1 is next in line to own AB, and H2 is next in line to own C.
H1 is still first in line for A and C, and H2 is currently first in line for B.

H1 signs a waiver that is only valid if H1 reveals a secret. this will cause H1 to give up control of C.
H2 signs a waiver that is only valid if the secret is revealed. it is to give up control of B.

H1 reveals the secret.
02:38
In reply to this message
im not sure what "for each waiver" means here.

I also don't see how them signing the same message reduces the storage costs.

it doesn't make sense to talk about "storage for all hubs combined", since each hub is only storing the history of it's own value. they each store different unrelated histories.
J
02:43
Josh
In reply to this message
The key point here is that they all sign the same message. The hub (H27) receiving the value of this series of waivers only needs to store O(log n) sigs and a single waiver message. Without the sig tree approach, H27 would have to store O(n) signatures.
02:44
In reply to this message
Still trying to understand this, I need to think about it some more.
Z
02:57
Zack
In reply to this message
There are N different hubs who could potentially try to claim your value on-chain.
What does one of the proofs look like to show that they have given up control?
How can these N different proofs be generated from only O(log(N)) sized data?
03:08
There have been a few times I thought advanced crypto might be useful.
But every time I look more deeply, it always turns out so much worse than just using hash functions and signatures.
03:09
I wonder if cryptography has anything else to give to cryptocurrency.
03:09
In reply to this message
Feel free to ask as many questions as you want
J
05:16
Josh
In reply to this message
The proof would look like a single threshold signature H1:H2:H3:H4 over the waiver message. This single signature works to prove that a claim by any of H1-H4 is false, since they all signed it together.
05:17
In reply to this message
I explained it in more detail here.
05:20
In reply to this message
"This means H1 has N-1 waivers to show that no one else owns A" but this doesn't say anything about the size of these N-1 waivers. We have to prove that total number of probability ranges referenced is O(n).
Z
05:22
Zack
In reply to this message
defragmenting lets us keep the number of ranges we need to keep track of in O(number of hubs).
We swap to own adjacent parts of the probability space, then combine them.
05:24
In reply to this message
so then, you would need to include on-chain, all the pubkeys for all the hubs?
05:25
if I have a waiver showing that hubN gave up control of the A part of the value space. and I have a waiver from hubN saying they gave up B.
Then they would be willing to sign a waiver giving up AB.
J
05:28
Josh
In reply to this message
No, the claim includes the "enhanced pubkey" which for each of H1-H4 includes the pubkey H1:H2:H3:H4
Z
05:30
Zack
so if H1 is trying to claim the lottery winnings, but H2 can show that H1 signed a waiver giving up the priority he is using in his claim.

H2 will need to include how many bytes of what data?
J
05:31
Josh
In reply to this message
I understand the defrag part and maybe you're right but I haven't been able to convince myself that the total number of probability ranges a hub has to store for the history of the waivers, including the defrag waivers, is O(number of hubs).
Z
05:33
Zack
you understand how if one person has ownership proofs for adjacent space, he can combine this proofs right?
He just asks everyone who has signed waivers over A, and B. they should now sign over AB.
05:33
so now instead of 1 list of signed waivers for A, and 1 list of waivers for B.
I just have 1 list for AB.
05:34
atomic swapping to own adjacent parts of the value space seems very simple. im not sure what part could be confusing.
J
05:35
Josh
In reply to this message
H1 publishes a claim with his enhanced pubkey [H1, H1:H2, H1:H2:H3:H4]. H2 just publishes the waiver message signed by any of H1, H1:H2, or H1:H2:H3:H4, since we know H1 had to take part in the signing for any of these sigs to be valid.
Z
05:39
Zack
"publishes a claim with his enhanced pubkey"

Currently, a claim is a merkle proof showing that you owned the part of the probabilistic value space that had won.
05:39
How do I know this list of pubkeys is the correct version of the enhanced pubkey?
J
05:40
Josh
In reply to this message
it's not how it works that it's confusing, it's how many probability ranges we need to reference throughout the history of the waivers. you're claiming O(n) but these histories can get very complicated. H1 can send a piece to H2 another piece to H3, another piece to H4; H2 and H4 can send pieces of those back to H1. I'm not convinced that all these pieces, in a very long line (> O(n)) of transactions can be collapsed to O(n) prob. range references.
Z
05:40
Zack
immediately simply between every pair of txs.
05:41
so it starts as:
[H1][H2][H3]
They each own one chunk. then H1 sends some to H3:
05:41
[H1][H3][H2][H3]
So now if H2 and H3 swap a little, we will be down to only 3 ranges again.
05:44
imagine if i have oil and water and mercury in a glass cup.
They will organize into layers.
No mattter how much you stir, they will return to their layers.
05:46
it isn't much different than an algorithm for sorting a list in place.
J
05:49
Josh
In reply to this message
this enhanced pubkey is what gets put in the merkle tree when the hub gets added to the sortition, so it's part of the merkle proof. the enhanced pubkey is the hub's identity.
Z
05:50
Zack
Here is a geralized algorithm.
Hubs 1 through N: H1, H2, ...
own total portions of the value space P1, P2, P3...

we want to end up with them owning consecutive ranges in the order [H1][H2][H3]

So we can calculate the transition points between ranges.
Between H1 and H2 is the point P1.
Between H2 and H3 is the point P1+P2...

Everyone just keeps swapping until they own the proper range that they can calculate.
05:52
In reply to this message
the ownership object currently looks like this:
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/trees/ownership.erl#L30
What fields do you think this thing should have?
It is for recording who owns which part of the sortition value space.
J
05:53
Josh
Another question I have: if H1 gives up range A and then H27 gets ownership of A and wants to give it back to H1, how does it do that? H1 will publish a claim, can't someone use the first waiver to refute the claim?
05:54
In reply to this message
it would be exactly the same except pubkey would be the enhanced pubkey
Z
05:54
Zack
it is a cycle, H1 is in the list every 28th time.
Each time is a lower priority.
If H1 gives up all claims with priority higher than H, that means he still has all his spots in line with priority lower than H
05:55
In reply to this message
because my plan for the hub involves thousands of these ownership objects.
every ownership object is only one spot in line. So if you give up that spot in line, and you want to receive the value again later, then you need another ownership object.
J
05:56
Josh
yeah, it's only length(pubkey) * log(number of hubs)
06:00
In reply to this message
ah ok, i think i get that. the ownership record (and claim) that's being rejected has to have a higher priority than the waiver.
Z
06:01
Zack
the claim is published on-chain first.
Then people can use waivers to show it is invalid
06:01
if the waiver has a valid smart contract, and it is signed with your pubkey then your claim is invalidated.
J
06:02
Josh
but they can't use waivers that have a higher priority reference, so he can still receive the value at a lower priority even if he signed a waiver at higher priority.
Z
06:02
Zack
the smart contract can say that it is only valid if the claim's priority is lower than a threshold
06:05
so basically, you think the ownership object should have a list of extra pubkeys. these pubkeys can sign waivers which can invalidate this ownership object.

And by carefully selecting the pubkeys in this list, it will allow the hubs to save memory?
06:06
because if all the hubs work together to agree on how everyone should do their waivers, you only need to remember one signature, instead of one for each hub.
J
06:06
Josh
yeah, so if I published a waiver that's only valid if the priority is >5, and then everybody else gives up their priority 6-10 and i get it back at priority 11, I can publish a claim with priority 11. they can't use that waiver against that, and nobody else can publish a claim that I can't reject because they all gave up their places.
Z
06:07
Zack
why have a full enhanced pubkey? why not just 1 pubkey for individuals making a waiver, and 1 pubkey for the entire pool of hubs making a waiver?
06:08
In reply to this message
if the waiver is valid for priority >5, then that means the waiver can be used to invalidate any claim with priority >5.
J
06:10
Josh
In reply to this message
Hmm, maybe that would work if the waiver says "everybody but H3 waives their place for segment D for priorities >100". Everybody signs it with the common pubkey, including H3, and the value transfers to H3.
06:14
Now H3 only needs to keep one sig and one waiver. If anyone tries to publish a claim, he can prove they signed the waiver.
06:15
If someone tries to use that waiver against H3, it won't work even though he signed it because it doesn't match his claim.
Z
06:24
Zack
so, if we use the cryptographic strategy, the on-chain cost of a waiver is: O((size to specify all the ranges)) -> O(# hubs)
the memory to own value is O(1 waiver) -> O(# hubs)
messages sent to transfer value is O(1)

If we use the non-cryptographic strategy, on-chain size of a waiver is -> O(1)
the memory to own value is O((size of waiver) * (number of hubs)) -> O(# hubs)
the messages sent to transfer value is O(1)
06:26
we could put the ranges into a merkle tree. and then the cryptographic strategy is O(log2(# hubs)), O(log2(# hubs)), O(1).
06:27
I feel like this is not going to be a bottleneck of the system, and the potential speedup is not worth the cost of the extra programming.
06:29
on-chain data is like, tens of thousands of times more valuable than data a hub needs to remember.
So making an on-chain waiver go from O(1) to O(log2(# hubs)) is actually a big deal.
It could easily be more important than the benefit of having off-chain data decrease from O(# hubs) -> O(log2(# hubs))
06:30
especially since the # hubs in a hub pool will stay small for other reasons.
06:30
it eventually gets too expensive for everyone to sign txs for everyone else. passing messages between hubs in a hub pool takes time
06:31
if the # hubs per pool is always less than 128, and a signature is 64 bytes, we are only talking about 8 kilobytes here.
06:32
not exactly something worth spending time optimizing.
06:32
it isn't worth it to make the on-chain cost of waivers 7x more expensive, just so hubs are storing 1 kilobyte off chain instead of 8 kilobytes
J
06:34
Josh
I didn't understand all the points but I generally agree that O(#hubs) space for off-chain storage is not going to be an issue for a hub pool even if there are 100,000 hubs.
06:38
so all hubs need to defrag all their value into a contiguous range before doing a waiver? then the waiver will always only have a single range.
Z
06:40
Zack
they don't need to defrag every time.
defragmenting costs waiting for messages to get sent around.
not defragmenting costs more memory.
memory is very cheap.
It is better to wait and batch the defragment.
06:40
or it can be continuous.
Since each hub bears the cost of their own history
06:40
they can choose for themselves when it is worth it to simplify
J
06:43
Josh
however, if I have a continuous range A in the end, I need to store all the waivers that will protect it. It's true that all the waivers were signed by only N-1 parties but these waivers could have been produced at different stages of defragging. So how do I know that I only need N-1 waivers to protect my A? All the other space is in contiguous pieces but that's owned space, the waivers could have been issued a long time ago.
06:44
each hub only has to remember its waiver history once but it's placing a cost on all other hubs so the incentive might not be aligned.
06:48
I don't really mind as long as we're guaranteed O(#hubs) storage. Still have to convince myself of that.
Z
07:29
Zack
you only need the most recent waiver from each hub for each range of value space.

If you are holding old fragmented waivers in pieces, then ask them to sign a bigger waiver that is in one piece.
07:30
In reply to this message
you could pay some small fee as a part of the swap to buy a continuous range.
07:31
so whoever is causing the fragments is the one paying to defragment
J
17:04
Josh
Ok, I think I managed to explain this to myself. Assume all hubs have contiguous ranges. Any time during the history of the payment each hub can publish a waiver which has two ranges: everything to the left of its current range and everything to the right of its current range. Now all the hubs have N-1 waivers with a total of 2*(N-1) ranges and those are enough for each of the hubs to provide proofs against any claims to their range.
Deleted invited Deleted Account
16 April 2020
J
02:10
Josh
Zack, I'm trying to figure out the details of how the sortition operator updates the merkle trees when a new ownership request comes in. Is there a place where the details are documented?
Z
02:12
Zack
they put all the ownership requests into a merkle tree. all the validators sign the root. the root with the signatures goes on-chain.
here is the tx implemented https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/txs/sortition_block_tx.erl#L24
02:13
the tx is only 34 lines of code
J
02:16
Josh
Thanks! I'll start looking into this.
Deleted invited Deleted Account
J
16:23
Josh
When the validators get the ownership request, what to they have to verify before putting it in the merkle tree? Who does it have to be signed by?
Deleted invited Deleted Account
Joseph C invited Joseph C
Z
20:38
Zack
In reply to this message
the entire list of validators signs the merkel root of the ownership tree.

Before adding someone new to the line to own some value, the validators should check that whoever is currently first in line, that they give permission to add someone new to the line.
20:38
so they will need a signed request from whoever is first in line.
This request can never end up on-chain, and it doesn't need to be stored for any amount of time.
J
20:42
Josh
Whoever is first in line owns the whole probability space right? So no need to check that when checking the signature?
Z
20:44
Zack
if you are first in line, then you own the value that you are in line for
20:47
https://cryptobriefing.com/central-banks-recommended-ban-stablecoins/
A stablecoin ban would be so good for Amoveo.
It would get rid of some of our less-secure competitors for stablecoins.
J
20:48
Josh
If I start a new sortition chain, I own all the value in the chain. If I want to give some up I have to put someone next in line. But how would I be first in line and not own all the value in the chain?
Z
20:49
Zack
if you are first in line, then you own the value.
If you are not first in line, you don't own the value.

>"how would I be first in line and not own all the value"?
that is not possible. because if you are first in line, then you do own the value.
J
20:57
Josh
Let me phrase it a different way. If I start a chain, only I'm allowed to sign ownership requests to put people behind me in line. But let's say I put Alice behind me in line and then signed a waiver. Can she now sign an ownership request to put someone in line after her to get her value?
Z
20:58
Zack
the validators can sign the merkle root of the ownership tree, in order to put new people in line.

If Alice is first in line, and she asks the validators to put someone in line after her, then they are supposed to comply.
J
21:01
Josh
Ok, cool, that's what I wanted to know. But they have to check that she owns the probability space that covers the ownership record and she has to send the validators the waivers that prove that she's actually next in line.
21:02
I'm trying to understand this data availability attack.
21:04
If a block is published by the validators and I see that I don't have a complete merkle proof to prove ownership, can't I use a merkle proof from a previous block?
Z
21:05
Zack
you can use the merkle proof from the previous block to show that you still own the value yes.
21:05
Lets say you gain ownership in block 5.
21:06
then in block 6 a root is published, and you can't prove if anyone was added to the line after you or not. the data is unavailable.
21:06
so if you try to add someone to the line in block 7, they can't know if they are 2nd in line, or 3rd, or 36th.
21:06
so no one will accept a payment from you.
J
21:14
Josh
Ok, thanks.
Deleted invited Deleted Account
17 April 2020
Deleted invited Deleted Account
Z
01:13
Zack
Ownership cycles. This is where we have an infinite loop of the same N people to own the same value. They are in line infinitely.

If we have a cycle of only 2, it seems like it could do everything a channel can do.

The only difference is that a channel that wins the lottery can keep existing on-chain for a period of time after the lottery has ended.
If we have a cycle of 2, then exactly one account will win.
01:16
I think the ownership cycle plan is important. Because it solves liquidity issues that would otherwise arise if tried using lightning network type tools to do things faster than the on-chain period.

This may also help for creating and enforcing single price batches in markets.
If we have ownership cycles, then you can instantly participate in a market without having to wait for an on-chain post to set it up.
J
01:27
Josh
Simplifying the design by removing channels would be very attractive. I don't think existing on-chain after winning the lottery is a big advantage.
01:27
Would you be able to add new people to the end of the loop after waivers start happening?
Z
01:57
Zack
In reply to this message
the infinite cycle is only connected to one block height.
If everyone in the cycle signs waivers giving up control of that entire block height, then whoever was added to the line in subsequent blocks becomes the new owner of the value.
J
01:58
Josh
makes sense
Z
01:59
Zack
In reply to this message
If the sortition chain only lasts a month, but you want to bet on something that will happen in 2 months.
Z
02:22
Zack
im imagining that people will use a channel with a hub to instantly make bets in any market.
then they ask the validators to make a direct channel for the bet.
Then they do an atomic swap to move the bet from the indirect path to the direct path.

A problem with markets today is that there are so many of them. and it takes time to put your money into a market so you can make a trade.

With Amoveo it can be flipped around. So participating in the trade is instant, and the slow step is afterwards.
Musa invited Musa
J
03:53
Josh
In reply to this message
But what happens if the channel loses the lottery?
Z
03:53
Zack
In reply to this message
oh right.
Everyone with channels wants to settle the channel and sell their lottery tickets before it ends. so they don't hold lottery risk.
03:54
so the channel can't exist longer than the sortition chain
J
03:54
Josh
can you just roll over a bet from one sortition chain to a new one?
Z
03:56
Zack
you can move a bet from one sortition chain to another, as long as the person on the other side of the channel cooperates.

But if they don't cooperate, then it is stuck on the first sortition chain.

So, if our goal is to have a trustless protocol, then this is not a valid strategy to have bets that last longer than the sortition chain.
J
03:58
Josh
we know when the sortition chain will end and both sides have an incentive at the start to be able to roll it over, so maybe there's a way they can agree to freeze it and start it over on a new chain.
Z
04:01
Zack
It seems impossible.

What is even the purpose of the channel in the first sortition chain, if it is guaranteed to get deleted anyway?
04:01
it might as well have never existed
J
04:05
Josh
i was thinking about bets in sortition chains, without channels
Z
04:06
Zack
if a bet is not enforceable, and is guaranteed to be deleted, it seems to have no purpose.
J
04:07
Josh
in that case you'd always need to make a bet in a sortition chain that expires after the bet expires
Z
04:08
Zack
right. that seems to be the case.
J
04:08
Josh
might not be a big deal, since the sortition chain itself is technically just a kind of bet
Z
04:09
Zack
Unfortunately, our current oracle design can take many rounds to finalize. There is no solid block height when the result is available.
Which makes it difficult to use oracles in bets inside the sortition chain.
04:09
We just need a really big buffer
04:09
so the oracles should aim to expire like 4 days or a week before the sortition chain would expire.
J
04:10
Josh
are the oracles guaranteed to expire after a finite amount of time?
04:10
instead of setting a fixed block time for sortition expiration, we could link it to the oracle finalization
Z
04:10
Zack
if no one interacts with the oracle, it can exist indefinitely.
04:11
game theoretically, the nash equilibrium is that the oracle will end rather quickly.
If you try to delay it, it is like giving away free money
04:11
and people can get in line to accept your free money, if they expect you to keep trying to delay the oracle.
04:12
so you need to throw away very large amounts of money in order to delay oracle resolution a significant amount of time.
04:12
I guess whoever is disappointed that their bet in the sortition chain isn't finalizing correctly, they can make up for it by accepting a bunch of free money from the oracle mechanism.
J
04:13
Josh
maybe we can just combine the sortition idea with oracles; after the oracle finalizes there could be a sortition random number process and a claim process
Z
04:14
Zack
that would require us to know what all the oracles we could want are ahead of time.

We use a strategy where most oracles never end up on-chain. As long as both participants in a contract can agree on how it would resolve if the oracle was created, then they don't need to pay to create the oracle.
04:15
Some kinds of contracts reference thousands of oracles, and at most only one of the thousands could need to end up on-chain.
J
04:17
Josh
ok, i need to read up on that process
Z
04:23
Zack
It is the same process as any oracle. The only difference is that instead of making the Oracle before you bet, you make it after.
The browser light node supports this already.
Z
06:26
Zack
it would be cool to use a sortition contract to make a giant stablecoin of some kind.
And use all that stablecoin value to make a new sortition chain.
Then there would be a sortition chain entirely denominated in the stablecoin.
Deleted invited Deleted Account
Pang 007 invited Pang 007
Deleted invited Deleted Account
J
16:24
Josh
In reply to this message
can you explain this in more detail? what do you mean by stablecoin value? doesn't the new sortition chain have to be denominated in veo in the current code?
Lord Mazo invited Lord Mazo
L
17:04
Lord Mazo
Is the explorer working?
J
17:05
Josh
Zack, what do you think of the idea of restricting smart contracts to turing-incompleteness by disallowing loops and recursion? Then we might not need gas at all. https://github.com/kadena-io/pact
17:06
In reply to this message
Which URL are you using?
L
17:07
Lord Mazo
Deleted invited Deleted Account
J
17:13
Josh
looks like it's down
Z
17:14
Zack
In reply to this message
Veoscan has been gone for a while. You can get the same info from our other explorers
17:15
In reply to this message
Put a sortition contract to split up the value between long-veo and stable-btc.
Now create a baby sortition chain on the stable-btc side.
17:16
Deleted Account
Amoveo fits all our needs to be our next projects, we still have some questions, can i talk to Admin or Mod?
Z
17:17
Zack
In reply to this message
Loops are convenient. I don't see any advantage to disallowing them.

Chalang doesn't have explicit looping. It uses recursion for that.
But again, recursion is useful. And there is no advantage to avoiding it.
J
17:19
Josh
What about the advantage of not needing gas?
Z
17:20
Zack
In reply to this message
A big difference between amoveo chalang and other blockchain languages is that we don't have any shared mutable contract state.
Any amoveo contract is run only once to settle a channel or sortition chain. The contract is not stored in the blockchain consensus state for any length of time.
17:20
In reply to this message
How is that an advantage?

Even without loops, different operations coat different amounts of resources, and should impact the fee differently.
J
17:23
Josh
Gas is complicated to analyze without running all the different input possibilities. Without gas you might be able to just charge a static fee for a contract, so you don't get out-of-gas runtime errors. You could still charge different amounts for different resources but you'd know the cost up front.
Z
17:23
Zack
For chalang, I optimized it to have short contract length. Because that way we can fit more txs in a block.
Looping is useful because we can write shorter contracts.
J
17:24
Josh
You could still have recursion but it would have to be bounded. You'd define the recursion depth before doing a recursion.
Z
17:24
Zack
In reply to this message
What's wrong with out-of-gas errors? The tx is still valid, you still pay a fee, only it doesn't update the on-chain consensus state.
17:25
In reply to this message
Sounds annoying to program. For zero advantages.
J
17:27
Josh
It's important for people to understand the contracts they're participating in, out-of-gas runtime errors is something they have to analyze, or they could get outcomes they're not expecting.
Z
17:27
Zack
In reply to this message
So basically that means defining a separate amount of gas for every instance of looping.
17:28
In reply to this message
A recursion depth limit is even harder to analyze
17:29
In reply to this message
No user is ever looking at smart contract code.
They look at pretty light node interfaces and click on buttons.
J
17:30
Josh
So how do they know they're not getting ripped off?
Z
17:31
Zack
If they download amoveo wallet software, the simplest way to rip them off would be to have a line that sends me their private key.

But sure, I could instead embed a fancy bug inside the smart contract code embedded in the wallet.
17:32
Getting wallet software involves some kind of trust, or reputation
J
17:33
Josh
I'm not talking about the wallet software, I'm talking about the smart contract code
17:33
The instances of the smart contracts embedded in waivers
Z
17:34
Zack
The only way to use amoveo is with the wallet. Any smart contract is embedded in the wallet software
17:35
In reply to this message
If a waiver doesn't exactly match the default format produced by a light node, then it is not accepted for payments.
17:36
Most waivers look like this:
((Rng > 0.34) and (rng < 0.37))
J
17:36
Josh
But waivers can look like something with an infinite recursion
Z
17:38
Zack
If I want to send you value from my wallet to your wallet, I don't need to know what a waiver is. That is all behind the scenes.
17:38
I would be looking at an interface that says my balance. And I type in your address.
17:38
I would choose how much to send, then click "spend veo"
17:39
Or I would be looking at a market depth chart. Where they are betting on a sporting event.
I would choose how much to bet, and my limit price, then click "make bet"
17:39
Our users never even need to think about the concept of a "smart contract"
17:42
Our users never think about gas
17:42
There will be a small handful of hard coded smart contracts based on the gui interfaces available in the wallet software
17:44
The reason we use smart contracts instead of writing more blockchain code is that the smart contracts can be updated wihout needing a hard update. So mining pools don't need to update, full nodes don't
need to update.

To change a smart contract, only the wallet software needs to be changed.
17:44
This makes it easier to maintain amoveo
J
17:48
Josh
If most of the contracts don't have recursion it wouldn't matter because we'd be able to statically analyze those. So there would only be an issue with smart contracts that have recursion, which I think you're saying will be rare.
17:48
I don't think all users will analyze smart contracts but there will be experts who will and will report on problematic contracts.
Z
17:49
Zack
You are going to statically analyze the smart contract code in the light node? Do you also statically analyze all the javascript I used to write the light node in?
17:49
Javascript has recursion too
17:49
Either the wallet software works, or it doesn't.
17:50
There could be a bug anywhere. It would be a lot easier to hide a bug in the big javascript code instead of in the small smart contract code.
17:52
How can you be sure which smart contract code the javascript will actually use?
Maybe you will analyze one hard-coded contract. But the javascript has an attack embedded in it so that it uses a different smart contract when you make bets.

javascript is turing complete
17:53
The most probable wallet attack would be that the attacker tells the wallet to send your private key to them.

Putting any other exploit into the wallet does not make sense.
17:56
Amoveo smart contracts are completely immutable.
You really can run them for the entire possible input space if you wanted to.

The input space is things like, whether a secret has been revealed, or whether an Oracle result was true/false, or whether someone provided a signature
17:59
Other blockchains, their smart contracts are persistent. They live on-chain and own state that mutates over time.
So analyzing them to see if they will run out of gas is complicated and important.

In amoveo, the contracts are immutable. Nothing about them ever changes.
Some evidence is provided to the contract, and the only output is how to divide up the money that depends on the smart contract.
J
18:11
Josh
Ok, thanks for the explanation.
Z
18:13
Zack
I use recursion in the stablecoin contract.
Each oracle only provides one bit. So we need 10 oracles to encode the price.
And I use recursion to combine the 10 bits into a number
Deleted invited Deleted Account
Z
22:20
Zack
completely getting rid of looping is tough.
We would have to get rid of higher order functions too https://en.wikipedia.org/wiki/Fixed-point_combinator

Gas is really simple. It is easy to verify contract security. It is easy to understand. It doesn't put unnecessary constraints on contract development. It allows for a language that minimizes the number of bytes per contract.

In languages without recursion, you need to format all the loops as like, for-loops. Which forces you to use more verbose syntax, and make the contract longer. It increases the amount of local state you need to be aware of while reading the code. It prevents the natural functional syntax.

Functions are so simple, and they give us a lot of capabilities immediately.
If we restricted functions to be non-turing complete, then we would need to add a lot more features to chalang for the language to be usable. This would make it harder to learn and understand chalang.

We have a nice lisp-like compiler for chalang, so you can write in a higher level language with immutable variables. If chalang didn't have functions, then a lisp like language wouldn't be possible. We would need a bigger more complicated compiler.

bugs and exploilts don't just hide in the smart contract code. They can be hidden in the compiler too.
It is better to have a very simple compiler, so it is easier to verify the security of the bytecode of the contracts that are produced.

chalang's high level lisp-like language has immutable variables and pure functions, which makes it very easy to analyze smart contracts, because the total possible states that the contract can be in is very small.
22:26
https://github.com/zack-bitcoin/chalang Here is the repository for the smart contract language we use in Amoveo.
22:28
it has about 65 opcodes. fewer than the bitcoin script VM or the ethereum VM.
22:30
here is the lisp compiler we are using https://github.com/zack-bitcoin/chalang/blob/master/src/compiler_lisp2.erl
It includes just-in-time optimization.
22:34
https://github.com/zack-bitcoin/chalang/blob/master/src/lisp2/sort.scm here is merge sort defined using a higher order function.
So you can sort based on whatever function rule you want.

the ability to use higher order functions this way can significantly reduce repetition in the smart contracts, resulting in shorter byte code.
Which is what we are optimizing for. We want the on-chain txs to be as short as possible, so we can fit more txs per block.
crowm cartenz invited crowm cartenz
Z
22:36
Zack
the major differences between the chalang VM and ethereum vm:
* with chalang there is no "call contract" stuff. because the smart contracts are never stored in consensus state. So none of the smart contracts can be aware of any other smart contracts.
* with chalang there is no state storage opcodes. because the smart contracts do not have any persistent on-chain state at all.
18 April 2020
Deleted invited Deleted Account
Z
13:17
Zack
Here is a kind of interesting thing we could do with sortition chains.
Lets say I want to make a market to bet on a sporting event.
To start, I could make a sortition contract to split up some of my money into 2 types. the A type can only win if Alice wins the game. The B type can only win if Alice does not win the game against her competitor Bob.

Next I want to sell these 2 piles of value in single price batches.
If Charlie wants to bet on Alice, I can make a channel with Charlie. Charlie puts veo from inside the sortition chain into the channel, and I put in some A type value, that can only have value if Alice wins.

So now, we have a channel that contains both veo and A type value, so we can make contracts to exchange these 2 kinds of value.
We could use atomic swaps, or single price batches.

The trick is to use the same Channel ID in both ownership objects. That way a single channel smart contract is valid for either of them.
Z
14:42
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_theory.md I added some more documentation to justify our design choices.
J
15:18
Josh
Do we still need channels if we have cyclical ownership for waivers?
Deleted invited Deleted Account
Z
15:23
Zack
In reply to this message
I guess we don't need channels. the cyclical ownership tool can accomplish all the same goals.
15:23
it is probably better to use the cyclical ownership tool everywhere, since it is more general. Stuff we build for it is more reusable.
Z
15:47
Zack
I wonder how we should fit these cyclical ownerships into the tree.
15:59
one option is the write the entire list of pubkeys onto an ownership object.
another is to have the ownership object contain the merkle root of a tree of pubkeys.
another option is to change how the rules of the branches of the sortition ownership tree work, so that it can specify the modulus that is being used when it walks down certain paths.
15:59
right now I am leaning towards having a merkle tree of pubkeys on a single ownership object.
J
16:46
Josh
Maybe when you submit a claim you have to indicate which cycle the claim is for. When you sign a waiver you also indicate what cycle the waiver is for. Do we have to change anything else?
Z
16:47
Zack
that is what happens crypto-economically sure.
Im wondering how to format the data structure now.
Deleted invited Deleted Account
J
16:55
Josh
what's the difference between the current ownership queue and a cyclical ownership queue. I didn't understand why the ownership data structure has to be changed.
Z
16:58
Zack
the ownership tree is different from a normal merkle tree.
As you walk down the merkle path, there are rules that uniquely define the boundary of the value space that is owned by the object inside.
16:58
normally, you make the key to store something from like, the hash of the pubkey.
16:58
but in this tree, the key is the chunk of value space that you own.
16:59
that way, a merkle proof of ownership is also a proof that no one else can possibly own the same chunk of value from the same merkle root as you.
16:59
and a merkle proof of an empty location is a proof that no one owns that chunk of value from that merkle root.
17:01
so it isn't clear if the size of a cycle should go higher up into the merkle branch rules that define the boundaries.
17:06
In reply to this message
I still think this is probably the best plan.
J
17:08
Josh
In reply to this message
why does the size of the cycle have to go into the merkle tree at all?
Z
17:09
Zack
it is important to maintain the property that every merkle proof is a unique chunk of the value space
17:09
so, the other proofs need to be aware if this branch has taken control of the entire priority dimention with a cycle.
J
17:31
Josh
I still don't understand but I'll wait to see what your new implementation looks like.
Z
17:33
Zack
this is probably the most key concept that allows the sortition chain to work.
17:33
and it is already implemented.
17:34
the merkle path uniquely defines a chunk of value space.
17:34
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/trees/ownership.erl#L39
See, we have this boundary object, to know what space is still available to be assigned to
17:35
it has boundaries based on priority, sortition id, probability space, and contract space.
Collyn invited Collyn
Deleted invited Deleted Account
lspwd invited lspwd
19 April 2020
Deleted invited Deleted Account
Elize invited Elize
Samim invited Samim
Nick invited Nick
20 April 2020
Deleted invited Deleted Account
Deleted invited Deleted Account
Lord Mazo invited Lord Mazo
L
19:24
Lord Mazo
What’s better to buy some veos?
19:24
Qtrade?
I
19:37
Instinct
In reply to this message
Yep
L
19:40
Lord Mazo
You send btc right?
19:40
I prefer to transfer eth due the gas costs and speed
19:40
But I’m afraid of being unable of converting eth to btc in a good rate
I
20:06
Instinct
In reply to this message
Yeah btc is better for qtrade. Their eth / btc market doesn’t have much volume
21 April 2020
Z
01:53
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/smart_contracts_as_derivatives.md
I made this document to try and argue the case for why all blockchain smart contracts should be derivative contracts.
Jimmy invited Jimmy
L
23:23
Lord Mazo
Hi there is a big gap in sell buy orders in qtrade
23:23
as there is very low liquidity I will place an order in 0.0025
23:24
Just in case someone wants to dump
B
23:28
Ben
5 Veo? hahaha
L
23:29
Lord Mazo
😂
23:29
I’m broke
23:29
Coronavirus is killing my finances
22 April 2020
Z
01:44
Zack
The enlightenment is stalling.
Humanity is stuck half way between the age of reason, and the age of faith.

Atheists won the memes, but theists still control the genes.

The ability to use reason and logic is incredibly powerful, and has allowed us to conquer nature in unimaginable ways. These same tools that give us power to know why some decisions are better than others, they also strip us of our ability to cooperate.
Once we can use reason to know that a goal isn't in our best interest, we stop cooperating to achieve that goal.
Without faith to unite us, we become scattered and weak.

Without the ability to cooperate, humanity is on a death march towards extinction.

And so we find ourselves in a world with:
* rich atheist cultures that constantly vanish.
* poor theist cultures that constantly grow, and then get consumed by the memes of reason, to convert into new atheist cultures.

Futarchy is the solution.
With futarchy, reasonable people will finally be able to cooperate the way faith-based people can.

We will finally have rich, stable, long-lasting cultures who are capable of making decisions in their own best interest, and cooperating to achieve shared goals.
ŽM
01:51
Živojin Mirić
ALL HAIL FUTARCHY!
CD
02:13
Crypt Dweller
If demand continues to dry up for VEO over the next year and liquidity more or less disappears, the miners will stop having an incentive to expend energy to secure the network and it could fail as a lack of users/demand drive miners off the network
02:15
Would people rate this as the biggest risk to VEO's survival over the next year or two? There's probably a limited time to engineer the architecture before it becomes unreasonable for miners to continue supporting the network. They may be hoarding the coins now in hopes of an eventual discovery/usage of Amoveo, but their anticipation of future value must be contingent on Amoveo's ability to draw users, and that window of time is shortening
02:19
Zack I think you would find Oswald Spengler's Man and Technics an interesting read
Z
02:20
Zack
https://en.wikipedia.org/wiki/Man_and_Technics he sounds like a racist luddite
CD
02:21
Crypt Dweller
That's a misinformed and reductive understanding, but he is right wing
02:23
He created the first truly modern theory of history that accounts for the rise and fall of civilizaitons
02:23
And wrote extremely thoughtfully about Western science
Z
02:25
Zack
There is something cool we can do with the sortition ownership cycles.

Usually when you make a payment in a cycle, you need all the participants to sign off on that payment.

But lets say there is a cycle of 10 people, and 3 of them are planning to do a bunch of payments between each other, and don't want to bother the other 7.

The 3 could create an ownership cycle inside of the larger ownership cycle.
So they can make lots of instant payments together without needing the other 7 to sign off.

To do this, the other 7 just sign waivers to give up control of the next 1 million priorities or so. This gives the final 3 the ability to move the money between each other up to 1 million times.
K
02:25
K
In reply to this message
it's been almost 100 years since he wrote that book and western civilisation is still as strong
Z
02:31
Zack
If we have a cycle of 10 people, and 4 of them only want to trade stablecoins, 5 of them only want to trade long-veo, and 1 of them wants to trade both.
We could make 2 mini-cycles, one with the 5 people who want to trade stablecoins, and one with the 6 people who want to trade long-veo.
02:38
creating the 2 mini-cycles doesn't require anything to be published on-chain. it can be instantaneous.
02:41
So, lets say there is a new sortition chain with 5 validators.
Will those 5 validators immediately put all the money from the sortition chain into a 5-cycle between themselves?
02:43
all 5 need to sign off to transfer any money anyway.
It seems like once the money is in a 5-cycle, this only gives them more capabilities without creating any limitations.

So it makes me think that in a new sortition chain, all the money should start out in a cycle between all the validators.
02:44
as the default initial state.
Z
05:44
Zack
oh, I guess that means the history would start out with as many signatures as there are validators. a small cost.
Z
10:35
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/smart_contracts_as_derivatives.md Any questions about this? I am going to put it on twitter soon.
Any suggestions?
10:43
thanks
Z
11:40
Zack
im especially interested if any parts are confusing, or any arguments are unconvincing.
CD
14:29
Crypt Dweller
Zack, if you care to share, what is the most important design element you've discovered or technical realization you've had since launching Amoveo?
14:39
Relatedly, have you revised your understanding of the technology since launching Amoveo? I imagine that developing Amoveo has caused you to correct prior assumptions or notions you may have had about this idea of futarchy.
14:40
I apologize if my questions are not directly beneficial, you should of course feel free to disregard them.
m invited m
P
20:31
PIP
What is the circ supply atm?
Deleted joined group by link from Group
Z
21:50
Zack
In reply to this message
I'm not sure most important.

I started off with the same plan as truthcoin in Jan 2014.
So some big realizations since then were:
* voting can't be a secure oracle mechanism, or a blockchain consensus mechanism.
* how to reuse Nakamoto consensus to make a secure Oracle, with an escalation mechanism.
* I invented the idea of state channels. Because on-chain LMSR was not scalable enough.
* the realization that shared mutable state was going to prevent scalability, that every smart contract needed to be formatted as derivatives.
* I came up with a strategy to connect the channels together for single price batches in markets.
* once we realized that channels have liquidity issues, I figured out how to combine probabilistic payments with channel tech to invent sortition chains. The secure on-chain rng was tough. I had to talk to many people and read a lot of papers.
* through trial and error we found out that the on-chain oracle can't be used as a futarchy mechanism. It can only be used to report the result of futarchy.
* we also found that a simple 4-way bet (AB) (A!B) (!AB) (!A! B) does not work as a futarchy market. That it is important to have a bet like: ( if A doesn't happen, the bet is undone. If A does happen, then we are betting on the outcome of B ).
21:55
The importance of single price batches to avoid front running was a realization explained to me by Casey detrio.
This lead to the discovery that on-chain single price batches are impossible because of miner frontrunning. And inspired the invention of off-chain single price batch mechanisms in channels.
22:03
jae kwon did say to me "it is impossible to have single price batches in channels, and that is why we need on-chain smart contracts".
Which inspired me to prove that on-chain batches are impossible, and only off-chain can be secure.
22:06
I was building it with a PoS consensus for a long time. I implemented many different pos protocols, only to find vulnerabilities once they were done.
Luckily jack, this Swedish guy I met in Berlin, he explained how PoS was not a critical feature of futarchy, and that I shouldn't get distracted from my main goal.

And then later on I was able to prove that PoS is impossible.
23 April 2020
Z
00:32
Zack
once we have sortition chains working, should we get rid of on-chain state channels entirely?
They aren't scalable. but they are the only way to have non-probabilistic value in smart contracts.
J
00:36
Josh
Why do we need non-probabilistic value?
Z
00:36
Zack
any service that can't be provided at scale seems worthless in comparison to those that can.
00:37
all else held equal, having non-probabilistic smart contracts would be preferable, because then it would be impossible for you to ever end up holding lottery risk.
00:38
and you wouldn't need to pay some specialist to buy up all your lottery tickets at the end of a sortition chain.
00:39
we would need to rewrite some light node tools before getting rid of state channels.
We don't want there to be a period of time when p2p derivatives aren't possible.
J
00:51
Josh
In reply to this message
Sortition chains are new and the markets for this don't exist yet but it should be pretty easy to set up lottery buying markets and in the beginning it will be especially profitable.
00:52
I think the wallets should be more sophisticated and automatically roll over lottery risk. This makes it harder to develop wallets but ultimately it's very scalable and gives each use control over how they want to manage it.
00:53
But I don't think we need two mechanisms, either sortition chains will work well or they won't and we need to think of another way.
Z
00:53
Zack
you need to come online to roll-over into a new sortition chain. It requires some signatures.
But besides that, we should be able to do it in the background.

Maybe you need to have some white list of validators, and your wallet will only move your value into sortition chains where at least one of the validators is in your white list.
J
00:59
Josh
If all the validators sign a bad merkle root, everybody will know about it and they'll need to go into panic mode. They should be able to set up hedging bets on a different sortition chain.
Z
01:05
Zack
if all the validators work together to attack, they can freeze all the money and force us all to hold lottery risk.

It isn't usually possible to hedge lottery risk. Only in very extreme cases.

Like, if you have a lottery ticket that has a 0.1% chance of being worth $1000, it's total value is $1.

To hedge this, you would need to be able to give up ~$999 of something in the case that you win the lottery.
So you would need to lock $999 in a different sortition chain to hedge the risk of the $1.

If a sortition chain has N users who all want to hedge this way, the amount of liquidity they would need to all hedge is (amount of money in the pot for the first lottery)*N
And in most cases, there isn't enough VEO in all of Amoveo for that.
01:06
locking up $999 to get rid of $1 of lottery risk, it is not cost effective.
01:07
if you own 1/2 the value in a small sortition chain, then hedging this way would be feasible.
J
01:07
Josh
Good point
01:08
There are problems with whitelisting. If I'm a regular guy and I want to download a wallet and get started, which validators should I trust?
01:09
Wallets might start including trusted validators in their defaults and that's pretty dangerous.
Z
01:09
Zack
you also need to choose who to download the wallet from.
There could be a default white list inside the wallet software. So as long as you are able to get a good version of the wallet, you are fine.
01:10
choosing where to download a wallet from is already a situation that involves trust.
01:10
the wallet software could be a honey pot that sends your private key to a hacker.

Unless you do everything with cold storage.
01:13
the nash equilibrium is that none of the validators will freeze money, because it is not profitable for them to do that.
J
01:22
Josh
the problem isn't that the wallet developers are trying to cheat you, it's that the validators that get themselves in lots of wallets become hard to replace which a centralization risk.
Z
01:29
Zack
it takes 2 seconds for a wallet developer to remove a validator from the default list.
01:32
there is no cost to deciding not to include a particular validator in the default list, and there is a big cost if one of the validators in your list decides to harm users of your wallet.
If a wallet developer even suspects that you might cause problems for users, he would immediately remove you from the default list and release an update.
J
01:34
Josh
it can take years for users to update their software
01:36
the wallet user won't suspect that the validator will cause problems because they probably never will, but there will still be a few famous validators in the wallet whitelists. those validators could come under regulatory pressure.
01:36
since they're in the big wallets, everyone will want to include them in their sortition chains so that the chains will be accepted by everyone.
Z
01:43
Zack
the wallet can look at merkle proofs from recent blocks to know which of the whitelisted pubkeys are regularly paying to have signed merkle roots published to the blockchain.
It can require a certain fraction of the entire whitelist to be participating, otherwise it needs manual intervention.

People don't put all their money into derivatives at the same time.
If their money is going into a sortition chain, they are accepting the risk that the money could get frozen for a couple weeks. If they haven't updated recently enough.

It is like being forced to hold veo for 2 weeks. It is not a big cost. The veo could even increase in value during that time.
You can update, and then use some other money to make the contract that you wanted.
01:44
the wallet could also check github if there is any update, and demand that you update. It could grey out all the interfaces so you can't type info, and have a big red explanation saying how to update.
01:45
I think there could even be ways to auto-update, but I don't know how.
01:46
Another option, if we all know that there are certain bad actors who were once validators and are now abusing the fact that they are on whitelists.
We can do a hard update, and add that validator's pubkey to a blacklist, so it can not be a validator for any new sortition chain.
01:47
futarchy allows for us to make the decision to do hard updates like that, without trusting any centralized decision maker.
01:48
In reply to this message
oh, I guess this isn't compatible with the sortition chain's recursive nature.
We can't prevent the inner layers from using the bad validator.
J
01:55
Josh
In reply to this message
the biggest problem isn't frozen funds it's lottery risk and that doesn't seem to have a solution, you'll probably lose your money if that happens.
Z
01:55
Zack
it only happens if all N of N validators are working together to make it happen.
J
01:55
Josh
In reply to this message
actually it should be easy for wallets to auto-update since they're just updating a tiny list, not the whole application.
Z
01:55
Zack
and they don't profit from this.
J
01:56
Josh
but the problem is that even if these validators will never do anything bad, they're gaining a valuable reputation. it's hard to replace them because their replacement would have to get into the wallets that people are using.
Z
01:56
Zack
trusting a centralized source to give you data on who to blacklist is a lower form of trust. the central power can't cause much damage by abusing this power.
J
01:57
Josh
In reply to this message
right but how do i know all N aren't the same entity?
Z
01:58
Zack
like, if the wallet provider wanted to freeze all his customers simultaneously, and force them all to have lottery risk?
01:59
I guess that wallet would become less popular than other wallets.
01:59
as soon as the wallet provider is abusing his customers
01:59
it is also a specialized skill, running efficient validator software on a well connected machine
02:00
a very different skill from writing and maintaining wallet software.
02:01
customers will gravitate towards the best product. made by the best wallet developers, and using the cheapest, highest-throughput validators.
Z
02:28
Zack
here is an attack we haven't looked at enough.
The N validators work together to freeze your money.
Then, during the final_spend_tx period, they offer to sell you a merkle proof which would let you make a final-spend-tx to get your money out so you don't need to hold lottery risk.
02:31
hey, even if all N validators wanted to freeze your money, I think they cannot prevent you from using the final-spend-tx to exit and not hold lottery risk.
02:31
why did we think it mattered before?
MF
02:35
Mr Flintstone
can you presign a waiver selling your potential claim to the probability space for 99% of its value?
02:35
until its worth 99% nobody will take the trade, but after that they would
02:35
not sure if there are double spending considerations in the current design tho for this
Z
02:36
Zack
If N of N doesn't matter, then I think we should just have 1 validator per sortition chain
MF
02:37
Mr Flintstone
In reply to this message
this way you wouldnt have to come online again to lose the lottery risk
Z
02:38
Zack
In reply to this message
you could set up a free option with arbitrage-sales-person who then finds someone to take the other side of the trade.
MF
02:38
Mr Flintstone
cant you just post it on twitter
02:38
the 1% spread itself will pay ppl to look into it
Z
02:41
Zack
the way atomic swaps usually work is that I lock something up, you lock something up, and then I reveal a secret to simultaneously cause the exchange.
02:41
I guess I could lock something up and then go offline.
You could lock something up and then go offline.
And when I finally come online again, I can activate the swap. oh, but I would have needed to put your pubkey into it from the first time I locked.
02:42
I think it is at least a 3-message handshake. I am not certain.
02:43
Alice - Bob
- pubkey ->
Bob locks funds to give to that pubkey.
< - pubkey -
alice locks funds to give to that pubkey
- evidence of locked funds ->
<- Secret -

looks like a 4- message handshake.
02:44
In reply to this message
but we can create the user experience you are looking for, trustlessly, if we involve a sales specialist who stays online to facilitate the trade while you are offline.
Spike Spiegel invited Spike Spiegel
SS
03:33
Spike Spiegel
Hello again
Z
03:37
Zack
In reply to this message
haha. there are so many bad oracle mechanisms. hopefully people are starting to learn
03:37
In reply to this message
1 validator per sortition chain would be nice. It would simplify a lot of things.
J
03:38
Josh
In reply to this message
That's huge, that means there's no lottery risk at all in sortition chains
Z
03:39
Zack
maybe there is something we are forgetting? Why did we think that before?
J
03:40
Josh
I was wondering about it but I was going by the docs, I didn't understand that part well enough.
P
04:27
PIP
In reply to this message
Do i read it right around 67k coins?
Z
04:43
Zack
In reply to this message
Yes, there are about that many
EA
07:48
Some in here might appreciate what Gnosis launched today, pretty slick
Z
10:22
Zack
In reply to this message
I still can't find a reason we had N validators instead of just 1.
Z
10:53
Zack
I reviewed some old conversations from around the time when that design choice was made.
Still isn't clear.
I can't find anything in the docs explaining why we did it that way.
It really seems like 1 validator per sortition chain will work fine.
s
12:36
sanket
In reply to this message
this is really cool. The volume also seems ok
s
13:28
sanket
I tried this, the interface is really simple for anyone to understand.
13:29
This could be a good case study for us on how probably we can built pm on amoveo, which people can use.
S
14:28
Sy
stupid vip i got rich spam scam...i guess those exist in every country - we got plenty of this with local vips aswell even on facebook
J
17:51
Josh
In reply to this message
Wasn't it because of the assumption that a bad root could lead to lottery risk?
17:59
In reply to this message
I asked about it here
B
18:40
Ben
@Zack I’m creating a graphical representation of sortition chains and noticed there are some loosely defined terms on https://github.com/zack-bitcoin/amoveo-docs/blob/master//design/sortition_chains.md that could be more clearly defined to help in this process. It goes from 3rd person to first person as well in a confusing way.

Things get a bit confusing starting here: “The commiters commit the merkel roots of 2 trees.”

Are these commiters the Sortition Chain Operators? Are those operators each individually committing the merkel roots of 2-trees, as in, each operator seperately? (And is that on-chain or offchain)?

And by committing, do you literally mean they are broadcasting those roots inside of a signed transaction?

Next question: “The first tree divides up the probabilistic value space between the different people who own it.”

Are the people who own it that you specify here the explicit owners of lottery tickets, which they received in exchange for the funds they put into the Sortition Chain?

Next: “The location in the tree is determined by which RNG values would result in your winning.”
Here you go to 1st person for the first time in this write-up. Someone is winning, but someone else is losing. Who is “your” here? And when it says the location in the tree is determined by which RNG values, does this simply mean, there is a tree that has branches/leaves and one of the leaves is the winning ticket, and the RNG determines the leaf that won?
18:41
@jmharvey if you know the answers to any of these, feel free.
J
18:44
Josh
In reply to this message
I think these are the validators and they do push an on-chain transaction with the merkle roots.
B
18:45
Ben
that was my assumption as well @jmharvey . I’m also wondering though is if those validators/operators sign a multi-sig transaction and its broadcast by one of them, or if each of them push on-chain their own version of the event and if N-of-N agree, its considered valid…
J
18:46
Josh
You can own part of the sortition chain by either creating it with your own funds or by having an existing owner sign a message saying you should be next in the queue.
B
18:47
Ben
Okay, so in that sense, if I contributed 10 VEO to a 30 VEO sortition chain, I could assign 5 VEO of that to you (since tickets are divisible) and now you would own 5/30 => 1/6th of the probabalistic space?
J
18:48
Josh
In reply to this message
I'd have to look at the code but it looks like we might not need N validators anyway, so that might go away.
18:48
In reply to this message
Yeah, you add me next in line and then send me a waiver.
18:50
“The location in the tree is determined by which RNG values would result in your winning.” -- Your ticket corresponds to a subrange of the probability space. If the RNG value is within that subrange (and your smart contract returns true) you win.
B
18:53
Ben
If Alice contributed 10 VEO of 40 in the chain, Alice would receive tickets equivalent to a 25% subrange of the probabalistic space ?
Z
18:55
Zack
In reply to this message
There is only the one tree now. Not 2.
The rng selects the winning lottery ticket. Only the winner can claim their winnings.if you won, then you would claim your winnings. If someone else won, they would claim it.
B
18:55
Ben
Then the documentation is outdated?
J
18:55
Josh
She wouldn't contribute 10 of 40, the original owner of the chain (call him Bob) would grant her 10. If the probabily space was from 0 to 40, and the RNG number came up as 8, she would win the whole 40 VEO.
B
18:56
Ben
@jmharvey is there only one original owner then? In the sense, someone creates a sortition chain, then grants probability space to each participant?
Z
18:56
Zack
In reply to this message
Anyone can own lottery tickets in a sortition chain.
Anyone with lottery tickets, they are recorded in the sortition ownership tree.
B
18:57
Ben
Zack when it says tickets are divisible, can I divide a ticket I purchased, and give a portion of my tickets to you?
Z
18:57
Zack
In reply to this message
Yes. Committing means a sortition-block-tx where they put a signed merkle root on-chain.
B
18:58
Ben
In reply to this message
Do they each individually put a signed merkle root on-chain? Meaning if there is 10 Validators, you get 10 distinct transactions?
Z
18:58
Zack
In reply to this message
It is a single sortition-block-tx that contains all their signatures.
18:59
In reply to this message
Yes.
B
18:59
Ben
Who broadcasts it? How is it determined that they have all signed it for broadcast?
Z
19:00
Zack
In reply to this message
Right.
Unless she is owning stable bitcoin or some other smart contract.