Amoveo ♥🧿
Previous messages
Next messages
31 December 2019
K
09:11
K
Am I able to create bets using payment channels?
09:12
Do you know if exante’s wallet does it via on chain transactions or LN?
Z
09:37
Zack
I'm not sure if exantech wallet supports this.
We have been updating the wallet I maintain, the process for making bets is simpler now.
We have been updating the wallet I maintain, the process for making bets is simpler now.
Peter invited Peter
1 January 2020
Z
02:43
Zack
I am thinking of writing an article about the airstrikes that the US military uses so frequently.
We should use futarchy to find out how effective these airstrikes are at protecting US citizens.
They cost like $1.4 million per missile, so it would be nice to know if this is money could be better used for something else.
We should use futarchy to find out how effective these airstrikes are at protecting US citizens.
They cost like $1.4 million per missile, so it would be nice to know if this is money could be better used for something else.
A
02:44
Aries
No 80,000
02:45
You mean Tomahawk or Hellfire?
Z
02:46
Zack
i don't know much about weapons.
A
02:46
Aries
Tomahawk around 1.8 million
02:47
Hellfire on predatory or reapers
02:47
70 to 80k
Z
02:47
Zack
I guess the drones that drop the bombs are pretty expensive as well
A
02:49
Aries
Predators are around 4.03 million
02:50
Cheap enough that the cia will crash them in order to have eyes on anyone who is high priority
02:50
Instead of going back to refuel
Z
02:56
Zack
I think it would be good to include a few facts in the article to give an idea of how much money is being spent on war
02:58
and also some facts to give an idea of how confident we are about how effective this money is at making US citizens safer.
03:06
looks like there is an arbitrage opportunity between some exchanges.
Maybe this New Years will happen similar to last year.
Maybe this New Years will happen similar to last year.
I
MF
03:26
Mr Flintstone
ya I would say 195 vs 50 is a small arb opp
S
2 January 2020
S
01:32
Sy
Still wondering why nobody is trading there, registering that hard?
Z
01:33
Zack
Last I checked they wanted like $10k deposit to open an account
S
01:50
Sy
Not that much for some of the bigger holders tbh...
01:51
Can't find it on their page tho...
I
S
02:34
Sy
Ah k but you can spend it afterwards?
I
S
03:10
Sy
Gotta read up on that exchange...
TG
08:41
Toby Ganger
interesting that coin paprika removed gozo from the amoveo markets
Z
08:45
Zack
Oh yeah, it's gone now
Deleted invited Deleted Account
mx
12:52
mr x
Link to light node on github not working.
Z
3 January 2020
S
01:57
Sy
In reply to this message
They did? Maybe auto remove duo restricted access and stupid spread? It was listed when I last wrote
MF
02:18
Mr Flintstone
it’s disappeared and reappeared multiple times before
02:18
could be an api issue as well
02:21
one exciting thing that is being looked into is if it is possible and tractable to partially match channel offers. so you could put an offer out for 10 veo, and someone can match any amount of it instead of being required to match the full 10.
mx
13:37
mr x
could then have more orderbook like ui?
Ziad Mo invited Ziad Mo
S
20:38
Sy
im still unsure if gozo is real or fake...is there any intel on them?
I
22:43
Instinct
In reply to this message
They’re connected with exante, seems like the crypto trading branch of them
MF
23:37
Mr Flintstone
would be nice to understand the strange behavior lol
4 January 2020
Alex Tchandalito invited Alex Tchandalito
5 January 2020
Deleted invited Deleted Account
S
19:50
Sy
19:50
interesting orders at gozo 😅
19:51
but someone just bought everything up to 200
19:51
well "just" isnt exactly right, it was last day of 2019
M
20:26
Minieep21
How have they been open for so long yet there is still very little info?
I
6 January 2020
S
00:37
Sy
I mean 50 buy 185 sell...that's some serious spread 😁
00:39
In reply to this message
You have to fully verify to start trading, that's not so popular in crypto I guess
00:39
Plus 10k first deposit
Z
CD
02:32
Crypt Dweller
Zack, what are you working on these days?
Š
02:34
Šea
He's trying to make the best recipe to cook the eggs. Thats why he's less responsive here these days
02:34
I believe we could have updates soon
I
K
03:56
K
How important is privacy for Amoveo?
03:56
Do you think Amoveo can function just fine with a fully public chain as it has right now?
Z
04:22
Zack
In reply to this message
There is a lot of controversy about blockchain privacy. Here is my perspective. https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/privacy.md
Privacy and scalability are the same thing. All that research we did in sortition chains isn't just the best known solution for scalability, it is also the best privacy solution.
Privacy and scalability are the same thing. All that research we did in sortition chains isn't just the best known solution for scalability, it is also the best privacy solution.
K
04:31
K
In reply to this message
So you believe that there is only such thing as delayed privacy on a blockchain?
04:36
If the best way to achieve privacy is by spending coins to yourself a bunch of times, likely using a mixer or some sort, then over time as tech increases and on-chain analysis techniques increases all transactions will be revealed
04:36
the more $ you spend, the longer you have until yours is broken
Z
04:37
Zack
In reply to this message
I don't work much around the winter solstice.
Today is my birthday.
I have been doing a little research into tradeoffs of different erlang data structures. I have been reviewing my family's finances.
This is a time when I try to step back, and make big picture strategy plans for the coming year.
Code should start getting written more quickly around January 15.
Today is my birthday.
I have been doing a little research into tradeoffs of different erlang data structures. I have been reviewing my family's finances.
This is a time when I try to step back, and make big picture strategy plans for the coming year.
Code should start getting written more quickly around January 15.
04:40
In reply to this message
Spending coins to yourself and using a mixer are 2 different privacy strategies.
The idea that on-chain analysis techniques will someday reveal everything is not the correct way to think about this.
If information is actually private, then it is provably impossible to uncover with any kind of analysis.
Paul sztorc has written some great stuff on this topic. He is a better writer than me.
The idea that on-chain analysis techniques will someday reveal everything is not the correct way to think about this.
If information is actually private, then it is provably impossible to uncover with any kind of analysis.
Paul sztorc has written some great stuff on this topic. He is a better writer than me.
04:43
https://twitter.com/Truthcoin/status/1202337024335843329?s=19 here is a twitter thread where you can see Paul sztorc and some zcash people debating about the nature of privacy on the blockchain.
EA
05:30
Eric Arsenault
Happy birthday Zack 🥳
B
07:10
Beer
Happy bd 👾
I
07:28
Instinct
🎉
T
08:21
Tromp
Feliz cumpleaños amigo!
S
08:54
Sy
In reply to this message
happy bday...damn itrs past midnight over here so i missed 😅
anyway, you are almost 10 years younger than me 😱
anyway, you are almost 10 years younger than me 😱
OK
09:21
O K
Happy birthday Zack!
ES
12:01
Ed Sonic
Happy Birthday Zack!
mx
12:18
mr x
HBD
B
15:37
Ben
HBD
EW
16:03
Eli W
Hbd
A
16:03
Aries
Happy Birthday Zack
w
16:11
wvvw
Happy Birthday Zack. I wish you much health and happiness ❤️🍀
N
16:27
NM$L
Happy Birthday Zack. I wish you much health and happiness ❤️🍀
7 January 2020
Z
01:36
Zack
Thanks for the well wishes.
This is going to be a good year.
This is going to be a good year.
АК
01:38
Алексей Колосов
С днюхой !! Zack
Deleted invited Deleted Account
Fabien invited Fabien
F
03:15
Fabien
Hi
Chris 🍞 invited Chris 🍞
C
04:31
I've been reminded by myself that i still need to close a DAC(?) for funding of someone
04:32
for myveowallet.com
04:32
if the dev can contact me i can transfer the funds that are still locked in the dac
CD
04:43
Crypt Dweller
Hey happy birthday Zack. You deserve some time off. Best wishes to you and your family.
C
14:13
Callum Wright
Happy birthday Zack!
14:14
On another note, I'm just thinking whether we can publish an article about Amoveo, its mission as well as sortion chain concepts on nakamoto.com
OK
8 January 2020
T
08:35
Topab
Reading this prediction makes me think that stable coins and derivatives are a real use case for crypto. It feels projects of such nature want to emerge but the underlying tech is not suitable. That seems to be the case for ethereum. This gives me hope for Amoveo. My worry is Amoveo adoption and development speeds are kind of slow.
Z
23:14
Zack
Someone from bitfare exchange says that they listed amoveo.
If anyone tries it out, tell us if it works.
If anyone tries it out, tell us if it works.
9 January 2020
S
00:09
Sy
00:09
looks like they really did
Z
00:10
Zack
Has anyone used this exchange? Are they reliable? Should I add them to the recommended list?
S
00:44
Sy
no idea
00:44
LOCATION: 32 Woburn Place London England WC1H 0JR
00:44
at least not the cayman islands or something like that ^^
Z
00:46
Zack
I think you don't need to be located in a country to set up a company there.
It could be a post office box where they are able to receive mail.
It could be a post office box where they are able to receive mail.
S
00:46
Sy
True but its still different laws, many companies in the EU formed as Ltd in UK since you dont need much capital...well not anymore, bb UK
J
00:47
Jed
they are also Located in Estonia
S
00:48
Sy
no veo trades on gozo since the new years 200$ run...odd
MF
01:29
Mr Flintstone
seems like someone was trying to make their 2019 performance look better
Z
01:38
Does this new years price spike happen to any other small cryptocurrency projects?
M
S
01:41
Sy
Yep
MF
01:44
Mr Flintstone
exact same thing happened 2018 to 2019 New Years on their charts for veo
S
02:11
Sy
Lol
02:11
It might actually work to fool some clients
MF
02:12
Mr Flintstone
yeah if they have horrific operational diligence wrt pricing best practices / or are just being lied to
M
S
02:58
Sy
Their portfolio is in veo, they want their annual balance and voila, veo is at 200
02:58
But maybe it's much simpler and just random, who knows 😁
02:58
But 8 days no trade is odd tbh
X
Z
05:56
Zack
Ok, I won't list them yet.
But if they do a good job, I will.
But if they do a good job, I will.
X
05:57
X | NPC
They have some isues with pegnet lately
Z
06:00
Zack
This doesn't seem like very strong evidence to me.
X
Z
06:02
Zack
Yes.
X
06:04
X | NPC
Another one from the pegnet discord:
Suspected Exchange Scam at BitFare.io @everyone
1 Million PEG taken, NOT 53 Million PEG.
Looking into the claims around an exchange scam <@!417824355385344052> did some good research and determined that BitFare.io is very likely to be a scam. You can see his detailed analysis on Twitter: https://twitter.com/niels_klomp/status/1211835230631452674?s=20
TLDR: Two community members have reported their deposits of PEG being taken when deposited at BitFare.io The PEG was immediately transferred and then sold via a different (legit) exchange, as can be seen on the pExplorer. These lost deposits total around 1 Million PEG.
Importantly the address people were tracing the PEG transfers to, is NOT involved in BitFare.io and belongs to a known exchange and therefore the 53 Million at that address are in that legit exchange's cold storage.
The 53 Million PEG is NOT being held by a scammer.
PLEASE BE CAREFUL WHEN USING ANY NEW EXCHANGE.
One good method is to quickly check the reputation of an exchange on Coin Gecko: https://www.coingecko.com/en/exchanges
Suspected Exchange Scam at BitFare.io @everyone
1 Million PEG taken, NOT 53 Million PEG.
Looking into the claims around an exchange scam <@!417824355385344052> did some good research and determined that BitFare.io is very likely to be a scam. You can see his detailed analysis on Twitter: https://twitter.com/niels_klomp/status/1211835230631452674?s=20
TLDR: Two community members have reported their deposits of PEG being taken when deposited at BitFare.io The PEG was immediately transferred and then sold via a different (legit) exchange, as can be seen on the pExplorer. These lost deposits total around 1 Million PEG.
Importantly the address people were tracing the PEG transfers to, is NOT involved in BitFare.io and belongs to a known exchange and therefore the 53 Million at that address are in that legit exchange's cold storage.
The 53 Million PEG is NOT being held by a scammer.
PLEASE BE CAREFUL WHEN USING ANY NEW EXCHANGE.
One good method is to quickly check the reputation of an exchange on Coin Gecko: https://www.coingecko.com/en/exchanges
Z
06:09
Zack
If you trade, then you should be careful.
X
06:11
X | NPC
Sure, just sharing info
10 January 2020
Z
14:09
Zack
In reply to this message
I looked into this idea more. I made a github issue for this topic. So we can continue the discussion there.
https://github.com/zack-bitcoin/amoveo/issues/269
I think that sortition chains would make this upgrade obsolete, so it seems like it would be better to just focus on sortition chains and not waste time on this upgrade.
https://github.com/zack-bitcoin/amoveo/issues/269
I think that sortition chains would make this upgrade obsolete, so it seems like it would be better to just focus on sortition chains and not waste time on this upgrade.
Z
14:55
Zack
https://github.com/zack-bitcoin/amoveo/blob/master/docs/use-cases-and-ideas/military_spending.md
I wrote about how we can use futarchy to find out what kinds of military spending are cost effective at making people safer.
I wrote about how we can use futarchy to find out what kinds of military spending are cost effective at making people safer.
Deleted invited Deleted Account
11 January 2020
Deleted invited Deleted Account
I
K
Z
03:50
Zack
There is a trading channel on discord. This place is not for trading.
13 January 2020
15:53
People from AVALabs talking about ur pos paper
Z
Z
19:41
Zack
Why did we want more than one validator per sortition chain? What is wrong with just having one?
19:44
Oh right. It is for availability attacks.
As long as 1 of n doesn't cheat, availability attacks are prevented.
Otherwise your money can get frozen and you don't get that one final chance to send it.
As long as 1 of n doesn't cheat, availability attacks are prevented.
Otherwise your money can get frozen and you don't get that one final chance to send it.
Deleted invited Deleted Account
14 January 2020
Z
22:33
Zack
we have so many branches on the amoveo github now. I am going to try to delete some.
22:39
im going to put the docs into a different github repository.
S
22:39
Sebsebzen
nice, remove the clutter
22:40
actually you could run a medium blog too
22:40
for these kinds of musings
Z
22:49
Zack
I think I might leave the current docs as-is for a while.
A lot of stuff links to them, and we might not want to break all those links yet.
A lot of stuff links to them, and we might not want to break all those links yet.
22:50
but I will update all the links we use to the new version.
22:50
and I can write "legacy docs, use the new version" on every page.
I
S
22:59
Sebsebzen
I actually enjoy Zacks oracle project comparison updates
22:59
Haha
Z
23:18
Zack
whats up with the branch called "legacy"?
No one is using that, right?
No one is using that, right?
23:18
I think that was when we updated to needing the new ubuntu version?
15 January 2020
K
00:13
K
Do you think amoveo governance will ever be binding?
Z
00:13
Zack
I gathered these notes about how to do hard updates that add an additional merkel tree to the blocks. https://github.com/zack-bitcoin/amoveo-docs/blob/master/checklists/new_merkel_tree_checklist.md
That way we didn't need to keep the sortition chain branch around.
That way we didn't need to keep the sortition chain branch around.
K
Z
10:01
Zack
Does anyone use non-default configuration options?
in particular, does anyone set db_version to 1?
I would like to drop support for the old version of storing blocks, because we could simplify the code.
in particular, does anyone set db_version to 1?
I would like to drop support for the old version of storing blocks, because we could simplify the code.
10:03
10:06
db_version 2 has the advantages:
* it uses far less space.
* you only write to disk once every few hundred blocks.
* you can read a contiguous range of blocks much faster.
db_version 1 has the advantages:
* you can look up any random individual older block faster.
* it uses far less space.
* you only write to disk once every few hundred blocks.
* you can read a contiguous range of blocks much faster.
db_version 1 has the advantages:
* you can look up any random individual older block faster.
11:35
Deleted Account
anyone else having troubles withdrawing from hitBTC? It's been weeks, tried support ticket and everything, still impossible to withdraw
Z
11:36
Zack
I heard hitbtc is having problems like that with a lot of currencies. I think we should not use their service.
11:38
Deleted Account
you are right but my VEO is there already, I'm sure many other people's veo as well
11:43
what's interesting is I think it's an easy issue to fix, but they won't do it. When I type in the withdraw address with the '=' at the end, the confirm email I receive has the address without the =. And then I click on the link, and it says error. Which makes sense in a way
Z
11:46
Zack
maybe they do errors like that on purpose so they don't have to give the veo back.
Deleted invited Deleted Account
Z
19:12
Zack
I want to make a checkpoint every 1000 blocks or so.
The checkpoint will keep a backup of the merkel trees from that point in time. This will allow us to sync blocks in reverse order.
But im running into an issue.
What if an attacker keeps re-mining block number 95000 for example?
would we need to save an additional checkpoint for every one?
until the block has enough confirmations, a full node is supposed to support history re-writes. So we need to be able to do checkpoint for any of the recent forks.
So I am thinking that instead of doing a checkpoint every 1000 blocks, we should check each block for whether
And if it is, that block should be a checkpoint.
So on average, there will be one block per 1000 blocks that is a checkpoint.
Does this strategy work?
What if miners refuse to publish any checkpoint blocks? It would only cost them 0.1% of their rewards.
I guess we would have to sync more blocks in the forwards instead of backwards direction, so it could take a few minutes longer to set up a new mining pool or anything that depends on a full node. But it would still be strictly better than syncing 100% of the blocks in the forwards direction.
The checkpoint will keep a backup of the merkel trees from that point in time. This will allow us to sync blocks in reverse order.
But im running into an issue.
What if an attacker keeps re-mining block number 95000 for example?
would we need to save an additional checkpoint for every one?
until the block has enough confirmations, a full node is supposed to support history re-writes. So we need to be able to do checkpoint for any of the recent forks.
So I am thinking that instead of doing a checkpoint every 1000 blocks, we should check each block for whether
(hash(header) % 1000) == 0 is true.And if it is, that block should be a checkpoint.
So on average, there will be one block per 1000 blocks that is a checkpoint.
Does this strategy work?
What if miners refuse to publish any checkpoint blocks? It would only cost them 0.1% of their rewards.
I guess we would have to sync more blocks in the forwards instead of backwards direction, so it could take a few minutes longer to set up a new mining pool or anything that depends on a full node. But it would still be strictly better than syncing 100% of the blocks in the forwards direction.
19:19
What if miners try to cause an excessive number of checkpoints to make it more expensive to run a full node?
If we store checkpoints that occurred in the most recent 2000 blocks, then on average we would expect to be storing 2 checkpoints.
If the miners throw out
But this means the miners are paying
So this attack isn't an issue.
If we store checkpoints that occurred in the most recent 2000 blocks, then on average we would expect to be storing 2 checkpoints.
If the miners throw out
(n-1) / n portion of their blocks, then they can increase the number of checkpoints we need to store to be 2*n.But this means the miners are paying
n times as much in order to find each block, which is cost prohibitive.So this attack isn't an issue.
19:23
What if at some point in the future, we have decided to make blocks at a much faster rate?
so instead of 1000 blocks per week, we have like 60000?
If we still want to store checkpoints for the last month, and if we are storing on average one checkpoint per 1000 blocks, then this means the total memory requirement of the checkpoints would be 60x higher.
So this makes me think that the rule for which blocks are checkpoints needs to be connected to the governance variable that controls the block time.
If the block time is reduced by a factor of 2, then we need to reduce the frequency of the checkpoints by a factor of 2.
so instead of 1000 blocks per week, we have like 60000?
If we still want to store checkpoints for the last month, and if we are storing on average one checkpoint per 1000 blocks, then this means the total memory requirement of the checkpoints would be 60x higher.
So this makes me think that the rule for which blocks are checkpoints needs to be connected to the governance variable that controls the block time.
If the block time is reduced by a factor of 2, then we need to reduce the frequency of the checkpoints by a factor of 2.
Z
19:56
Zack
I guess ill set it up so on average we have 2 checkpoints per month.
So on average, you only need to sync 2 weeks of blocks before the full node is usable, and on average a full node only needs to store less than 3 checkpoints at a time.
Currently each checkpoint will require 11 megabytes of data.
compare with 231 megabytes of blocks, and 24 megabytes of headers, and 11 megabytes of up-to-date merkel tree data.
So on average, you only need to sync 2 weeks of blocks before the full node is usable, and on average a full node only needs to store less than 3 checkpoints at a time.
Currently each checkpoint will require 11 megabytes of data.
compare with 231 megabytes of blocks, and 24 megabytes of headers, and 11 megabytes of up-to-date merkel tree data.
19:58
I think we can optimize this to the point that it takes less than 30 seconds for a new full node to be ready for mining or checking your balance or whatever you need.
20:00
we could set up a configuration variable so you don't have to sync all the historical blocks if you don't need them.
If you only sync the 1 month of blocks necessary for the checkpoints, then you would only download 4k blocks instead of 98k blocks.
If you only sync the 1 month of blocks necessary for the checkpoints, then you would only download 4k blocks instead of 98k blocks.
20:05
is 1 month ideal?
what attack exactly are we worried about?
What if we only stored checkpoints for the last week, or last day?
what attack exactly are we worried about?
What if we only stored checkpoints for the last week, or last day?
20:07
I guess the configuration value "fork_tolerance" would need to be set to less than the number of blocks until the checkpoint.
So if someone wanted a fork tolerance of 2000 blocks, then we would need some checkpoint from more than 2000 blocks ago.
So if someone wanted a fork tolerance of 2000 blocks, then we would need some checkpoint from more than 2000 blocks ago.
20:07
currently, the default fork tolerance is 50 blocks, which is like 8 hours.
20:09
if more than 50 blocks of history got rewritten, it would cause all the nodes with default configurations to crash.
20:16
if more than 1 days of blocks got undone, that seems like a pretty huge disaster. Some big double-spending could get done in 1 day.
So maybe 1 day's worth of blocks is the furthest back we need a checkpoint to be.
So maybe 1 day's worth of blocks is the furthest back we need a checkpoint to be.
20:17
needing to sync 144 blocks would be a lot faster than needing to sync 4000.
Z
21:00
Zack
One option is to maintain at least 2 checkpoints.
One that is 12 hours ago, and another that is 1 month ago.
So if there is a fork longer than 12 hours, you only need to sync 1 month of blocks.
One that is 12 hours ago, and another that is 1 month ago.
So if there is a fork longer than 12 hours, you only need to sync 1 month of blocks.
21:01
But that is a little complicated.
Maybe it is better to start with a simple solution, and upgrade it later if we need it.
Maybe it is better to start with a simple solution, and upgrade it later if we need it.
S
OK
21:30
O K
👍
Z
21:55
Zack
Ok, thanks guys
16 January 2020
Z
09:29
Zack
https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/src/checkpoint.erl
I made a module for checkpoints.
It stores on average one checkpoint per 1000 blocks, and on average it is storing 2 checkpoints at a time.
I haven't activated it yet.
I made a module for checkpoints.
It stores on average one checkpoint per 1000 blocks, and on average it is storing 2 checkpoints at a time.
I haven't activated it yet.
09:34
what if every node could choose different blocks to use as checkpoints?
09:36
it seems like it doesn't matter if the checkpoint you are syncing with is the same as one of the checkpoints that you store.
Deleted invited Deleted Account
20:28
Deleted Account
Any staff available to chat?
[
20:39
Deleted Account
So not really? Lol
[
20:40
[Riki]
Can check with chief of canteen if he is available too
ŽM
21:12
Živojin Mirić
hello, I am responding to the call of duty
21:12
how may I be of service to you kind sir?
21:13
please be quick, pork bellies will burn up in the oven
S
Z
21:58
Zack
In reply to this message
Are they still using dai? I wrote about why dai doesn't work.
It is good they are allowing for betting on "bad question".
That is an important feature.
They are still using a votecoin based oracle, so it is not scalable and it is cost prohibitive vs Amoveo's design.
It is good they are allowing for betting on "bad question".
That is an important feature.
They are still using a votecoin based oracle, so it is not scalable and it is cost prohibitive vs Amoveo's design.
S
22:54
Sebsebzen
Yes, DAI based. I guess we'll see when it's released.
22:54
The UI looks good tho, maybe something worth emulating
22:55
Would be nice to see Amoveo in the top50 at CMC someday 🙂
Deleted invited Deleted Account
Rafael B. invited Rafael B.
17 January 2020
Z
07:56
Zack
Amoveo has had some updates that made block syncing faster, but they were hard updates. So only the recent blocks are faster.
by syncing blocks in reverse order we can overcome the mistakes of our past, and feel the full effect of speed improvements immediately.
by syncing blocks in reverse order we can overcome the mistakes of our past, and feel the full effect of speed improvements immediately.
08:01
If we can sync blocks in reverse order, then a full node can be practically as light as a light node.
Just tell it not to sync the historical blocks.
Just tell it not to sync the historical blocks.
08:11
Looks like the 3.5 megabytes of trie databases can get compressed into a 0.6 megabyte checkpoint.
Z
08:27
Zack
Has any other blockchain enabled backwards syncing yet?
08:28
I set up this server to host checkpoints. 46.101.185.98
08:31
I think I heard about the backwards syncing idea in 2015 from Vlad Zamfir.
You would have thought that someone would have built it by now.
I guess a prerequisite is having a stateless full node, and Amoveo might be the only blockchain with stateless full nodes.
You would have thought that someone would have built it by now.
I guess a prerequisite is having a stateless full node, and Amoveo might be the only blockchain with stateless full nodes.
Z
12:08
Zack
I think once backwards syncing is working, an amoveo full node should be completely usable within 1 minute of turning it on.
and installing amoveo with dependencies on a new machine can probably be done in less than a minute.
and installing amoveo with dependencies on a new machine can probably be done in less than a minute.
Deleted joined group by link from Group
Z
18:15
Zack
a sortition chain will probably only last like 4000 or 8000 blocks.
So if you sync backwards, you only need to sync the most recent 4000 or 8000 blocks, and you can know everything about the sortition chains currently in use.
So if you sync backwards, you only need to sync the most recent 4000 or 8000 blocks, and you can know everything about the sortition chains currently in use.
ŽM
18:25
Živojin Mirić
this is great
Ntin Ang invited Ntin Ang
18 January 2020
Z
07:36
Zack
The checkpoint we were looking at before included merkel trees for the most recent 200-800 blocks, depending on the settings of who you got them from, and how many txs were in those blocks.
So I wrote an update for the merkel tree library. If you only care about a single merkel root, it can delete everything else from that checkpoint.
Syncing in reverse will completely remove any data leaks that accumulated while syncing the 100k blocks.
So I wrote an update for the merkel tree library. If you only care about a single merkel root, it can delete everything else from that checkpoint.
Syncing in reverse will completely remove any data leaks that accumulated while syncing the 100k blocks.
Z
07:56
Zack
I set it up so when you are doing a checkpoint, it verifies all the merkel proofs for all parts of the merkel tree in the checkpoint.
Pjmora28 invited Pjmora28
P
10:28
Pjmora28
Hello, what is the total suply?
Z
10:31
Zack
about 70 000 VEO.
P
10:33
Pjmora28
Max suply to?
Z
10:34
Zack
Amoveo has a governance system, we can't predict the max supply.
10:34
the governance system might raise or lower the block reward this month.
P
10:34
Pjmora28
👍
ŽM
19 January 2020
Z
01:01
Zack
I am running into issues with the prev_hashes part of each block.
01:03
originally we had a way to looking any block in a given version of history.
Starting with block N, to find block M, it look log2(N-M) lookups of blocks.
block N stores log2(N) many hashes of previous blocks.
This strategy was not good because as the number of blocks grew, and the size of blocks grew, it became very expensive to look up random blocks this way.
Starting with block N, to find block M, it look log2(N-M) lookups of blocks.
block N stores log2(N) many hashes of previous blocks.
This strategy was not good because as the number of blocks grew, and the size of blocks grew, it became very expensive to look up random blocks this way.
01:06
as long as we are only using db_version 2 from now on, then we only use a tree structure for the recent 200 or so blocks. As long as forks aren't longer than 100 blocks, this works.
older blocks get stored in compressed pages containing hundreds of blocks per page.
So we are barely useing the prev_hashes at all any more.
older blocks get stored in compressed pages containing hundreds of blocks per page.
So we are barely useing the prev_hashes at all any more.
01:07
I think it will be even faster if we scan through the recent 100 headers, since they are all in ram. that way we don't have to do any unnecessary reads from the hard drive.
01:08
then we can get rid of prev_hashes entirely, which will make checkpointing a lot simpler as well.
Z
05:56
Zack
should store this prev-hashes data with the headers?
Do we ever want to query by height?
Do we ever want to query by height?
06:00
I think if we did want to query by height, it should be a new dedicated data structure. And not a hack on top of the headers process.
Z
14:28
Zack
I am able to sync the recent blocks between the checkpoint and the top, and then the node stays in sync like a normal node.
So the next step is to verify the rest of the blocks in reverse order back to the genesis, and give some command to look up how far backwards has been verified.
So the next step is to verify the rest of the blocks in reverse order back to the genesis, and give some command to look up how far backwards has been verified.
14:29
im probably going to come up with some better plan for syncing headers.
and we will need to run tests to make sure a full node can sync either forwards or backwards with an existing full node that was synced either forwards or backwards.
and we will need to run tests to make sure a full node can sync either forwards or backwards with an existing full node that was synced either forwards or backwards.
Z
14:46
Zack
the headers are pretty repetitive. maybe we can compress them before sending.
Z
20:14
Zack
It looks like syncing backwards will be a lot faster than forwards.
Going forwards there was one step that was synchronous. Maintaining the merkel trees had to be done one block at a time.
Writing the new batch of data to the RAM tree after processing each block.
But when we verify the blocks in reverse, we don't need to maintain any merkel trees, so everything is parallelizable.
Going forwards there was one step that was synchronous. Maintaining the merkel trees had to be done one block at a time.
Writing the new batch of data to the RAM tree after processing each block.
But when we verify the blocks in reverse, we don't need to maintain any merkel trees, so everything is parallelizable.
20 January 2020
Z
06:00
Zack
Im still working on syncing backwards.
I ran into an issue.
We need to calculate the merkel root of the consensus state after running all the txs.
But currently, the only way of doing that is by maintaining the long term merkel data structure that has everything in it.
so we need a way to gather up all the merkel proofs from a single block, and make them into a small merkel data structure that can be updated, and we can get the new root from it.
I ran into an issue.
We need to calculate the merkel root of the consensus state after running all the txs.
But currently, the only way of doing that is by maintaining the long term merkel data structure that has everything in it.
so we need a way to gather up all the merkel proofs from a single block, and make them into a small merkel data structure that can be updated, and we can get the new root from it.
Z
07:54
Zack
so, the way I am thinking of dealing with this.
The txs have a bunch of merkel proofs, and instead of making a tree, I am going to update these merkel proofs directly.
This is something we need to do anyway, if we want to have sharded mining pools that can include txs from other shards.
Once the merkel proofs are updated, each one will say the new merkel root on it, which is what we need.
The txs have a bunch of merkel proofs, and instead of making a tree, I am going to update these merkel proofs directly.
This is something we need to do anyway, if we want to have sharded mining pools that can include txs from other shards.
Once the merkel proofs are updated, each one will say the new merkel root on it, which is what we need.
07:55
maybe we need to upgrade the full node to allow a less repetitive format for the merkel proofs.
If they were gathered up into trees, we could operate over them more efficiently, and it would waste less space.
If they were gathered up into trees, we could operate over them more efficiently, and it would waste less space.
Z
08:40
Zack
https://github.com/zack-bitcoin/MerkleTrie/blob/master/src/verify.erl#L6
I made a tool for updating a merkel proof.
I made a tool for updating a merkel proof.
ŽM
C
17:56
Chris 🍞
In reply to this message
cuz he's been in blockchain longer then you have been out of diapers
Z
18:08
Zack
An advantage of syncing backwards is that it will make testing so much faster.
If we can spin up a fresh full node in only 2 minutes instead of 25+ minutes, then we can test new code out on the full node that much faster.
If we can spin up a fresh full node in only 2 minutes instead of 25+ minutes, then we can test new code out on the full node that much faster.
b
19:13
I have been reading about Erlang, Zack you are way ahead of many blockchains doing it with it.
One of many smart decisions you have taken.
One of many smart decisions you have taken.
Z
19:18
Zack
Erlang is a great language. Here is a recent video about it from a channel on YouTube that I enjoy https://youtu.be/SOqQVoVai6s
b
19:24
bitcoinsfacil - pedro
I am reading this free book recommendation you said > https://learnyousomeerlang.com/
Z
19:26
Zack
If we had to choose between a modern popular language built for highly scalable infrastructure protocols and massive development teams, vs an obscure language from the 80s built for connecting phone calls, guess which is better?
A
19:27
Advanced
Hei guys, hey zack! Just checking in after more than a year, I was mining and buying VEO ... what's current average price for 1 VEO?
Z
19:28
Zack
Qtrade seems to have the most honest price.
I think it was around $40 last I checked.
I think it was around $40 last I checked.
A
19:29
Advanced
thanks
JS
22:28
Jon Snow
In reply to this message
Which are the two languages? I guess Erlang is the one from 80’s built for connecting phone calls?
Z
22:31
Zack
In reply to this message
many languages fit that description: golang, rust, c#, swift, java
22:35
yes, erlang was designed and optimized for connecting analogue telephone calls.
21 January 2020
JS
00:17
Jon Snow
In reply to this message
Why didn’t Amoveo use a modern popular language built for highly scalable infrastructure protocols and massive development teams, but an obscure language from the 80s built for connecting phone calls?
B
00:29
Ben
good question ;)
b
00:49
bitcoinsfacil - pedro
Check Erlang please and then rephrase, it is really a great language for development on exactly this type of projects
Z
02:38
Zack
In reply to this message
Erlang is much better than modern popular languages.
Erlang is not the fastest. C/rust/golang/swift/java are faster. even javascript is faster now that there is asm.js
But in the context of blockchain, a faster language doesn't really matter. If we implement scaling correctly, then we can support trillions of users in parallel, even with a slow language.
Where erlang does win is in:
* a person can implement new features in erlang much faster than the popular languages. It is about as fast as Lisp for adding new features. Probably less than 1/10th as much work as popular languages.
* erlang has the best system for error handling I have seen, and it is the only system I have seen than still works well when doing parallel computation. This is a critical feature for catching unexpected bugs, and reducing the DOS attack surface area.
* every other language has parallelism thrown on top as a bonus feature after the language is already built. in Erlang parallelism was the primary goal. It is the only language I have used with sane tools for parallel computation. This is a critical feature for any protocol that has many simultaneous peers. It makes it easy for us to maintain large number of simultaneous channel relationships. It makes it easy to process blocks in parallel.
Erlang is not the fastest. C/rust/golang/swift/java are faster. even javascript is faster now that there is asm.js
But in the context of blockchain, a faster language doesn't really matter. If we implement scaling correctly, then we can support trillions of users in parallel, even with a slow language.
Where erlang does win is in:
* a person can implement new features in erlang much faster than the popular languages. It is about as fast as Lisp for adding new features. Probably less than 1/10th as much work as popular languages.
* erlang has the best system for error handling I have seen, and it is the only system I have seen than still works well when doing parallel computation. This is a critical feature for catching unexpected bugs, and reducing the DOS attack surface area.
* every other language has parallelism thrown on top as a bonus feature after the language is already built. in Erlang parallelism was the primary goal. It is the only language I have used with sane tools for parallel computation. This is a critical feature for any protocol that has many simultaneous peers. It makes it easy for us to maintain large number of simultaneous channel relationships. It makes it easy to process blocks in parallel.
Z
08:03
Zack
In reply to this message
I made a version that takes a list of merkel proofs, and updates, and returns all the new merkel proofs as they will look after all the updates are applied.
Cactus invited Cactus
C
21:56
Cactus
Hi everyone is anyone available from the team to take a message? Thanks in advance
22 January 2020
Deleted invited Deleted Account
Z
09:57
Zack
In reply to this message
im starting to think that updating merkel proofs in place is not a good strategy.
Most of the time it works fine, but the edge case of making a new stem 1/16th of the time makes it kind of complicated.
Most of the time it works fine, but the edge case of making a new stem 1/16th of the time makes it kind of complicated.
10:01
one option is to launch a new set of merkel tree processes for every block we are processing in parallel. That way garbage collection is trivial, we just drop the entire process.
And there is no race condition issues because each block being verified can have its own tree processes to store its own merkel trees.
Another option is to re-write the merkel tree operations for these small merkel trees, but instead of using ETS which requires a process to own it, we can use tuples and lists to build the trees.
garbage collection would be trivial, we can just drop the variable that is storing the merkel tree.
and there is no race condition issues, because each block can have its own variable to store its own merkel tree.
And there is no race condition issues because each block being verified can have its own tree processes to store its own merkel trees.
Another option is to re-write the merkel tree operations for these small merkel trees, but instead of using ETS which requires a process to own it, we can use tuples and lists to build the trees.
garbage collection would be trivial, we can just drop the variable that is storing the merkel tree.
and there is no race condition issues, because each block can have its own variable to store its own merkel tree.
10:03
I kind of like the idea of re-writing the merkel tree application so it doesn't have any processes, and it works like an erlang dictionary that you can just pass around to the process that needs it.
Z
10:56
Zack
Now that we are using the sortition chain scaling plan, that means we can keep the merkel trees in ram forever. they will never need to go on the hard drive.
So this means we don't need a separate process for managing our merkel trees.
It turns out you can use ETS in "public" mode, and then it can act like a dictionary, you can pass it between processes.
So I think I will make a new branch of the merkel tree. I will only support ram version, not hd.
I will stop using the dump dependency.
I will start by making tools for merkel trees, and then afterwards I will use those merkel tree tools to build the long-term database for the up to date consensus. So it will work in both ways.
So this means we don't need a separate process for managing our merkel trees.
It turns out you can use ETS in "public" mode, and then it can act like a dictionary, you can pass it between processes.
So I think I will make a new branch of the merkel tree. I will only support ram version, not hd.
I will stop using the dump dependency.
I will start by making tools for merkel trees, and then afterwards I will use those merkel tree tools to build the long-term database for the up to date consensus. So it will work in both ways.
23 January 2020
Alex invited Alex
A
02:58
Alex
Hi there
03:03
Have been quite impressed with this project - and Zach, to be honest.
03:04
Still working through some of the finer details regarding the technical logic and game theory that enables centralized trustless services
03:04
But impressed and engaged
A
05:14
Alex
Zack I havent been able to find a link to Amoveo's tokenomics. Is there one I am missing?
Z
05:23
Zack
hi Alex. thanks for your interest in Amoveo.
I am not sure what "tokenomics" means.
Amoveo has a governance system called "futarchy".
Futarchy is able to update aspects of Amoveo, like the block time and the block reward.
We can't predict what futarchy will set the block reward to in the future.
I am not sure what "tokenomics" means.
Amoveo has a governance system called "futarchy".
Futarchy is able to update aspects of Amoveo, like the block time and the block reward.
We can't predict what futarchy will set the block reward to in the future.
A
05:39
Alex
Understood, thank you. I mean the total supply on CMC is just under 70mm, but it would seem to me that there is no supply cap if PoW is ongoing
05:42
I suppose the term "token metrics" might be more appropriate here
Z
05:43
Zack
there might be a supply cap. there might not be.
We cannot predict what the governance system will set the block reward and block time to.
We cannot predict what the governance system will set the block reward and block time to.
A
05:44
Alex
Fair point, understood
C
J
16:42
JOHNwick3's dog
so, what are derivatives? its a bet right?
Could you use Amoveos oracles to make a bet in another coin? What potential does Amoveo bring to be interoperable with other coins? i'm brainstorming/tinkering with ideas that I don't fully understand yet.. trying to think about how to build dapps
Could you use Amoveos oracles to make a bet in another coin? What potential does Amoveo bring to be interoperable with other coins? i'm brainstorming/tinkering with ideas that I don't fully understand yet.. trying to think about how to build dapps
16:43
The best coin.. would be a fusion between successful coins..
Z
17:05
Zack
In reply to this message
>what are derivatives?
A financial derivative is the most basic financial instrument.
Primary colors are to colors what financial derivatives are to finance.
The same way you can combine the primary colors to produce all possible colors, you can combine financial derivatives to create any financial portfolio.
the chemical elements are to chemistry what financial derivatives are to finance.
The same way you can combine the chemical elements to produce all possible chemicals, you can combine financial derivatives to create any financial portfolio.
If you are a farmer who is growing orange fruit trees, there is a lot of risk for you if the price of orange fruits should drop before you are ready to harvest.
You could use a financial derivative to hedge this risk. That way you can lock in the current price of oranges, so when your oranges are ready you can sell them at the price you locked in.
Financial derivatives are older than written language. Financial derivatives are the most popular use-case of currency.
> could you use amoveo to bet on another coin?
you can use Amoveo to bet on the price of BTC. We can have BTC stablecoins on top of Amoveo.
>brainstorming
here are a bunch of use-cases of Amoveo to give you an idea of what is possible https://github.com/zack-bitcoin/amoveo/tree/master/docs/use-cases-and-ideas
>the best coin would be a fusion between successful coins.
When it comes to software tools, it seems like simple tools that do their job well end up more successful in comparison to tools that try to do too many different things.
I can't see any reason that a platform for financial derivatives could be improved by adding crypto-kitties, or subcurrencies, or DAO-voting-pools, or any of the other crazy finance experiments people have been doing lately.
Financial derivatives are popular today for the same reason they have been popular since prehistory, which is the same reason that they will be popular in the future. Financial derivatives are a scalable way to hedge risks.
They are scalable because their enforcement doesn't require any shared mutable state.
A financial derivative is the most basic financial instrument.
Primary colors are to colors what financial derivatives are to finance.
The same way you can combine the primary colors to produce all possible colors, you can combine financial derivatives to create any financial portfolio.
the chemical elements are to chemistry what financial derivatives are to finance.
The same way you can combine the chemical elements to produce all possible chemicals, you can combine financial derivatives to create any financial portfolio.
If you are a farmer who is growing orange fruit trees, there is a lot of risk for you if the price of orange fruits should drop before you are ready to harvest.
You could use a financial derivative to hedge this risk. That way you can lock in the current price of oranges, so when your oranges are ready you can sell them at the price you locked in.
Financial derivatives are older than written language. Financial derivatives are the most popular use-case of currency.
> could you use amoveo to bet on another coin?
you can use Amoveo to bet on the price of BTC. We can have BTC stablecoins on top of Amoveo.
>brainstorming
here are a bunch of use-cases of Amoveo to give you an idea of what is possible https://github.com/zack-bitcoin/amoveo/tree/master/docs/use-cases-and-ideas
>the best coin would be a fusion between successful coins.
When it comes to software tools, it seems like simple tools that do their job well end up more successful in comparison to tools that try to do too many different things.
I can't see any reason that a platform for financial derivatives could be improved by adding crypto-kitties, or subcurrencies, or DAO-voting-pools, or any of the other crazy finance experiments people have been doing lately.
Financial derivatives are popular today for the same reason they have been popular since prehistory, which is the same reason that they will be popular in the future. Financial derivatives are a scalable way to hedge risks.
They are scalable because their enforcement doesn't require any shared mutable state.
17:12
Computer programmers don't know enough about finance to know what a derivative is.
Finance people don't know enough about programming to realize why the lack of shared state is so important in the success of derivatives.
Finance people don't know enough about programming to realize why the lack of shared state is so important in the success of derivatives.
I
17:32
Instinct
Could a centralised exchange like qtrade list a Veo btc stablecoin?
B
17:35
Ben
no
17:36
at least it is not an easy thing
Z
17:37
Zack
In reply to this message
yes, and you have a lot of freedom to decide which parts to make trust-free.
there are already exchanges that allow you to buy leverage on bitcoin. That is a kind of financial derivative that is very trustful.
Amoveo markets for derivative contracts have a centralized untrusted hub to facilitate trading at the current market price. So a centralized exchange like qtrade could offer completely trust-free stablecoin contracts.
there are already exchanges that allow you to buy leverage on bitcoin. That is a kind of financial derivative that is very trustful.
Amoveo markets for derivative contracts have a centralized untrusted hub to facilitate trading at the current market price. So a centralized exchange like qtrade could offer completely trust-free stablecoin contracts.
B
17:37
Ben
contracts != stablecoin
Z
17:38
Zack
a stablecoin is one kind of derivative contract.
B
17:38
Ben
true, more a naming thing
17:39
but still i guess if the implementation would be easy, qtrade would have done it.
Z
17:39
Zack
there are also stablecoins built out of subcurrencies, like ERC-20 subcurrencies on Ethereum.
They are not derivatives because they involve shared mutable state.
They are not derivatives because they involve shared mutable state.
J
17:40
JOHNwick3's dog
Thanks for the response Zack!
well, what i'm curious about is why you need Amoveo to host Derivatives. Why can't you use any other crypto?
Doesn't this have something to do with Oracles?
But why can't someone just create some type of universal Oracle that can use any currency for a derivative?
Say you wanted to use Bitcoin as the bet, could you?
or USD?
So lets say some other coin comes up with a demand for derivatives with their coin, but wants to use Amoveos Oracles without risk in VEO.
I'm obviously asking because I don't fully understand this lol
well, what i'm curious about is why you need Amoveo to host Derivatives. Why can't you use any other crypto?
Doesn't this have something to do with Oracles?
But why can't someone just create some type of universal Oracle that can use any currency for a derivative?
Say you wanted to use Bitcoin as the bet, could you?
or USD?
So lets say some other coin comes up with a demand for derivatives with their coin, but wants to use Amoveos Oracles without risk in VEO.
I'm obviously asking because I don't fully understand this lol
Z
17:40
Zack
In reply to this message
it will get easier with time. We are building up tooling to make stuff like this easy on Amoveo.
Sortition chains will be a key feature moving us in this direction because they will allow a central hub to match up customer contracts without needing to maintain to much locked up capital.
Sortition chains will be a key feature moving us in this direction because they will allow a central hub to match up customer contracts without needing to maintain to much locked up capital.
B
17:41
Ben
perfect, usability is one key aspect that stops amoveo
Z
17:46
Zack
In reply to this message
Amoveo's goal is to be a very cost effective platform for derivatives.
People have been using derivatives longer than recorded history, at least 10k years. Amoveo is less than 2 years old. Cryptocurrency is barely 10 years old.
You don't need Amoveo or any cryptocurrency to use financial derivatives.
>doesn't this have something to do with oracles?
Amoveo's design for oracles is very cost effective. you can read about it here https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/oracle.md
> why not create a universal oracle that can use any currency for a derivative? can you use Bitcoin to bet? or USD?
You can use the result of Amoveo's oracle to resolve contracts on other blockchains. Amoveo has a cheap light node. If you embed the light node into another blockchain, then it can know the results of oracles on Amoveo.
You can make BTC stablecoins on Amoveo, and then make a derivative contract on Amoveo that is priced in the BTC stablecoins.
Similarly you can bet on Amoveo using USD stablecoins.
People have been using derivatives longer than recorded history, at least 10k years. Amoveo is less than 2 years old. Cryptocurrency is barely 10 years old.
You don't need Amoveo or any cryptocurrency to use financial derivatives.
>doesn't this have something to do with oracles?
Amoveo's design for oracles is very cost effective. you can read about it here https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/oracle.md
> why not create a universal oracle that can use any currency for a derivative? can you use Bitcoin to bet? or USD?
You can use the result of Amoveo's oracle to resolve contracts on other blockchains. Amoveo has a cheap light node. If you embed the light node into another blockchain, then it can know the results of oracles on Amoveo.
You can make BTC stablecoins on Amoveo, and then make a derivative contract on Amoveo that is priced in the BTC stablecoins.
Similarly you can bet on Amoveo using USD stablecoins.
WL
17:47
Wilson Lau
In reply to this message
If sortition chain works, what will the flow of setting up and closing a derivative looks like?
J
17:51
John
Do we have a example platform for derivatives running on amoveo?
Z
17:56
Zack
In reply to this message
the p2p derivatives tool in the light node will still work basically the same way once sortition chains exist. the "smart contract" section of the light node http://159.89.87.58:8080/home.html
How the derivatives work behind the scenes doesn't really make a difference for how the user interface looks or acts.
Eventually we will get to the point where the user experience of making an Amoveo derivative contract will be about the same as how it feels to make a derivative contract on a centralized platform like CME today.
How the derivatives work behind the scenes doesn't really make a difference for how the user interface looks or acts.
Eventually we will get to the point where the user experience of making an Amoveo derivative contract will be about the same as how it feels to make a derivative contract on a centralized platform like CME today.
J
17:57
JOHNwick3's dog
so if a lot of derivatives were made on a btc stablecoin or other coin, would that benefit the price of Amoveo a lot? So basically, If you have a BTC stablecoin that it uses, it mirrors the price of BTC but you hold VEO to do it with right?
Z
17:57
Zack
In reply to this message
we have the p2p derivatives tool in the light node. and there is that website where you can post offers of derivatives contracts.
J
17:59
JOHNwick3's dog
Also, you mentioned a while back that there was a method of using Amoveo for derivatives without getting exposure to the price fluxuations? How does that work again? I guess that would be just another derivative basically?
Z
17:59
Zack
In reply to this message
if there was a lot of VEO locked up in contracts, and there was demand for more VEO to be locked up in more contracts, that demand would result in the price of VEO increasing.
If you hold a BTC stablecoin on Amoveo it would stay the same price as BTC, but the contract is priced completely in VEO. When it expires, you get paid a quantity of VEO that is worth as much as how many BTC the contract specifies for you.
If you hold a BTC stablecoin on Amoveo it would stay the same price as BTC, but the contract is priced completely in VEO. When it expires, you get paid a quantity of VEO that is worth as much as how many BTC the contract specifies for you.
WL
18:00
Wilson Lau
In reply to this message
What about the matching both sides? It enable user to match within the chain? Or require thrid party platform?
Z
18:00
Zack
In reply to this message
you can combine derivatives to create whatever risk profile you are interested in.
For example, if you bet that the price of BTC/VEO will increase, and you bet that the price of GOLD/BTC will increase, the combination is like betting that GOLD/VEO will increase.
For example, if you bet that the price of BTC/VEO will increase, and you bet that the price of GOLD/BTC will increase, the combination is like betting that GOLD/VEO will increase.
J
18:03
JOHNwick3's dog
alright, thanks for the feedback Zack. I took some notes. I'm not 100% sure where I was going with this. I'm mainly trying to brainstorm how to build a business/dapp to become financially indepenedent. haha. Makes my head hurt I have to think!
J
18:03
John
In reply to this message
Anything holding back for people to build a large scale derivative tool on amoveo based on the lightnode? Afterall, amoveo is quite a dream tool for them and it sounds like a good way make a lot of money
Z
18:06
Zack
In reply to this message
>what about matching both sides
we previously had a market mechanism where people could make bets on both sides.
But before the existence of sortition chains, it was too expensive. the operator had to lock up too much veo to operate it.
Also, we found some bugs in the smart contract for it.
So we turned that feature off for now, until we are ready to try again.
You can read about how it will work here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md
> it enable user to match within the chain? or require third party platform?
markets necessarily involve some shared mutable state. The order book where trades are matched.
Amoveo doesn't support this kind of state on-chain.
But you can use Amoveo to host this kind of state on a central server in a trust-free way.
I feel that making the market secure and trust-free is more important than making the market decentralized.
if one central trust-free market gets shut down, we can make another.
we previously had a market mechanism where people could make bets on both sides.
But before the existence of sortition chains, it was too expensive. the operator had to lock up too much veo to operate it.
Also, we found some bugs in the smart contract for it.
So we turned that feature off for now, until we are ready to try again.
You can read about how it will work here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md
> it enable user to match within the chain? or require third party platform?
markets necessarily involve some shared mutable state. The order book where trades are matched.
Amoveo doesn't support this kind of state on-chain.
But you can use Amoveo to host this kind of state on a central server in a trust-free way.
I feel that making the market secure and trust-free is more important than making the market decentralized.
if one central trust-free market gets shut down, we can make another.
18:08
In reply to this message
>anything holding back people who want to build large scale derivatives tools on amoveo based on the light node?
The light node is an open source tool for making derivatives. If you have idea on how to improve it, I am willing to accept pull requests.
Or you can make suggestions, and if they are good I will program it, or we will make contracts to incentivize someone else to program it.
The light node is an open source tool for making derivatives. If you have idea on how to improve it, I am willing to accept pull requests.
Or you can make suggestions, and if they are good I will program it, or we will make contracts to incentivize someone else to program it.
J
18:09
John
Thanks for your response Zack
Z
18:10
Zack
Feel free to ask questions about Amoveo here any time.
J
18:13
JOHNwick3's dog
What makes Amoveo blockchain unique?
The Oracle right?
Why can't Bitcoin take the code and have Derivatives done with that?
or any ERC20 coin?
Why can't we just take the code and use it on a different coin so that derivatives can be done on any coin that has liquidity?
The Oracle right?
Why can't Bitcoin take the code and have Derivatives done with that?
or any ERC20 coin?
Why can't we just take the code and use it on a different coin so that derivatives can be done on any coin that has liquidity?
18:14
Can't this just be done by copying amoveos code and making a sidechain on other coins?
18:14
obviously I don't understand the details of how this works, thats why i'm asking
Z
18:24
Zack
In reply to this message
Amoveo is 100% open source.
Any part of Amoveo's software can be easily copied into other blockchains.
This is a very serious risk to the success of Amoveo, it is a big part of the reason that VEO is such a high risk investment.
What can't be copied is the community that has built up around Amoveo. We have a culture, with values that we share.
If Amoveo's culture is correct, then other blockchains wont realize that we were right until we are already popular. And if we are already popular, then there will be network effects making Amoveo the better platform for doing the things that makes Amoveo popular.
> can amoveo be cloned to an erc20 on ethereum?
It is hard to put a competitive oracle on top of Ethereum.
Part of what makes Amoveo's oracle design work is that it is the only oracle on Amoveo. So the success of veo and the success of the oracle are tied together closely. So we can use the price of veo as a signal to know about the oracle's accuracy on a fork.
With ethereum there can be many oracles, so the success of any one oracle isn't very connected to the price of ETH.
The kinds of oracles that people have been able to build on Ethereum are all less cost effective than Amoveo's oracle design.
> can amoveo be cloned to a bitcoin?
yes, that is the goal of the drivechain project. I highly recommend their website and forums http://bitcoinhivemind.com/ they are a major inspiration for Amoveo.
Adding these features to bitcoin is a political battle.
Bitcoin is so big that it is very hard to make changes to it now.
Also, I think the current strategy being explored by drivechain will not work https://github.com/zack-bitcoin/amoveo/blob/master/docs/other_blockchains/drivechain.md
Any part of Amoveo's software can be easily copied into other blockchains.
This is a very serious risk to the success of Amoveo, it is a big part of the reason that VEO is such a high risk investment.
What can't be copied is the community that has built up around Amoveo. We have a culture, with values that we share.
If Amoveo's culture is correct, then other blockchains wont realize that we were right until we are already popular. And if we are already popular, then there will be network effects making Amoveo the better platform for doing the things that makes Amoveo popular.
> can amoveo be cloned to an erc20 on ethereum?
It is hard to put a competitive oracle on top of Ethereum.
Part of what makes Amoveo's oracle design work is that it is the only oracle on Amoveo. So the success of veo and the success of the oracle are tied together closely. So we can use the price of veo as a signal to know about the oracle's accuracy on a fork.
With ethereum there can be many oracles, so the success of any one oracle isn't very connected to the price of ETH.
The kinds of oracles that people have been able to build on Ethereum are all less cost effective than Amoveo's oracle design.
> can amoveo be cloned to a bitcoin?
yes, that is the goal of the drivechain project. I highly recommend their website and forums http://bitcoinhivemind.com/ they are a major inspiration for Amoveo.
Adding these features to bitcoin is a political battle.
Bitcoin is so big that it is very hard to make changes to it now.
Also, I think the current strategy being explored by drivechain will not work https://github.com/zack-bitcoin/amoveo/blob/master/docs/other_blockchains/drivechain.md
J
18:32
JOHNwick3's dog
Couldn't you build an oracle on an erc20 token so that its price is tied to that? and that would be independent of Ethereum price?
I'd bet Amoveo has a chance of success even if this happens, but i'm curious.
I'd bet Amoveo has a chance of success even if this happens, but i'm curious.
18:33
Amount of money in derivatives is huge, so it makes sense to have redundancy of where to store the derivatives and competition.
18:34
Amoveo on its own blockchain is a security risk.. Bitcoin has apparently had two inflation bugs.
Z
18:35
Zack
In reply to this message
That is an idea we talked about before.
For example, if Augur only allowed betting in Rep.
I asked Augur why they don't only do betting in Rep. Let me try and remember what they said.
For example, if Augur only allowed betting in Rep.
I asked Augur why they don't only do betting in Rep. Let me try and remember what they said.
18:42
oh, I remember.
The reason an ERC-20 can't be as effective is because the rest of the Ethereum community might not care to hard fork their entire blockchain just to rescue one ERC-20 derivatives contract.
So even if Ethereum did hard fork as part of the recovery process, and the ERC-20 was much more valuable on side A so we could know which side has an honest oracle, side B with the dishonest oracle could still win if the price of Eth is higher on side B.
And the reason Augur didn't use that strategy is because Rep is too volatile, and the market cap of Rep is too low. It would have been an inferior product with more volatility.
The reason an ERC-20 can't be as effective is because the rest of the Ethereum community might not care to hard fork their entire blockchain just to rescue one ERC-20 derivatives contract.
So even if Ethereum did hard fork as part of the recovery process, and the ERC-20 was much more valuable on side A so we could know which side has an honest oracle, side B with the dishonest oracle could still win if the price of Eth is higher on side B.
And the reason Augur didn't use that strategy is because Rep is too volatile, and the market cap of Rep is too low. It would have been an inferior product with more volatility.
18:45
In reply to this message
yes, if Amoveo was popular, there would inevitably be altcoins ready to take our place if we ever mess up.
J
19:02
JOHNwick3's dog
In reply to this message
I don't undestand this part. why would you need to hardfork to rescue a derivatives contract?
19:03
What does the side a and side b stuff mean?
Z
19:03
Zack
In reply to this message
This is the design we are using in Amoveo to allow for such an extremely affordable oracle.
If Amoveo's oracle works, then every other design currently being explored will become cost-prohibitive in comparison to Amoveo's design.
If Amoveo's oracle works, then every other design currently being explored will become cost-prohibitive in comparison to Amoveo's design.
19:04
We were studying oracles a lot.
It turns out that coming to agreement on the state of the oracle is a kind of consensus protocol, like how PoW is a blockchain consensus protocol to come to agreement about who has which money.
It turns out that coming to agreement on the state of the oracle is a kind of consensus protocol, like how PoW is a blockchain consensus protocol to come to agreement about who has which money.
19:04
Consensus protocols are very expensive.
19:05
Amoveo's oracle is cheap because we found a way to re-use the blockchain consensus protocol to also be an oracle consensus protocol.
All other designs involve sustaining 2 consensus mechanisms at the same time, which is far more expensive than just having 1.
All other designs involve sustaining 2 consensus mechanisms at the same time, which is far more expensive than just having 1.
19:07
this is the documentation for Amoveo's oracle https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/oracle.md
J
19:07
JOHNwick3's dog
So this is the "why" of Amoveo. This is all fine and well, but if I struggle to understand this than other people probably do too. I get the basic idea of what your saying...
Why can't all this be copied onto an erc20 token?
Why can't all this be copied onto an erc20 token?
19:08
all other designs suck why aren't they copying your design? lol
Z
19:17
Zack
In reply to this message
> why can't this be copied into an erc20 token?
ethereum erc20 tokens are inside a VM sandbox.
For example, you can't make an ethereum smart contract that changes the size of the ethereum block reward or changes the gas price of opcodes, or causes ethereum blocks to happen more slowly or faster.
Amoveo's oracle is intimately connected to the PoW mechanism in a way that is not possible for an Ethereum smart contract.
Amoveo only has one oracle, so if that one oracle should fail, it would cause VEO to fail. So the price of VEO is connected to the accuracy of the oracle in a measurable way. The side of an Amoveo blockchain fork with a less honest oracle tends to lose to the side with a more honest oracle.
In Ethereum there are many different smart contracts. The community might not care if our derivative contract succeeds or fails. So if the ethereum blockchain forks, there is no incentive to go with the side of the fork that has a more honest derivatives contract.
> if all other designs suck, why aren't they copying your design?
different teams have different reasons.
Bitcoin hivemind is dedicated to BTC, their community isn't willing to do anything on any blockchain besides bitcoin.
Augur is dedicated to ETH, their community isn't willing to do anything on any blockchain besides Ethereum.
A lot of teams don't understand the importance of a trust-free oracle. They use trusted third parties to resolve derivatives contracts.
ethereum erc20 tokens are inside a VM sandbox.
For example, you can't make an ethereum smart contract that changes the size of the ethereum block reward or changes the gas price of opcodes, or causes ethereum blocks to happen more slowly or faster.
Amoveo's oracle is intimately connected to the PoW mechanism in a way that is not possible for an Ethereum smart contract.
Amoveo only has one oracle, so if that one oracle should fail, it would cause VEO to fail. So the price of VEO is connected to the accuracy of the oracle in a measurable way. The side of an Amoveo blockchain fork with a less honest oracle tends to lose to the side with a more honest oracle.
In Ethereum there are many different smart contracts. The community might not care if our derivative contract succeeds or fails. So if the ethereum blockchain forks, there is no incentive to go with the side of the fork that has a more honest derivatives contract.
> if all other designs suck, why aren't they copying your design?
different teams have different reasons.
Bitcoin hivemind is dedicated to BTC, their community isn't willing to do anything on any blockchain besides bitcoin.
Augur is dedicated to ETH, their community isn't willing to do anything on any blockchain besides Ethereum.
A lot of teams don't understand the importance of a trust-free oracle. They use trusted third parties to resolve derivatives contracts.
19:20
In reply to this message
If there was a futarchy market saying that VEO would be more valuable if we moved everything into a contract on Ethereum, then I would make a big profit in that futarchy market.
I would bet that the Amoveo side will be more valuable than the Ethereum side, and my bet will win.
Even if the majority of the community moved onto Ethereum, that doesn't fix the inherent technical limitations on Ethereum that make it a less effective derivatives platform.
I would bet that the Amoveo side will be more valuable than the Ethereum side, and my bet will win.
Even if the majority of the community moved onto Ethereum, that doesn't fix the inherent technical limitations on Ethereum that make it a less effective derivatives platform.
19:23
> if all other designs suck, why aren't they copying your design?
Also, some people think that Amoveo's oracle wont work. Paul Sztorc wrote about why he thinks Amoveo's oracle will cause Amoveo to fork over and over, and we will end up with hundreds of worthless forks.
Also, some people think that Amoveo's oracle wont work. Paul Sztorc wrote about why he thinks Amoveo's oracle will cause Amoveo to fork over and over, and we will end up with hundreds of worthless forks.
J
19:25
JOHNwick3's dog
"For example, you can't make an ethereum smart contract that changes the size of the ethereum block reward or changes the gas price of opcodes, or causes ethereum blocks to happen more slowly or faster."
Why is this important? just because you can design a more efficient blockchain for derivatives if you can modify these things?
Why is this important? just because you can design a more efficient blockchain for derivatives if you can modify these things?
Z
19:26
Zack
In reply to this message
im just trying to explain how Ethereum's VM is sandboxed. That you don't have access to core consensus mechanism stuff.
19:27
The feature of the core consensus that we use for efficient oracle resolution is the PoW fork resolution process.
J
19:28
JOHNwick3's dog
"Amoveo only has one oracle, so if that one oracle should fail, it would cause VEO to fail. So the price of VEO is connected to the accuracy of the oracle in a measurable way. The side of an Amoveo blockchain fork with a less honest oracle tends to lose to the side with a more honest oracle.
In Ethereum there are many different smart contracts. The community might not care if our derivative contract succeeds or fails. So if the ethereum blockchain forks, there is no incentive to go with the side of the fork that has a more honest derivatives contract."
And you said here: if it forks? If there is a disagreement there is a fork? What would be the cause of Amoveo forking?
So basically the incentives are more aligned with Amoveo.
In Ethereum there are many different smart contracts. The community might not care if our derivative contract succeeds or fails. So if the ethereum blockchain forks, there is no incentive to go with the side of the fork that has a more honest derivatives contract."
And you said here: if it forks? If there is a disagreement there is a fork? What would be the cause of Amoveo forking?
So basically the incentives are more aligned with Amoveo.
Z
19:30
Zack
In reply to this message
In Amoveo if someone tries to make an oracle lie, and they are willing to spend a lot of money on this goal, it ends up causing the blockchain to fork.
J
19:30
JOHNwick3's dog
ok
Z
19:34
Zack
In reply to this message
Here is a copy/paste of Paul commenting on the oracle.
https://raw.githubusercontent.com/zack-bitcoin/amoveo/master/docs/progress_reports/Paul_Sztorc_Quick_Review.md
and then I wrote more about this a few days later after thinking about what Paul had said.
https://github.com/zack-bitcoin/amoveo/blob/master/docs/attacks_analyzed/ambiguous_oracle.md
https://raw.githubusercontent.com/zack-bitcoin/amoveo/master/docs/progress_reports/Paul_Sztorc_Quick_Review.md
and then I wrote more about this a few days later after thinking about what Paul had said.
https://github.com/zack-bitcoin/amoveo/blob/master/docs/attacks_analyzed/ambiguous_oracle.md
J
20:13
JOHNwick3's dog
Thanks for answering all of my questions Zack!
Craig invited Craig
C
21:40
Craig
I'm inspired by Mr wick's very basic questions and Zack's patience to respond.
I'm also trying to learn about derivatives in crypto. My current frame of reference is the Synthetix project though I'm far far far from an expert there.
But as I understand the synthetix framework, you end up with erc20 representations of the underlying assets.
So you wouldn't call it "a BTC stablecoin" but synthetic BTC or sBTC for short. Likewise sUSD. The plan in the future would be sAPPL and so on.
These erc20 coins can float around the entirw Ethereum ecosystem, with it's DEXes, lending platforms, liquidity protocols and so on.
I might be wrong about all that, still learning.
I have a lot of questions, mostly hard to articulate. But let me start here.
BTC on amoveo (call it vBTC?)
What does that look like exactly? Is it a token, a contract? Is it somehow an IOU that only settles weekly, monthly or whatever?
How could it be listed on a CEX or a DEX?
I'm also trying to learn about derivatives in crypto. My current frame of reference is the Synthetix project though I'm far far far from an expert there.
But as I understand the synthetix framework, you end up with erc20 representations of the underlying assets.
So you wouldn't call it "a BTC stablecoin" but synthetic BTC or sBTC for short. Likewise sUSD. The plan in the future would be sAPPL and so on.
These erc20 coins can float around the entirw Ethereum ecosystem, with it's DEXes, lending platforms, liquidity protocols and so on.
I might be wrong about all that, still learning.
I have a lot of questions, mostly hard to articulate. But let me start here.
BTC on amoveo (call it vBTC?)
What does that look like exactly? Is it a token, a contract? Is it somehow an IOU that only settles weekly, monthly or whatever?
How could it be listed on a CEX or a DEX?
Z
21:51
Zack
In reply to this message
any time you use financial derivatives to try to create the same risk profile as another asset, this is called a "synthetic asset".
if you combine different derivatives to try an create something that stays the same value as $100 USD, then this is "synthetic USD".
I think that putting any financial derivative into a ERC20 is a bad strategy.
The reason financial derivatives are powerful is because they don't have any shared mutable state.
ERC20 is shared mutable state, it destroys all the usefulness of derivatives.
For example, lets say that we made a channel together, and we wanted to trade some synthetic USD in our channel.
unless we put ERC20 synthetic usd in the channel when we had first made it, this would be impossible.
A channel can only use ERC tokens if you had put those ERC tokens in when the channel was first created.
similarly, if we use sharding/side-chains to make a blockchain more scalable, each shard will only have access to the ERC tokens that are inside of it.
If all the ERC20 tokens for synthetic USD are in different shards from the shards where your money is, then you cannot use the ERC20 synthetic USD.
Normal financial derivatives like on Amoveo doesn't have this problem. If you and I have a channel with VEO in it, we can immediately create a synthetic USD contract, or a synthetic BTC contract, or leveraged USD, or whatever you want.
Another problem with ERC20 derivatives is that they are one-size-fits-all. There is only one size of margins for the entire ERC20 contract.
but in reality, every trader has their own unique needs. Depending on how long you are holding the synthetic USD, and what you will be using it for, you might be willing to pay for very wide margins. or you might want to save money and only pay for more narrow margins.
If we use normal financial derivatives like Amoveo, then when we make the synthetic BTC contract we can choose exactly the margins we want.
We could choose whatever expiration for the contract that we want.
>How could it be listed on a CEX/DEX?
I wrote about that here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md
I think it is wrong to think about it as a DEX (decentralized exchange) or CEX (centralized exchange).
A decentralized exchange is trash because you can never prevent front-running.
the property we really care about is whether the exchange is trustful or trustless.
if you combine different derivatives to try an create something that stays the same value as $100 USD, then this is "synthetic USD".
I think that putting any financial derivative into a ERC20 is a bad strategy.
The reason financial derivatives are powerful is because they don't have any shared mutable state.
ERC20 is shared mutable state, it destroys all the usefulness of derivatives.
For example, lets say that we made a channel together, and we wanted to trade some synthetic USD in our channel.
unless we put ERC20 synthetic usd in the channel when we had first made it, this would be impossible.
A channel can only use ERC tokens if you had put those ERC tokens in when the channel was first created.
similarly, if we use sharding/side-chains to make a blockchain more scalable, each shard will only have access to the ERC tokens that are inside of it.
If all the ERC20 tokens for synthetic USD are in different shards from the shards where your money is, then you cannot use the ERC20 synthetic USD.
Normal financial derivatives like on Amoveo doesn't have this problem. If you and I have a channel with VEO in it, we can immediately create a synthetic USD contract, or a synthetic BTC contract, or leveraged USD, or whatever you want.
Another problem with ERC20 derivatives is that they are one-size-fits-all. There is only one size of margins for the entire ERC20 contract.
but in reality, every trader has their own unique needs. Depending on how long you are holding the synthetic USD, and what you will be using it for, you might be willing to pay for very wide margins. or you might want to save money and only pay for more narrow margins.
If we use normal financial derivatives like Amoveo, then when we make the synthetic BTC contract we can choose exactly the margins we want.
We could choose whatever expiration for the contract that we want.
>How could it be listed on a CEX/DEX?
I wrote about that here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md
I think it is wrong to think about it as a DEX (decentralized exchange) or CEX (centralized exchange).
A decentralized exchange is trash because you can never prevent front-running.
the property we really care about is whether the exchange is trustful or trustless.
C
22:01
Craig
I don't have the time to follow up or digest the GitHub quite yet
But thanks so much for the thorough response.
My instinctual response is, it seems to me that the sXXX erc20 tokend Synthetix is creating aren't entirely useless even, if they aren't ideal...
I actually need to go back and understand the word channel though, that's how basic I am.
I'll be back when I have more study under my belt
But thanks so much for the thorough response.
My instinctual response is, it seems to me that the sXXX erc20 tokend Synthetix is creating aren't entirely useless even, if they aren't ideal...
I actually need to go back and understand the word channel though, that's how basic I am.
I'll be back when I have more study under my belt
A
22:01
Alex
In reply to this message
What makes an exchange trustless (or trustful) independent of centralization? In other words, what is the defining measure of trustlessness?
Z
22:03
Zack
In reply to this message
erc20 synthetic assets are useful if you have a blockchain with 1 shard and you do everything on-chain.
but that means you can only have like 30 txs per second at best.
Shared mutable state is an anti-scalability flaw.
If you want to scale bigger, then you need to get rid of the erc20 and use normal financial derivatives.
but that means you can only have like 30 txs per second at best.
Shared mutable state is an anti-scalability flaw.
If you want to scale bigger, then you need to get rid of the erc20 and use normal financial derivatives.
22:04
In reply to this message
I developed a math framework to quantify what we mean by "trust" https://github.com/zack-bitcoin/amoveo/blob/master/docs/basics/trust_theory.md
A
Z
22:17
Zack
there are about 10^10 people.
a day has about 10^5 seconds.
so if every person makes 1 tx per day, then that means we need 10^5 txs per second.
100 000 txs per second.
so a single-threaded blockchain doing 30 txs per second is not nearly good enough.
a day has about 10^5 seconds.
so if every person makes 1 tx per day, then that means we need 10^5 txs per second.
100 000 txs per second.
so a single-threaded blockchain doing 30 txs per second is not nearly good enough.
A
22:18
Alex
In reply to this message
Great read. Well organized thoughts, cohesive model. Some of the best reading I've done in my time in this space
Z
A
22:22
Alex
As I continue to grasp the logic behind Amoveo, I see more and more that it's major strengths lie in its independent Blockchain model and cost-efficient oracle, which of course feed off of one another.
The major, make-or-break piece - what you refer to as "risk" - is achieving a substantial network effect inside of some undefined but nonetheless critical time horizon. I am interested to know you approach to marketing, and if you are waiting for macroeconomic changes or to complete certain technical elements prior to jumpstarting a professional marketing campaign of sorts
The major, make-or-break piece - what you refer to as "risk" - is achieving a substantial network effect inside of some undefined but nonetheless critical time horizon. I am interested to know you approach to marketing, and if you are waiting for macroeconomic changes or to complete certain technical elements prior to jumpstarting a professional marketing campaign of sorts
Z
22:26
Zack
I am afraid that moderate success could prevent us from achieving profound success.
If we market hard now, we will grow fast, and then hit our scaling limit. And at that point everyone else will see that it works and is popular, and competition will get much harder.
I want to get sortition chains operational first, that way we wont have any scaling limitations.
https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/sortition_chains.md
If we market hard now, we will grow fast, and then hit our scaling limit. And at that point everyone else will see that it works and is popular, and competition will get much harder.
I want to get sortition chains operational first, that way we wont have any scaling limitations.
https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/sortition_chains.md
A
22:27
Alex
Understand and respect the vision
Z
22:27
Zack
Also the transition from on-chain channels to sortition-chain channels will be messy. I think it will be a lot less work to do this transition earlier on the popularity progression path instead of later.
A
22:27
Alex
Are you familiar with defix?
Z
A
22:28
Alex
Yes
22:29
They have given Amoveo a generous portfolio allocation on par with ZRX and Augur
22:29
Have they contacted you?
Z
22:30
Zack
yeah, these are the exantech guys. they have been involved with amoveo a long time. they made the amoveo.io website, and maintain an amoveo blog with newsletters, and frequently come on this chat.
A
22:30
Alex
Ah understood
22:30
So they are investors and contributors?
22:30
Almost sounds like PE involvement
Z
22:32
https://amoveo.substack.com/ here is the newsletter they have been making
22:32
I guess they stopped a few months ago
A
22:33
Alex
My fault. In PE (Private Equity) the investing firm makes a (sometimes early stage) investment, and assists upper management to reform its business, operations, etc. Whereas in VC (venture capitalism), there is significant early stage investment, but less involvement
Z
22:34
Zack
yeah, it is kind of like PE.
but kind of different, because Amoveo isn't a company. They didn't need anyone's permission to buy a bunch of veo and start helping out.
but kind of different, because Amoveo isn't a company. They didn't need anyone's permission to buy a bunch of veo and start helping out.
A
22:34
Alex
Are they paid?
22:34
Or do they mine as well?
Z
22:35
Zack
I think they are a branch of a bigger financial company called "exan group"
A
22:35
Alex
Also, thank you for answering these questions. I don't get transparency or thorough responses like this anywhere
Z
22:37
Zack
That is what this forum is for, and what I am paid to do.
A
22:37
Alex
So you're main developer and community mod?
Z
22:38
Zack
I moderate this forum, and I am the main developer
A
22:38
Alex
Much respect 👍🏻
22:38
How many devs are on the team in total?
22:39
I see you also run your own medium
22:39
And does Amoveo have a base or main office, or is it fully distributed?
Z
22:41
Zack
I don't run a medium.
You can see contributors to Amoveo core here https://github.com/zack-bitcoin/amoveo/graphs/contributors
It is pretty much just me.
We are distributed.
You can see contributors to Amoveo core here https://github.com/zack-bitcoin/amoveo/graphs/contributors
It is pretty much just me.
We are distributed.
22:42
oh, there is a medium. I think exantech did that too.
A
22:42
Alex
Understood
22:43
Can you give a little background evantech's involvement?
22:43
Did they find your project and express interest, or did you seek them out?
Z
22:44
Zack
I don't actually know much about them. Most of them don't speak english as a first language.
They found Amoveo, I didn't seek them out.
They found Amoveo, I didn't seek them out.
A
22:46
Alex
Ah, very interesting
22:46
Then they hired you?
Z
22:46
Zack
no. I haven't paid them, they haven't paid me.
A
22:47
Alex
Who pays you?
Z
22:47
Zack
I get a developer reward with each block mined.
22:47
1/6th of the new coins
A
22:47
Alex
Ok, this is quite interesting
22:47
But who pays you to moderate?
Z
22:48
Zack
Amoveo's governance uses futarchy.
If the community thinks I am doing a bad job, they can lower my pay as easily as modifying any of the other variables controlled by the governance mechanism.
If the community thinks I am doing a bad job, they can lower my pay as easily as modifying any of the other variables controlled by the governance mechanism.
22:49
No one specifically tells me to moderate, this is just one of the things I do to hopefully keep getting paid.
A
22:49
Alex
(I contend you are in fact doing a good job, but will have to grab some tokens contribute my opinion accordingly)
22:49
I read that you also contributed to Augur and another prominent ERC20 whose name is escaping me. May I ask why you departed those projects?
Z
22:54
Zack
Augur was committed to using the votecoin strategy, which I think is prohibitively expensive.
They wanted intellectual property ownership of all my ideas, and the ability to sue me for unlimited damages if I revealed any info that later turned out harmful to Augur.
So I left.
I tried teaming up with some other people, but they were physically violent, so I left.
They wanted intellectual property ownership of all my ideas, and the ability to sue me for unlimited damages if I revealed any info that later turned out harmful to Augur.
So I left.
I tried teaming up with some other people, but they were physically violent, so I left.
A
22:54
Alex
Wow. Very much respect.
22:55
So then you founded Amoveo?
Z
22:56
Zack
I wrote the MVP for Augur, Amoveo, and the other project, each one before it was named. I founded all 3.
A
22:57
Alex
Very impressed
22:59
The violence you alluded to in Augur makes me quite concerned for the ETH community. I am interested to know your perspective on Vitalik's vision - as I imagine you must have shared dialogue with him at various points - and you outlook for the whole ecosystem
Z
22:59
Zack
there was no violence in Augur.
22:59
they are peaceful people.
A
22:59
Alex
Demanding ownership over your intellectual property is absolutely not in the spirit of Blockchain
Z
23:00
Zack
oh right
A
23:00
Alex
Ah violence was with others - my bad
Z
23:00
Zack
well, they wanted to be able to sell Augur at a high price, and if I signed the contract, then Augur would be worth more. I think Jack had signed similar contracts at his previous jobs.
A
23:01
Alex
Sell tokens, or rights to the whole project?
Z
23:01
Zack
and I was homeless at the time, so I think they felt like I didn't have much room to barter
A
23:01
Alex
Jesus
23:01
Are you self-taught?
23:02
You know what, I'm going to stop asking personal questions in this chat room. Sorry for this.
Z
23:02
Zack
I went to school for physics for a while.
My understanding was that they wanted the ability to sell Augur the company
My understanding was that they wanted the ability to sell Augur the company
23:03
23:03
Here is a reward I got for helping NASA go to Mars
23:04
I learned a little software from them
A
23:05
Alex
Would use an exasperated gif of impression and disbelief, but no gifs allowed in this chat
P
A
23:05
Alex
Based af
Z
23:05
Zack
I used python to help make a calendar for them to schedule their meetings.
A
23:10
Alex
Were they a bright group?
Z
23:12
Zack
I think Vitalik is very smart. I asked him questions in person before, and he can make such accurate answers so fast.
I guess the main places we disagree:
* Vitalik still thinks PoS is possible. I wrote why I think it is not here https://github.com/zack-bitcoin/amoveo/blob/master/docs/other_blockchains/proof_of_stake.md
* Vitalik is so committed to having mutable state on ethereum, I think that it is better to only use financial derivatives so we don't need mutable state. Our disagreement about mutable state is the root of our disagreement about how scaling should happen. I think that lottery based sidechains with probabilistic value tokens are best, vitalik wants to assign validators to shards.
* vitalik and I agree that voting is bad, but vitalik is so interested in quadratic voting instead. I think that we should use futarchy for all our decisions.
I guess the main places we disagree:
* Vitalik still thinks PoS is possible. I wrote why I think it is not here https://github.com/zack-bitcoin/amoveo/blob/master/docs/other_blockchains/proof_of_stake.md
* Vitalik is so committed to having mutable state on ethereum, I think that it is better to only use financial derivatives so we don't need mutable state. Our disagreement about mutable state is the root of our disagreement about how scaling should happen. I think that lottery based sidechains with probabilistic value tokens are best, vitalik wants to assign validators to shards.
* vitalik and I agree that voting is bad, but vitalik is so interested in quadratic voting instead. I think that we should use futarchy for all our decisions.
23:14
In reply to this message
yeah, the people I met at NASA were very smart.
But their administration has become bloated, and the pointless bureaucracy is so wasteful.
But their administration has become bloated, and the pointless bureaucracy is so wasteful.
A
23:18
Alex
In reply to this message
Thank you for all answers here. I am going to research some of the terms you have used here to get a better understanding of your differences in perspective.
Z
23:18
Zack
oh, and Vitalik thinks bribery attacks can work against PoW. I think that no one will join an attacker coalition in PoW, because there is no way to prove that they wont get double-crossed if they join.
A
23:19
Alex
got it
24 January 2020
Z
01:32
Zack
I think that the first time I read about truthcoin was in January, 6 years ago.
I stopped going to my physics classes.
I didn't want to work, that way I could spend all my time focused on truthcoin. So I kept my expenses at practically zero.
I am so captivated by this dream.
A better way for groups of people to cooperate.
I stopped going to my physics classes.
I didn't want to work, that way I could spend all my time focused on truthcoin. So I kept my expenses at practically zero.
I am so captivated by this dream.
A better way for groups of people to cooperate.
A
Z
17:30
Zack
In reply to this message
Depends what you mean by PoS.
If PoS means each person has a influence in proportion to their stake, then futarchy Is not pos.
In futarchy, your influence is largely based on to how confident you are in the impact the decision will have on the price.
If PoS means each person has a influence in proportion to their stake, then futarchy Is not pos.
In futarchy, your influence is largely based on to how confident you are in the impact the decision will have on the price.
A
18:15
Asindu
In reply to this message
Betting can be analogized as staking & loosing a bet can also be analogized as getting "slashed".
Just like how in Futarchy Oracles, we bet on the truth & anyone that bets against the truth is just a payment to honest oracles(via slashing)
Just like how in Futarchy Oracles, we bet on the truth & anyone that bets against the truth is just a payment to honest oracles(via slashing)
Z
18:27
Zack
In reply to this message
With voting, whoever is in the majority wins.
With betting, the minority can win.
Like, let's say we are thinking of doing an upgrade. And the upgrade turns out to be a bad idea that makes the price go down.
But we didn't know it would be bad. We thought it would be good.
In that situation, it is possible that futarchy would tell us to do the upgrade. So we would do the upgrade.
But then, everyone who bet that the upgrade was good, they would all lose their bets.
Everyone who bet that the upgrade was bad, they would win their bets.
With betting, the minority can win.
Like, let's say we are thinking of doing an upgrade. And the upgrade turns out to be a bad idea that makes the price go down.
But we didn't know it would be bad. We thought it would be good.
In that situation, it is possible that futarchy would tell us to do the upgrade. So we would do the upgrade.
But then, everyone who bet that the upgrade was good, they would all lose their bets.
Everyone who bet that the upgrade was bad, they would win their bets.
A
18:37
Asindu
In reply to this message
Thanks. Well explained as usual.
Btw could you expand more on level 4 security?
Btw could you expand more on level 4 security?
18:38
I don't understand how it can cost less than zero to attack a system
Z
18:39
Zack
Attacks can often be profitable.
if someone takes the money from your pocket, and you don't notice, then they can keep the money.
if someone takes the money from your pocket, and you don't notice, then they can keep the money.
A
18:58
Where do time locks fall?
18:59
Level 1 or level 2?
18:59
Or 3
Z
19:07
Zack
hash timelock is used to connect 2 events, so either they both occur, or neither occurs. so in this situation, we consider a successful attack to be one which can cause either of the 2 events to occur, and prevent the other from occurring.
If one of the events is on a blockchain, then can do a 51% attack to censor that event. so in that case it has the same security level as the blockchain consensus mechanism. in the case of PoW, trust level 2.
If the 2 events are happening in channels that the attacker is not a participant in, then the attacker can't even know the state of the channel to know if the attack succeeded or not. I think in this case it would have trust level 1.
If the attacker is one of the participants in each of the channels, then the attack could succeed if the attacker can prevent their partner from posting the channel data on-chain to cause the blockchain to enforce the correct outcome. so it is as difficult as censoring the blockchain, which in the case of PoW is trust level 2.
If one of the events is on a blockchain, then can do a 51% attack to censor that event. so in that case it has the same security level as the blockchain consensus mechanism. in the case of PoW, trust level 2.
If the 2 events are happening in channels that the attacker is not a participant in, then the attacker can't even know the state of the channel to know if the attack succeeded or not. I think in this case it would have trust level 1.
If the attacker is one of the participants in each of the channels, then the attack could succeed if the attacker can prevent their partner from posting the channel data on-chain to cause the blockchain to enforce the correct outcome. so it is as difficult as censoring the blockchain, which in the case of PoW is trust level 2.
A
19:21
Asindu
When do we add decimals? Was thinking this was one of those cases
Z
19:25
Zack
if someone is doing a 51% attack against PoW, we all know it is happening. So this kind of attack is 2.1, not 2.2.
Z
23:40
Zack
https://github.com/zack-bitcoin/MerkleTrie/blob/experimental/src/mtree.erl
I rewrote the merkle tree to not need Dump or any OTP supervisor. So we can make unnamed merkle trees.
This will allow us to make a new merkle tree for each block we a processing in parallel, which is something we needed to be able to verify blocks in reverse.
I rewrote the merkle tree to not need Dump or any OTP supervisor. So we can make unnamed merkle trees.
This will allow us to make a new merkle tree for each block we a processing in parallel, which is something we needed to be able to verify blocks in reverse.
23:42
Next ill update the OTP version to use this new way of dealing merkle trees, and then I will delete a bunch of unused code from MerkleTrie, and then I will set up Amoveo to process blocks in reverse.
25 January 2020
Z
06:53
Zack
looks like the new version of the merkle tree is working with Amoveo
06:58
we made it to 100k blocks.
B
06:58
Beer
grats
Z
08:12
Zack
the new merkel tree doesn't work right if I turn it off and then back on.
Z
08:53
Zack
now it doesn't die when I restart it, but it has a memory leak that eventually fills up the ram and makes it crash.
09:04
I switched it back to normal version of trees, and it still crashed while syncing.
09:15
yeah, normally it should only be using ~110 mb, but it is using over 600 mb.
09:16
maybe the dependencies didn't get recompiled correctly. I haven't changed anything in the master branch that could cause this.
09:27
im not sure why this memory leak is happening.
09:28
if you are running an amoveo node. do not update it.
Z
09:44
Zack
it looks like the memory leak is in the form of binaries.
09:58
oh, looks like the recent_blocks process froze
10:01
I updated recent_blocks 6 days ago, to what I thought was a faster way of looking up headers. but I guess it actually broke it.
10:01
undoing that change seems to have fixed it.
10:04
crisis averted. haha
A
10:06
Alex
In reply to this message
Have some great gifs for this, but seeing as none are allowed:
Very nice to hear. Confidence restored 👍🏻
Very nice to hear. Confidence restored 👍🏻
Z
11:13
Zack
if you restart a fully synced erlang node, it's memory cost drops from 160 mb to only 100 mb.
I guess there are 60 mb of the kind of memory leaks that disappear when you reboot.
I guess there are 60 mb of the kind of memory leaks that disappear when you reboot.
11:16
the file that contains all the blocks is 237 mb.
and there are 100 k blocks.
So that means the average block is about 2370 bytes
and there are 100 k blocks.
So that means the average block is about 2370 bytes
11:17
there are 25 megabytes of headers.
So the average header is using up about 250 bytes.
So the average header is using up about 250 bytes.
11:23
im able to fully sync, and I can restart, using the new version of the merkle tree.
Z
11:42
Zack
there are 3 megabytes of accounts now.
maybe we should delete all the ones that have less than enough veo to pay a tx fee.
maybe we should delete all the ones that have less than enough veo to pay a tx fee.
11:43
each checkpoint is only 1.1 megabytes.
Even though it is storing like 4 megabytes of merkel tree files.
I guess there is a lot of repetition that can be compressed.
Even though it is storing like 4 megabytes of merkel tree files.
I guess there is a lot of repetition that can be compressed.
11:44
i bet if we put headers into compressed pages, like we did with blocks, they would get sent a lot faster.
b̲̅a̲̅m̲̅b̲̅u̲̅n̲̅g̲̅ h̲̅i̲̅d̲̅e̲̅u̲̅n̲̅g̲̅︻┳═一 invited b̲̅a̲̅m̲̅b̲̅u̲̅n̲̅g̲̅ h̲̅i̲̅d̲̅e̲̅u̲̅n̲̅g̲̅︻┳═一
Z
21:43
Zack
A lot of people have this perspective, thinking "what more can we add to cryptocurrency to make it better?"
But the more important innovations are when we realize something is unnecessary, and it can be removed.
The best tool is one that does the least.
But the more important innovations are when we realize something is unnecessary, and it can be removed.
The best tool is one that does the least.
26 January 2020
S
05:36
Siasuomo
Hello
Z
06:07
Zack
I verified almost 300 blocks in reverse order.
We are getting near to having this working.
We are getting near to having this working.
X
06:09
X | NPC
Great
Z
06:11
Zack
I verified the first 460 in reverse. now im working on writing the first compressed page of blocks to the hard drive.
Z
07:06
Zack
I did over 2000 blocks in reverse.
A
07:06
Alex
Man Ive got such great memes for moments like this
07:07
But congrats to you, and thank you for advancing this vision toward a tangible platform
Z
07:23
Zack
it's not updating the oracle-unmatched merkle tree correctly. I think 96043 is the most recent block that updates this tree.
Deleted invited Deleted Account
Z
13:20
Zack
im thinking for the very early blocks, I am just going to have it verify that the block matches the POW from the header.
Because I don't want to re-program these hard updates in reverse.
Because I don't want to re-program these hard updates in reverse.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
20:05
Zack
I am still stuck on 96043.
my next strategy is to use the block metadata system to find out exactly which merkel proofs should have updated in what way, to figure out where my reverse-sync process is messing up.
my next strategy is to use the block metadata system to find out exactly which merkel proofs should have updated in what way, to figure out where my reverse-sync process is messing up.
Z
21:27
Zack
I confirmed that the unmatched merkle tree isn't updating right because it isn't including the root element of the order books.
Z
23:25
Zack
it looks like the problem is because I loop over the input merkel proofs when making updates.
but with new_oracle_tx, we add some new info to the consensus state which doesn't have a corresponding input proof.
but with new_oracle_tx, we add some new info to the consensus state which doesn't have a corresponding input proof.
27 January 2020
Z
00:57
Zack
Now I loop over all the resulting values after running the txs, so the order book roots from the unmatched tree are being included.
but the root hash of the unmatched tree is still wrong.
I added more details to block meta, hopefully this will help us find what isn't matching.
but the root hash of the unmatched tree is still wrong.
I added more details to block meta, hopefully this will help us find what isn't matching.
Z
01:25
Zack
that didn't work. they really look the same.
01:35
maybe the next step is to freeze a full node at 96043 so I can look up individual merkle proofs to track down what is going wrong.
Z
01:53
Zack
I think we are going to need a hard update to fix this.
The problem is that we are using some information to process the block from the consensus state, but we aren't including proofs with the block.
The problem is that we are using some information to process the block from the consensus state, but we aren't including proofs with the block.
C
01:58
Chris 🍞
Is it mission critical?
Z
01:59
Zack
https://github.com/zack-bitcoin/amoveo/blob/master/apps/amoveo_core/src/consensus/chain/proofs.erl#L300
We calculate U, but then don't include it in the output.
Such a small typo caused this.
We calculate U, but then don't include it in the output.
Such a small typo caused this.
01:59
In reply to this message
it is critical to the mission of being able to sync blocks backwards.
C
02:00
Chris 🍞
In reply to this message
I meant more the mission you have for the blockchains goals you've set at start. sounds like a nice feature to sync backwards though 😆
Z
02:01
Zack
This means we wont be able to verify blocks backwards earlier than height 96044.
So I guess ill just check that the block hash matches the headers for all the earlier blocks than that.
So I guess ill just check that the block hash matches the headers for all the earlier blocks than that.
02:02
well, it will take a couple weeks to do this hard update.
and if anyone does a new_oracle tx between now and then, then we wont be able to sync backwards earlier than whatever height that that tx got included.
and if anyone does a new_oracle tx between now and then, then we wont be able to sync backwards earlier than whatever height that that tx got included.
C
02:03
Chris 🍞
only because the typo in when U is calculated?
Z
02:04
Zack
I forgot to add U to the output at line 313.
02:04
at least it is an easy fix
02:04
one line
C
02:04
Chris 🍞
ghehe funny thing code 😆 always does exactly whats written
Z
02:10
Zack
I guess Amoveo wasn't a stateless full node.
It was only like 99% stateless.
After this update we will be stateless.
It was only like 99% stateless.
After this update we will be stateless.
02:13
@Simon3456 @potat_o
Hard update 27 will activate in about February 9.
Here is documentation about updating https://github.com/zack-bitcoin/amoveo/blob/master/docs/getting-started/updating.md
Hard update 27 will activate in about February 9.
Here is documentation about updating https://github.com/zack-bitcoin/amoveo/blob/master/docs/getting-started/updating.md
C
OK
02:15
O K
Thank you
Z
02:17
Zack
I gave warnings to lolopool, hitbtc, qtrade, and a1 exchange.
I wonder how I should alert gozo exchange?
Is there anyone else I forgot?
I wonder how I should alert gozo exchange?
Is there anyone else I forgot?
02:19
I guess the next programming task is sortition chains.
Z
02:41
Zack
@potat_o sorry for the confusion. I just pushed hard update 27 right now.
I forgot to save the forks.erl file last time.
I forgot to save the forks.erl file last time.
02:44
oh no. now tests aren't passing.
I think I messed up guys. I shouldn't have announced the update yet.
I think I messed up guys. I shouldn't have announced the update yet.
Z
03:01
Zack
it looks like it was a really small bug. it was refusing the generate merkle proofs of non-existant data for the root of the order book in the unmatched tree.
and this hard update requires those kinds of proofs.
and this hard update requires those kinds of proofs.
03:03
@potat_o ok, now hard update 27 is ready.
03:09
http://46.101.185.98:8080/peer_scan.html Here is a page where you can see which full nodes have updated.
OK
03:13
O K
👍 perfect thanks
S
09:43
Sebsebzen
Can somebody explain what’s sortion chain?
Z
09:44
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains.md here is the documentation about sortition chains
09:52
the first app of sortition chains might be a gambling lottery. haha
RICARDO MENEZES invited RICARDO MENEZES
S
12:07
Sebsebzen
Very interesting, Zack
Deleted invited Deleted Account
I
Z
20:49
Zack
I
21:36
Instinct
In reply to this message
👍 I remember he used to follow you on twitter before he unfollowed everyone
Z
23:11
Zack
https://github.com/zack-bitcoin/amoveo-docs/tree/master/failure_reports it has been over 6 months since Amoveo had any major failure. We are becoming more stable.
s
23:27
sanket
That's great to hear
28 January 2020
L N invited L N
Z
06:17
Zack
There are 2 major programming styles.
top-to-bottom. that is where you are building something, and you already know how it will work. Naming conventions are based on the mental model that is easiest to understand. You read the code starting with the things at the top of the page.
bottom-to-top. that is where you are building something, and you don't know how the final product will work. Naming conventions are based on the mental model that has many composable parts. It is like building up a language for making the kinds of programs related to the problem you are solving. You read the code starting with the things at the bottom of the page.
Most programmers are programming something where they know how it will work. Most software is optimized for users, not for researchers.
The kinds of programming languages that are most popular are ones for delivering a final product. languages optimized for the situation where the programmers know what it is that they are building.
Erlang is a language more suited for the bottom to top style. This is something that prevents it from getting very popular, but it is also something very useful for Amoveo development.
If Amoveo did get popular, and we stopped wanting to modifying things so much, we could always re-write it into C or whatever at that point, to get the final 10x speed boost we could get from having a compiled instead of interpreted program.
But for now we are better off having an adaptable code base, rather than being super fast at processing txs.
Our adaptability should help us more quickly achieve layer 2 scaling.
top-to-bottom. that is where you are building something, and you already know how it will work. Naming conventions are based on the mental model that is easiest to understand. You read the code starting with the things at the top of the page.
bottom-to-top. that is where you are building something, and you don't know how the final product will work. Naming conventions are based on the mental model that has many composable parts. It is like building up a language for making the kinds of programs related to the problem you are solving. You read the code starting with the things at the bottom of the page.
Most programmers are programming something where they know how it will work. Most software is optimized for users, not for researchers.
The kinds of programming languages that are most popular are ones for delivering a final product. languages optimized for the situation where the programmers know what it is that they are building.
Erlang is a language more suited for the bottom to top style. This is something that prevents it from getting very popular, but it is also something very useful for Amoveo development.
If Amoveo did get popular, and we stopped wanting to modifying things so much, we could always re-write it into C or whatever at that point, to get the final 10x speed boost we could get from having a compiled instead of interpreted program.
But for now we are better off having an adaptable code base, rather than being super fast at processing txs.
Our adaptability should help us more quickly achieve layer 2 scaling.
06:24
anyway, at this point it is not clear that cpu would be the bottleneck of any financially significant participants in a cryptocurrency network.
A possible advantage of a top-to-bottom rewrite could be that it would be easier for more people to understand how Amoveo works.
for now, I think it is better to optimize for modifiability, until we know we have something good at least.
A possible advantage of a top-to-bottom rewrite could be that it would be easier for more people to understand how Amoveo works.
for now, I think it is better to optimize for modifiability, until we know we have something good at least.
06:34
a climate change prediction market would be good
Z
06:35
Zack
haha, the decentralized thermometer idea is funny.
It is a lot more expensive than Amoveo's oracle.
It is a lot more expensive than Amoveo's oracle.
B
06:35
Beer
oh, i see you already replied to navals tweet
Z
07:34
Zack
There is a lot of complication in the sortition chain design for dividing up a sortition chain's probability space to make 2 on-chain sortition chain objects.
But I think our final design no longer depends on that feature for security?
But I think our final design no longer depends on that feature for security?
07:35
I am going to start out without that feature.
07:45
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_implementation.md im planning out the records for sortition chains.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
18:51
Zack
I made a new branch for sortition chain stuff https://github.com/zack-bitcoin/amoveo/tree/sortition
I set up the records, and I am currently working on the merkle trees.
I set up the records, and I am currently working on the merkle trees.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Z
20:14
Zack
Hi new members.
Say something or be banned.
Say something or be banned.
20:26
oh, I forgot to plan out the records and merkle trees for the random number generator fraud proofs.
20:30
so, every layer you prove takes about 32 bytes.
I figure a person should prove 128 evenly spaced hashes. so it is 4 kilobytes per layer of the fraud proof.
1 second is about 10 million hashes.
1 block is about 10 minutes.
We want the proof to take 20 blocks, so 200 minutes, which is 2 billion hashes.
log128(2 billion) is about 4.5
We also need to handle the case where people spam incorrect info into the fraud proof.
The existence of a incorrect fraud proof does not mean that it is impossible to make a correct fraud proof.
I figure a person should prove 128 evenly spaced hashes. so it is 4 kilobytes per layer of the fraud proof.
1 second is about 10 million hashes.
1 block is about 10 minutes.
We want the proof to take 20 blocks, so 200 minutes, which is 2 billion hashes.
log128(2 billion) is about 4.5
We also need to handle the case where people spam incorrect info into the fraud proof.
The existence of a incorrect fraud proof does not mean that it is impossible to make a correct fraud proof.
w
21:26
wvvw
Fock OK and Destiny have same profile pictures.
29 January 2020
Z
02:58
Zack
I think eventually we will have a rule like, you can't make an account that has less than 1/20 000th of the total supply of veo.
That way we can be sure there will never be more than 20k accounts on-chain.
This will keep the small size of the checkpoint you need to download to sync with the network.
Everyone will store their money in the sortition chains, not on the main chain.
That way we can be sure there will never be more than 20k accounts on-chain.
This will keep the small size of the checkpoint you need to download to sync with the network.
Everyone will store their money in the sortition chains, not on the main chain.
03:07
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_implementation.md
I updated the plan to include txs and merkle trees for calculating the rng.
I updated the plan to include txs and merkle trees for calculating the rng.
03:08
now it looks like we need to add 8 tx types. and 4 merkle trees
m
06:47
mm
Can prediction markets be helpful to prevent/fight pandemics?
Z
06:57
Zack
In reply to this message
yes, good idea for a topic.
It is costly to impose quarantine on people.
People with political power can often get clearance to skip quarantine, putting everyone else at risk.
A prediction market could give us the most accurate possible estimate for the costs and benefits of the various strategies we could use to protect ourselves from pandemics.
It is costly to impose quarantine on people.
People with political power can often get clearance to skip quarantine, putting everyone else at risk.
A prediction market could give us the most accurate possible estimate for the costs and benefits of the various strategies we could use to protect ourselves from pandemics.
06:58
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chains_implementation.md
I added RNG generation to the timeline of a sortition chain's life cycle.
I added RNG generation to the timeline of a sortition chain's life cycle.
06:59
I think I might have a problem with the rng challenge response process.
Z
09:01
Zack
ok, I think I got the design done.
next ill focus on getting the 4 merkle trees working.
next ill focus on getting the 4 merkle trees working.
Z
10:16
Zack
I think those updates we had to do to the merkle trees to enable backwards syncing, they are going to be very useful for implementing sortition chains.
Because now it is easy to make small stand-alone merkle trees while processing blocks.
We can make a little tree for all 129 verified random number generator checkpoints.
Because now it is easy to make small stand-alone merkle trees while processing blocks.
We can make a little tree for all 129 verified random number generator checkpoints.
Deleted joined group by link from Group
Z
20:27
Zack
I ran into another issue with sortition chains.
Example. I am trying to move my money from one sortition chain into another.
I hash lock the 2 payments together.
But then, my partner changes their mind, and refused to reveal the secret, so the payment is not executed.
Now if I try to spend the Veo, people will see the hash locked payment, and they will think that I have already spent the money, that I am just pretending that the secret was never revealed and that I still have the money.
Example. I am trying to move my money from one sortition chain into another.
I hash lock the 2 payments together.
But then, my partner changes their mind, and refused to reveal the secret, so the payment is not executed.
Now if I try to spend the Veo, people will see the hash locked payment, and they will think that I have already spent the money, that I am just pretending that the secret was never revealed and that I still have the money.
20:28
I feel like we solved this before, and I forgot the solution
20:32
Maybe the revealed secret needs to be included in one of the root states that all the validators sign over?
But there are 2 sortition chains involved. What if the validators only include the secret for one of the two?
But there are 2 sortition chains involved. What if the validators only include the secret for one of the two?
20:35
Maybe we should only have contracts for giving up control of part of the probabilistic value state.
And not have contracts for assigning control.
But then, how can we properly handle the case where they refuse to reveal a secret?
If they are next in line to own your value, then it seems like they are the only one who you can spend your value to.
And not have contracts for assigning control.
But then, how can we properly handle the case where they refuse to reveal a secret?
If they are next in line to own your value, then it seems like they are the only one who you can spend your value to.
A
Z
20:59
Zack
if we had timeouts on each sortition chain, so like, you need to get the unlocking secret included in the sortition chain before the time runs out.
What if one set of sortition chain operators cooperates to include the secret, and the other does not?
If we allow secrets on one sortition chain to count for the other sortition chains, it makes it much more expensive to use them.
Because verifying that a secret has not been revealed is as expensive as syncing with all existing sortition chains.
What if one set of sortition chain operators cooperates to include the secret, and the other does not?
If we allow secrets on one sortition chain to count for the other sortition chains, it makes it much more expensive to use them.
Because verifying that a secret has not been revealed is as expensive as syncing with all existing sortition chains.
21:01
one option is to have all secrets revealed on the main chain.
But that would come with serious anti-scalability consequences.
But that would come with serious anti-scalability consequences.
21:09
maybe we can have a multi-step process.
Kind of like how if the participants in a state channel agree on the final outcome, they can simplify it at the end.
Maybe we can transition through an expensive state where a secret could potentially need to go on the main-chain, but then to save money they cooperate to finish in a state where nothing could need to go on the main-chain.
Kind of like how if the participants in a state channel agree on the final outcome, they can simplify it at the end.
Maybe we can transition through an expensive state where a secret could potentially need to go on the main-chain, but then to save money they cooperate to finish in a state where nothing could need to go on the main-chain.
21:20
for example, lets say that I are the one who will reveal the secret.
I ask the operators of my sortition chain (called A) to make a tx that puts you next in line to own my value, but the tx is only valid if a secret is revealed on the main-chain before an expiration date, otherwise the value goes back to me. I am third in line as well as first.
You ask the operators of your sortition chain (called B) to make a tx to put me next in line to own your value, if the secret is revealed on the main chain before the expiration, otherwise it goes back to you, you are third in line as well as first.
I give up my spot as first in line.
You give up your spot as first in line.
I reveal the secret.
Now I am first in line on sortition chain B, as long as I have the secret to prove ownership, and you are first in line on my sortition chain A, as long as you have the secret.
So I ask the sortition chain B operators to make me third in line, and you ask the sortition chain A operators to make you third in line.
Then we both give up our 2nd in line spots.
Now we both have ownership on the correct side, and we don't need to publish any secret to the main chain.
I ask the operators of my sortition chain (called A) to make a tx that puts you next in line to own my value, but the tx is only valid if a secret is revealed on the main-chain before an expiration date, otherwise the value goes back to me. I am third in line as well as first.
You ask the operators of your sortition chain (called B) to make a tx to put me next in line to own your value, if the secret is revealed on the main chain before the expiration, otherwise it goes back to you, you are third in line as well as first.
I give up my spot as first in line.
You give up your spot as first in line.
I reveal the secret.
Now I am first in line on sortition chain B, as long as I have the secret to prove ownership, and you are first in line on my sortition chain A, as long as you have the secret.
So I ask the sortition chain B operators to make me third in line, and you ask the sortition chain A operators to make you third in line.
Then we both give up our 2nd in line spots.
Now we both have ownership on the correct side, and we don't need to publish any secret to the main chain.
21:22
So it seems like we for sure need contracts on the txs that assign ownership to someone.
Do we also need contracts on the txs where someone is giving up ownership of some value?
Do we also need contracts on the txs where someone is giving up ownership of some value?
21:35
Technically, we don't need hashlocking at all.
We could do the strategy where we simultaneously stream micro-payments on both sides at once.
But the bandwidth overhead for that strategy is like 100x worse, so it would be nice to use hashlocking if it is possible.
We could do the strategy where we simultaneously stream micro-payments on both sides at once.
But the bandwidth overhead for that strategy is like 100x worse, so it would be nice to use hashlocking if it is possible.
Z
22:31
Zack
we should make a plan for markets with single price batches now, to be sure it is possible with this design.
22:36
Do batches need to all be in the same sortition chain? Or can we have large markets that include multiple sortition chains?
22:36
Do the sortition operators need to be the same as the order book operator?
Z
23:59
Zack
yeah, I think we can do that same hashlocking trick above to update all the sortition chains.
instead of revealing a secret, the operator is revealing the price of the next batch.
instead of revealing a secret, the operator is revealing the price of the next batch.
30 January 2020
Paul Natt - 2536971 invited Paul Natt - 2536971
GJ
04:28
Guillermo Joya
Hello guys. What’s happening with everybody today ?
Z
04:31
Zack
this is a place to talk about Amoveo.
GJ
04:31
Guillermo Joya
Yes sorry about that Zack
Z
04:58
Zack
It is kind of interesting.
a single solution to the verified random number generator, it has 129 hashes that are evenly spaced checkpoints along the process of computing the RNG.
If only one person publishes an attempted solution, it is expensive to verify (if you lack gpu). Each of the 128 gaps between the hashes is time consuming to verify.
But if 2 people publish solutions that differ from each other, it is very cheap for anyone to confirm that at least one of them has lied.
You simply look at the first of the 128 gaps where the solutions are different.
You only need to computer that single gap on your cpu, which can be done in a few minute.
This will prove that one of the 2 attempted solutions to the rng puzzle was incorrect.
a single solution to the verified random number generator, it has 129 hashes that are evenly spaced checkpoints along the process of computing the RNG.
If only one person publishes an attempted solution, it is expensive to verify (if you lack gpu). Each of the 128 gaps between the hashes is time consuming to verify.
But if 2 people publish solutions that differ from each other, it is very cheap for anyone to confirm that at least one of them has lied.
You simply look at the first of the 128 gaps where the solutions are different.
You only need to computer that single gap on your cpu, which can be done in a few minute.
This will prove that one of the 2 attempted solutions to the rng puzzle was incorrect.
Deleted invited Deleted Account
Z
06:47
Zack
I made first drafts for all 4 of the new merkle trees we will need.
Now we are at the fun part.
implementing txs.
For now I am just making a rough first draft. Then we can do some testing and modifications before we merge.
There are 8 txs to make, I am guessing it will take me about 2-3 days for each one. and an extra 4 days to hook up the smart contract system to the sortition_claim tx.
If it turns out sortition_evidence also needs smart contracts, that would probably be an extra 4 days as well.
Now we are at the fun part.
implementing txs.
For now I am just making a rough first draft. Then we can do some testing and modifications before we merge.
There are 8 txs to make, I am guessing it will take me about 2-3 days for each one. and an extra 4 days to hook up the smart contract system to the sortition_claim tx.
If it turns out sortition_evidence also needs smart contracts, that would probably be an extra 4 days as well.
GJ
06:56
Guillermo Joya
Thanks Zack for everything you do
Z
07:08
Zack
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/txs/sortition_new_tx.erl here is the first tx. It is only loading info, so very simple.
the new trees are in this folder https://github.com/zack-bitcoin/amoveo/tree/sortition/apps/amoveo_core/src/consensus/trees
sortition, candidates, rng_challenge, rng_response
the new trees are in this folder https://github.com/zack-bitcoin/amoveo/tree/sortition/apps/amoveo_core/src/consensus/trees
sortition, candidates, rng_challenge, rng_response
Z
07:26
Zack
first draft of rng_response tx https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/txs/rng_result_tx.erl
Z
08:19
Zack
So, I had wanted to make the tree and order of txs like:
sortition -> response -> challenge -> response -> challenge ... -> challenge.
but maybe we need a 4th data type and tx type. the rng_result_tx
sortition -> result -> challenge -> response -> challenge -> response ...
it goes between sortition and the first challenge.
This tx is different, because it is where the person offering up this suggested rng result makes a deposit as a claim that they can solve any challenges about this result.
sortition -> response -> challenge -> response -> challenge ... -> challenge.
but maybe we need a 4th data type and tx type. the rng_result_tx
sortition -> result -> challenge -> response -> challenge -> response ...
it goes between sortition and the first challenge.
This tx is different, because it is where the person offering up this suggested rng result makes a deposit as a claim that they can solve any challenges about this result.
08:23
In reply to this message
Another way of saying this:
As long as someone provides the correct answer, it will be cheap for anyone to verify that it is more correct than an alternative incorrect answer, it will be cheap for anyone to create challenges to expose their lie.
As long as someone provides the correct answer, it will be cheap for anyone to verify that it is more correct than an alternative incorrect answer, it will be cheap for anyone to create challenges to expose their lie.
08:24
So I was thinking of working under the security model that someone cares enough about the result to spend the $0.10 to calculate the rng correctly.
And their evidence makes it cheap for us to know that everyone else's claims are lies.
And their evidence makes it cheap for us to know that everyone else's claims are lies.
Z
08:41
Zack
maybe it should be 1 tx, but 2 merkle trees?
Z
08:58
Zack
so im thinking ill take all the rng_results for one sortition chain, ill make them as a linked list, and have the sortition chain point at the head.
This way if you are trying to submit an honest result, you only need to take care of those who are ahead of you in line, not behind you.
This way if you are trying to submit an honest result, you only need to take care of those who are ahead of you in line, not behind you.
08:58
having it all connected this way could potentially make garbage collecting at the end of a sortition chain a lot cleaner
A
10:03
Asindu
Hi
10:03
Zack
10:03
I was thinking of something
10:04
Is it possible to use your state channels to do cross chain interoperability?
Z
15:10
Zack
In reply to this message
Yes, but we don't have tooling or a Web page to make it simple yet.
Z
16:13
Zack
In reply to this message
Another simplification we can do.
the rng_challenge and rng_response data structures come in pairs.
every challenge can only have one response at most.
but a response can have many challenges.
So I think we can combine the 2 merkle trees into 1.
the rng_challenge and rng_response data structures come in pairs.
every challenge can only have one response at most.
but a response can have many challenges.
So I think we can combine the 2 merkle trees into 1.
A
18:24
Asindu
In reply to this message
What’s wrong with having participants generate a cryptographically secure a random number.
And then sharing it via a game?
For instance you can tell a group of participants to generate a
hashlock where the secret X has to be a CSRN(or else it can be brute forced & their money stolen)
We can also add a time lock for let’s say 1 week. This would mean that brute forcers genuinely have enough time to find the X if it is not a CSRN
We can then gather a list of these hash locks from multiple participants. And then randomly truncate it to to which ever length we desire.
We can pay them a fee for doing this or we can add it to the protocol. The way you added oracles?
And then sharing it via a game?
For instance you can tell a group of participants to generate a
hashlock where the secret X has to be a CSRN(or else it can be brute forced & their money stolen)
We can also add a time lock for let’s say 1 week. This would mean that brute forcers genuinely have enough time to find the X if it is not a CSRN
We can then gather a list of these hash locks from multiple participants. And then randomly truncate it to to which ever length we desire.
We can pay them a fee for doing this or we can add it to the protocol. The way you added oracles?
Z
18:54
Zack
The problem with commit reveal schemes is that whoever reveals last has the option to not reveal. This gives them one bit of control over the randomness that gets revealed.
18:56
The strategy we are currently planning on using is a lot cheaper than your suggestion.
We only need one person to publish the result in one tx.
What you are suggesting sounds like it involves multiple people making multiple txs each.
We only need one person to publish the result in one tx.
What you are suggesting sounds like it involves multiple people making multiple txs each.
31 January 2020
A
02:28
Asindu
In reply to this message
Yes. That's true.
But they get to take their transactions back.
But they get to take their transactions back.
Z
05:29
Zack
It looks like we will need a bunch of new governance parameters for sortition stuff
Z
09:07
Zack
In reply to this message
I combined those 2 into a single thing, and called it "rng_challenge"
I made the rng_result tree
and I implemented more of the txs. https://github.com/zack-bitcoin/amoveo/commit/4b322a522e423a67a4ed4fdb7777ac7d4a345f80
I made the rng_result tree
and I implemented more of the txs. https://github.com/zack-bitcoin/amoveo/commit/4b322a522e423a67a4ed4fdb7777ac7d4a345f80
Z
17:30
Zack
https://twitter.com/VitalikButerin/status/1223164287624986625?s=20 According to Vitalik's definition, sortition chains are a kind of "plasma".
Maybe we should call them "the plasma lottery".
Maybe we should call them "the plasma lottery".
Z
20:46
Zack
https://github.com/zack-bitcoin/amoveo/commit/fb97c24f7b91a3a6a76ec8c852d152577f84c1da I set up a bunch of new governance variables, and I wrote a test for one of the new tx types.
There are some advantages to having hard forks littered around the codebase.
If I need to remember how to add new governance variables for example, I can just look up the last hard update where we added a governance variable.
There are some advantages to having hard forks littered around the codebase.
If I need to remember how to add new governance variables for example, I can just look up the last hard update where we added a governance variable.
Z
21:08
Zack
how about if we rename Amoveo to "shitcoin"?
ŽM
21:31
Živojin Mirić
it would be great for marketing
A
Z
22:53
Zack
I made a test for rng_challenge_tx.
now 3 of the 11 txs have tests.
now 3 of the 11 txs have tests.
22:57
I am guessing that the sortition_claim_tx is going to be at least 1/2 the effort of this hard update.
Because that is where we need to hook up the virtual machine.
Because that is where we need to hook up the virtual machine.
1 February 2020
MF
00:09
Mr Flintstone
lol
Hardik invited Hardik
Z
17:03
Zack
I made a test for rng_confirm_tx.
That finishes the first draft of all 5 txs needed for generating the RNG we will use for sortition chains.
I am planning on making a couple more RNG tx types for cleaning up unneeded data from the consensus state.
That finishes the first draft of all 5 txs needed for generating the RNG we will use for sortition chains.
I am planning on making a couple more RNG tx types for cleaning up unneeded data from the consensus state.
Z
17:50
Zack
That extra tool we made to double-check that coins never get duplicated.
It is so nice.
It makes the task of writing new txs far easier. Because I know it is impossible to duplicate money, so I can focus better on everything else.
One less thing to worry about.
It should give us some peace of mind when we merge this massive hard update to enable sortition chains.
If it breaks, at worst it can only destroy money of people who choose to try out the new features.
It can't cause inflation.
It is so nice.
It makes the task of writing new txs far easier. Because I know it is impossible to duplicate money, so I can focus better on everything else.
One less thing to worry about.
It should give us some peace of mind when we merge this massive hard update to enable sortition chains.
If it breaks, at worst it can only destroy money of people who choose to try out the new features.
It can't cause inflation.
17:51
I guess the next task is to make a first draft of the sortition claim tx.
Probably this tx will be the most time consuming part of the hard update.
Probably this tx will be the most time consuming part of the hard update.
Deleted invited Deleted Account
2 February 2020
Z
05:04
Zack
I am going to start by only allowing 1 layer of sortition chains, then I will upgrade it to have baby sortition chains inside of the sortition chains.
05:14
one thing we haven't planned out well enough is how to put merkle roots of the sortition ownership state onto the main chain.
We need it to be possible for someone who is joining the sortition chain to know that he has the entire history of a particular coin, just by verifying merkle proofs against main-chain roots.
it seems like the current proof of existence tx type might not solve the problem we need to solve.
Maybe we need something where all the validators from a single sortition chain sign a single tx, and the existence of one hash gets recorded to the blockchain.
So if you know the list of validators for a sortition chain, you can look up the merkle roots of all the times that that list of validators had recorded the root to the main chain.
We need it to be possible for someone who is joining the sortition chain to know that he has the entire history of a particular coin, just by verifying merkle proofs against main-chain roots.
it seems like the current proof of existence tx type might not solve the problem we need to solve.
Maybe we need something where all the validators from a single sortition chain sign a single tx, and the existence of one hash gets recorded to the blockchain.
So if you know the list of validators for a sortition chain, you can look up the merkle roots of all the times that that list of validators had recorded the root to the main chain.
05:16
I think we are not using the proof of existence tx for anything else, so I might as well upgrade it to have these capabilities.
05:31
In reply to this message
We want computation to be a lazy as possible, leave it all until the sortition_claim_tx if possible.
We don't want to do extra main-chain computation for every side-chain-block.
We don't want to do extra main-chain computation for every side-chain-block.
Z
05:56
Zack
I think we need to verify all the validator signatures before we can store their hash.
otherwise it is not possible for someone who is syncing a sidechain to know if they have all the data or not.
otherwise it is not possible for someone who is syncing a sidechain to know if they have all the data or not.
05:57
this implies that the on-chain cost of a sortition chain is (number of validators)*(number of side-blocks in that sortition chain).
05:58
I wonder if this means that there is going to be lots of sortition chains with few validators each, rather than fewer with many validators each?
06:02
Probably we can use ring-signatures to reduce the on-chain cost to being a single signature per side-block.
Z
06:17
Zack
if the same group of validators is managing multiple sortition chains, maybe we can merge their commitments together.
06:19
maybe instead of signing with a validator private key directly, a validator can assign a signator for themselves. So that signator can sign on their behalf.
That way they don't need to leave their high valued private key on a single machine's hot wallet.
They can divide up the risk between many different machines that each manage different sortition chains.
That way they don't need to leave their high valued private key on a single machine's hot wallet.
They can divide up the risk between many different machines that each manage different sortition chains.
06:19
like how delegated proof of stake works.
06:20
I think I am going to start us off with something simple that can be upgraded, and not try to make it perfect to start.
Z
07:57
Zack
instead of adapting the proof_of_existence_tx, I just made a new tx type and merkle tree for holding sortition chain commits.
I think the proof of existence tool might be useful for some oracle stuff eventually.
I think the proof of existence tool might be useful for some oracle stuff eventually.
07:58
What is nice about this dedicated data structure, is that I can have it easily scroll through the commits for a single sortition chain, which will make it easy to sync with sortition chains eventually.
Scandalnavia invited Scandalnavia
Z
21:35
ranking back end software devs from noob to Satoshi.
Z
21:56
Zack
one thing we need for sortition chains is a merkle database where the portion of the probability space that you control is the key to look up your data from the tree.
We want it to be the case that a merkle proof of your data is also a proof that no one else was assigned an overlapping region of the probability space.
We want it to be the case that a merkle proof of your data is also a proof that no one else was assigned an overlapping region of the probability space.
21:57
Maybe the key should be the beginning of the region that you control, and we also include a proof of whoever owns the next continuous region, and we prove that these 2 entrees are adjacent, with no other entree between them.
21:58
oh right, we were going to put little smart contracts at every step of verifying the merkle proof
22:01
putting a smart contract at every step would be a pretty complicated solution.
Showing that the next continuous region is non-overlapping would be a lot simpler, if it is possible.
Showing that the next continuous region is non-overlapping would be a lot simpler, if it is possible.
Z
22:17
Zack
yeah, it seems doable.
Lets say you own from 0 -> 1/8th
then the layer1 stem would be
{you, empty, _,_,_,_,_,_,_,_,_,_,_,_,_,_}
The first 2 of the 16 entrees control 1/8th of the total space.
So if your entree starts at 0, and the it is empty up till 1/8th, then you can know that there is no overlap.
Lets say you own from 0 -> 1/8th
then the layer1 stem would be
{you, empty, _,_,_,_,_,_,_,_,_,_,_,_,_,_}
The first 2 of the 16 entrees control 1/8th of the total space.
So if your entree starts at 0, and the it is empty up till 1/8th, then you can know that there is no overlap.
22:18
we might have to encode the keys a little weird to make sure that probability space lines up this way, but it shouldn't be very difficult.
3 February 2020
Z
06:03
Zack
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/txs/sortition_claim_tx.erl
I got the first draft of the sortition claim tx done.
It doesn't support baby sortition chains yet.
I got the first draft of the sortition claim tx done.
It doesn't support baby sortition chains yet.
ŽM
06:12
Živojin Mirić
Ok, thx
Z
08:59
Zack
I wrote a passing test for the new sortition claim tx.
09:07
the rest of the txs are simple.
one to provide evidence that a sortition chain can't close that way.
one to show that a timer ran out, so the sortition chain can be settled.
and a couple to clean up old unneeded data from the consensus state.
The next step will be to go over the txs more carefully and double-check that they are all secure.
and then we can make more tests and add baby-sortition-chains.
one to provide evidence that a sortition chain can't close that way.
one to show that a timer ran out, so the sortition chain can be settled.
and a couple to clean up old unneeded data from the consensus state.
The next step will be to go over the txs more carefully and double-check that they are all secure.
and then we can make more tests and add baby-sortition-chains.
Andy invited Andy
Z
17:01
Zack
In reply to this message
I think this plan has a flaw.
It is only preventing overlaps that start inside the range I own.
It doesn't prevent overlaps that start before my range.
It is only preventing overlaps that start inside the range I own.
It doesn't prevent overlaps that start before my range.
17:05
So, one option is to entirely fill up the tree.
We only divide the probabilistic value space up into 2^32 parts.
So if you own 1/8th of the total sortition chain's value, there are only 2^29 different RNG values that would result in you winning.
For all 2^29 locations in the merkel tree, we can insert your pubkey.
This sounds expensive, but since it is so repetitive we can collapse most of the work on itself.
It would only cost like ~128 sha256 hashes to fill up a region completely with the owner's pubkey.
And if one RNG value is containing my pubkey, it can't possibly also contain someone else's pubkey at the same time.
We only divide the probabilistic value space up into 2^32 parts.
So if you own 1/8th of the total sortition chain's value, there are only 2^29 different RNG values that would result in you winning.
For all 2^29 locations in the merkel tree, we can insert your pubkey.
This sounds expensive, but since it is so repetitive we can collapse most of the work on itself.
It would only cost like ~128 sha256 hashes to fill up a region completely with the owner's pubkey.
And if one RNG value is containing my pubkey, it can't possibly also contain someone else's pubkey at the same time.
17:12
another option is that syncing with a sortition chain would require downloading the entire merkel state tree of every sortition-block where your coins were spent.
Ideally we would want a person to only need to download the merkel proofs of the coins they personally control.
Ideally we would want a person to only need to download the merkel proofs of the coins they personally control.
17:20
Another option is to ditch the normal merkel tree library, and make a customized merkel datastructure for claiming and proving claims of probabilistic value space.
17:26
we could have a binary merkel tree, where every step of the tree says how the probabilistic value space is divided between the two child branches. Then walking down a path could give you certainty that there is no overlap.
This option would probably have the least computation and bandwidth requirements.
We want the same team of validators to be able to manage multiple sortition chains, and use a single merkel root to commit to updates on the different sortition chains simultaneously.
So the custom merkel tree might first be keyed by the sortition IDs, and the leafs of that tree will start new smaller merkel trees that are keyed by non-overlapping ranges of probabilistic value space.
This option would probably have the least computation and bandwidth requirements.
We want the same team of validators to be able to manage multiple sortition chains, and use a single merkel root to commit to updates on the different sortition chains simultaneously.
So the custom merkel tree might first be keyed by the sortition IDs, and the leafs of that tree will start new smaller merkel trees that are keyed by non-overlapping ranges of probabilistic value space.
Z
18:38
Zack
There is another property we would like to have.
Let's say a particular part of the probability space got divided up into a btc stablecoin and long Veo.
Now both the stablecoin owner and the long-veo owner would like to spend their coins at the same time.
But this would mean that the validators need to include 2 different pubkeys at the same blockheight for the same part of the probability space.
But the with the design we were currently discussing, this would be impossible.
Let's say a particular part of the probability space got divided up into a btc stablecoin and long Veo.
Now both the stablecoin owner and the long-veo owner would like to spend their coins at the same time.
But this would mean that the validators need to include 2 different pubkeys at the same blockheight for the same part of the probability space.
But the with the design we were currently discussing, this would be impossible.
18:40
So maybe we should embed tiny chalang smart contracts in every step.
The smart contract could specify which sortition chain we are using, which part of the range of probability space it is about, and whether it is for stablecoins or Veo or anything.
The smart contract could specify which sortition chain we are using, which part of the range of probability space it is about, and whether it is for stablecoins or Veo or anything.
18:41
Smart contracts are a very adaptable strategy as well.
Z
19:13
Zack
There is this board game called "Guess Who?"
Where there are all these little pictures of people. Your opponent picks one of the people.
and you ask yes/no questions to try and narrow down which of the people they had chosen.
So the strategy is to try and ask a question such that 1/2 the people would be "yes", and 1/2 would be "no". that way, no matter what the answer is, you can eliminate 1/2 the suspects.
building up these merkle trees is going to be similar.
In order to minimize the length of any individual merkel proof, we want the tree to be balanced.
To make a balanced tree, we need to keep choosing questions such that 1/2 of the elements we need to put in the tree are "yes", and 1/2 are "no".
Where there are all these little pictures of people. Your opponent picks one of the people.
and you ask yes/no questions to try and narrow down which of the people they had chosen.
So the strategy is to try and ask a question such that 1/2 the people would be "yes", and 1/2 would be "no". that way, no matter what the answer is, you can eliminate 1/2 the suspects.
building up these merkle trees is going to be similar.
In order to minimize the length of any individual merkel proof, we want the tree to be balanced.
To make a balanced tree, we need to keep choosing questions such that 1/2 of the elements we need to put in the tree are "yes", and 1/2 are "no".
Juliany invited Juliany
Z
21:11
Zack
embedding chalang scripts inside a merkel tree is pretty intense, but it seems doable.
I feel like this tool might be useful for more things in the future. It seems really powerful to have turing complete programs at every node of the merkel tree, to tell you which path to follow.
I feel like this tool might be useful for more things in the future. It seems really powerful to have turing complete programs at every node of the merkel tree, to tell you which path to follow.
Z
21:26
Zack
https://github.com/zack-bitcoin/amoveo/blob/sortition/apps/amoveo_core/src/consensus/trees/ownership2.erl
I started planning out what a merkel tree with contracts embedded in it would look like.
I started planning out what a merkel tree with contracts embedded in it would look like.
4 February 2020
Z
06:29
Zack
putting full turing complete contracts at every step of the merkel proof seems excessive, I think we can get away with doing less.
I am planning to have 3 types of stem nodes in the new merkel tree.
sid, before, contract.
This node just checks if the contract hashes match. if they do, it is stored on the left. if they don't match, it is stored on the right.
This allows us to separate the merkel proof verification from actually running the smart contracts, which is important for preventing certain denial of service attacks.
I am planning to have 3 types of stem nodes in the new merkel tree.
sid, before, contract.
sid type nodes use the Sortition ID, which is the id that says which sortition chain your ownership contract is for. If your SID in your ownership contract is the same as the SID written on that merkel stem, then your contract is stored on the left side. If it is different, then it is stored on the right side.before type nodes look at the probability space that this ownership contract gives you control over. if your range is before the split point, then your contract is stored to the left, if it is after, then it is stored to the right.contract type nodes look at the hash of the smart contract that you have agreed to participate in. it could be the hash of a stablecoin smart contract for example.This node just checks if the contract hashes match. if they do, it is stored on the left. if they don't match, it is stored on the right.
This allows us to separate the merkel proof verification from actually running the smart contracts, which is important for preventing certain denial of service attacks.
06:40
maybe for
contract instead of checking if the contracts are an exact match, I should make an order of all possible hashes, so I can calculate if one contract hash is "before" or "after" another. That way we can have more ways to try and divide the contracts evenly between the 2 branches.
06:41
so, I guess ill make 5 stem types for the new merkel tree.
sid, sid_before, prob_before, contract, contract_before
sid, sid_before, prob_before, contract, contract_before
Z
07:30
Zack
In reply to this message
so, that strategy is using the incorrect assumption that different contract hashes are all mutually exclusive.
What we want is for the stem to say, the opposite of some other contract. whatever that other contract does, this is the opposite.
What we want is for the stem to say, the opposite of some other contract. whatever that other contract does, this is the opposite.
07:31
Maybe for the opposite I should store the additive inverse of the contract hash. so I can just add them together and see if it makes 0.
Z
08:57
Zack
I wrote a passing test for ownership2.
I haven't made code to generate merkel proofs in the case of smart contracts, like stablecoins.
It only supports generating proofs of holding veo.
but it can verify all kinds of proofs.
It also supports generating proofs for different sortition chains using a single merkel hash, if a single team of validators is managing more than one sortition chain.
I haven't made code to generate merkel proofs in the case of smart contracts, like stablecoins.
It only supports generating proofs of holding veo.
but it can verify all kinds of proofs.
It also supports generating proofs for different sortition chains using a single merkel hash, if a single team of validators is managing more than one sortition chain.
Z
19:40
Zack
I think optimally packing ownership evidence into a Merkel tree this way is an example of the knapsack problem. The ideal solution is too expensive, so we need to use good-enough approximations.
Z
21:14
Zack
800 blocks until the hard update. around 5 or 6 days.
d
Z
21:16
Zack
oh, it is supposed to be "merkle".
I mess up on that one so much
I mess up on that one so much
21:18
is hitbtc working?
I thought they have been blocking withdraws for months now.
I thought they have been blocking withdraws for months now.
21:20
I think hitbtc is a scam.
They make the price look low so people deposit BTC, and then they never let you withdraw.
They make the price look low so people deposit BTC, and then they never let you withdraw.
5 February 2020
Z
07:31
Zack
the new tree is dividing across value probability space fine now, but im struggling to get it to divide across the different possible sortition_id values.
Z
07:49
Zack
oh, looks like the problem isn't the sortition_id nodes, it is if the proof has more than 1 stem in it.
Z
08:20
Zack
I made passing tests for both SID splitting, and probabilistic space splitting.
S
13:12
Sebsebzen
Is the VEO buy/sell telegram bot still working?
X
Z
21:01
Zack
I heard bitcoin has had 1/2 billion txs so far.
A global blockchain would need to process at least 8 billion per day. One for each human.
A global blockchain would need to process at least 8 billion per day. One for each human.
Deleted invited Deleted Account
DK
22:03
Deve Kliman
I am not sure I remember a day I’ve conducted fewer than 10
Z
22:04
Zack
wow, you are a heavy user. Why do you need to make so many bitcoin txs?
DK
22:05
Deve Kliman
Not of btc lol although I did 2 today... just any kind of financial transactions whatsoever
Z
22:05
Zack
oh, right
22:06
I think I use money about once in 3 days. haha
DK
22:06
Deve Kliman
If something is to become the money... yeah I’d imagine a trillion or more per hour? Especially with video games?
22:07
Ok maybe that’s much but what counts as a transaction in a video game?
22:07
I wonder how many packets are transmitted online per day
Z
22:08
Zack
I think with most video games, people tend to buy a bunch of in-game tokens, and then use those for purchases over time.
I suspect that even if we could support 100 tx per day per person, that we could still create a lot of value by increasing it to 1000 tx per day per person.
I suspect that even if we could support 100 tx per day per person, that we could still create a lot of value by increasing it to 1000 tx per day per person.
22:09
if we could have 1000 payments per person, per day, I bet people will start finding ways to use money that we couldn't even think of today.
DK
22:09
Deve Kliman
I suppose there are billions who have few transactions at all
22:10
I suppose it can become tiring to have so many tx
Z
DK
22:15
Deve Kliman
And this isn’t even with star link yet
Z
22:16
Zack
looks like more than 1 zetabyte per year
DK
22:19
Deve Kliman
Exponentially increasing
22:20
Or does it become an n(1-n) sort of thing eventually... I don’t think we have approached constraints yet though
Z
22:47
Zack
it seems like even once a person is already online, the amount of bandwidth they consume per year keeps increasing exponentially.
DK
22:50
Deve Kliman
A healthy Internet is one where users are also sending...
22:50
Not just leeching
6 February 2020
G
ŽM
04:43
Živojin Mirić
Please reminder when amoveo 1000$ thx
Z
08:59
Zack
http://46.101.185.98:8080/peer_scan.html more than half the nodes are ready for update 27.
Z
09:34
Zack
In reply to this message
the atomic swap protocol we discussed a few days ago, it requires at least 2 on-chain confirmations.
First we wait for sortition chain A to update for you to be second in line to own my money, then we wait for sortition chain B to update for me to be second in line to own your value.
If we already had state channels set up, then we could do the same thing instantly, with zero on-chain confirmations.
If we didn't already have state channels set up, but we wanted to use channels for this atomic swap, we would need to wait at least one confirmation to put our money into the channel, and at least one more to take our money out of the channel at the end.
This is worse than sortition chains because of the quantity of data that goes on-chain. But is is equally costly as far as how much time it takes to accomplish the operation.
There is a fundamental trade-off between capital lockup costs of having your money inside channels, vs the time cost of waiting for a confirmation to get recorded on the chain.
I wonder if it is possible to overcome this limit.
Maybe we can have sortition operators pre-agree on facts about the next sortition root they will record on the main chain?
First we wait for sortition chain A to update for you to be second in line to own my money, then we wait for sortition chain B to update for me to be second in line to own your value.
If we already had state channels set up, then we could do the same thing instantly, with zero on-chain confirmations.
If we didn't already have state channels set up, but we wanted to use channels for this atomic swap, we would need to wait at least one confirmation to put our money into the channel, and at least one more to take our money out of the channel at the end.
This is worse than sortition chains because of the quantity of data that goes on-chain. But is is equally costly as far as how much time it takes to accomplish the operation.
There is a fundamental trade-off between capital lockup costs of having your money inside channels, vs the time cost of waiting for a confirmation to get recorded on the chain.
I wonder if it is possible to overcome this limit.
Maybe we can have sortition operators pre-agree on facts about the next sortition root they will record on the main chain?
09:35
I can't see how we can recover anything if the sortition operators lie in a pre-agreement.
09:49
If an atomic swap involves having 2 participants online for 6 confirmations*2 = 12 confirmations = about 2 hours...
That seems like a significant cost.
If we use channels inside the sortition chain, then each person can do their 2 hours when it convenient for them, and then trade instantly.
As long as some 3rd party middle-men are willing to take the other side of the channels and lock up significant capital.
At any time, at most 1/2 the money in the sortition chain is usable for making smart contracts, and it takes 2 hours to reshuffle the money to make a different part of it available for smart contracts.
Do we really need to wait 6 confirmations after a sortition chain root is recorded?
undoing a sortition chain confirmation would require getting all N of the validators to sign a contradictory update, and also re-mining a block.
That is even harder to achieve than a data-availability attack.
That seems like a significant cost.
If we use channels inside the sortition chain, then each person can do their 2 hours when it convenient for them, and then trade instantly.
As long as some 3rd party middle-men are willing to take the other side of the channels and lock up significant capital.
At any time, at most 1/2 the money in the sortition chain is usable for making smart contracts, and it takes 2 hours to reshuffle the money to make a different part of it available for smart contracts.
Do we really need to wait 6 confirmations after a sortition chain root is recorded?
undoing a sortition chain confirmation would require getting all N of the validators to sign a contradictory update, and also re-mining a block.
That is even harder to achieve than a data-availability attack.
09:52
The data-availability attack isn't directly profitable the way a double-spend attack is.
the data-availability attack just freezes the sortition chain, and causes everyone to take on lottery risk. So it is a loss for everyone participating in that sortition chain.
a double-spend attack can steal from one person, and give to another. It is profitable for someone.
Whoever is profiting could bribe the validators to make it happen.
So maybe we do need 6 confirmations.
the data-availability attack just freezes the sortition chain, and causes everyone to take on lottery risk. So it is a loss for everyone participating in that sortition chain.
a double-spend attack can steal from one person, and give to another. It is profitable for someone.
Whoever is profiting could bribe the validators to make it happen.
So maybe we do need 6 confirmations.
09:58
I am thinking of making a different kind of content. I will record a phone call between me and a beginner.
I will teach them about some basic part of cryptocurrency or Amoveo.
The Amoveo podcast.
I will teach them about some basic part of cryptocurrency or Amoveo.
The Amoveo podcast.
C
13:11
Craig
You could also consider appearing on an established podcast
A phonecall with a complete beginner could turn out great, but in terms of production value alone a semi professional podcast might be worth it
A phonecall with a complete beginner could turn out great, but in terms of production value alone a semi professional podcast might be worth it
OK
18:27
O K
In reply to this message
Animation
Not included, change data exporting settings to download.
343.3 KB
18:27
Yes, do this. The enemy of good is perfect, right?
WL
I
Z
21:22
Zack
An important thing for us to find out is whether sortition chains are necessarily less convenient than smart contracts in state channels.
If the UX is better for state channels, then in order to be competitive we would need to first build up a user-base of state channel users, and only switch to sortition chains once the cost of fees is enough to incentivize our users to want to switch to the more difficult UX.
If the UX is better for state channels, then in order to be competitive we would need to first build up a user-base of state channel users, and only switch to sortition chains once the cost of fees is enough to incentivize our users to want to switch to the more difficult UX.
S
Z
21:32
Zack
the entire process, starting from bitcoin on an exchange, through the smart contract, and finally depositing the winnings onto the exchange again.
first with state channels:
1) withdraw to veo - 6 confirmations
2) make a sortition offer and send it to your partner.
3) after you know who won, do a channel team close to withdraw the money from the channel. 6 confirmations
4) send veo to the exchange - 6 confirmations
now with sortition chains:
1) withdraw from the exchange directly to the sortition chain - 6 confirmations.
2) use a hashlock to simultaneously update 2 accounts in the sortition chain to create the contract - 12 confirmations
3) after you know who won, sign a update to collapse the history proof and maintain privacy.
4) send veo from the sortition chain to an exchange - 6 confirmations.
A big advantage of the state-channel strategy currently is that we don't need them both to be online at the same time.
It would be really nice if we could achieve that kind of user experience with sortition chains.
first with state channels:
1) withdraw to veo - 6 confirmations
2) make a sortition offer and send it to your partner.
3) after you know who won, do a channel team close to withdraw the money from the channel. 6 confirmations
4) send veo to the exchange - 6 confirmations
now with sortition chains:
1) withdraw from the exchange directly to the sortition chain - 6 confirmations.
2) use a hashlock to simultaneously update 2 accounts in the sortition chain to create the contract - 12 confirmations
3) after you know who won, sign a update to collapse the history proof and maintain privacy.
4) send veo from the sortition chain to an exchange - 6 confirmations.
A big advantage of the state-channel strategy currently is that we don't need them both to be online at the same time.
It would be really nice if we could achieve that kind of user experience with sortition chains.
21:41
I think what we need to do, is have something like a tx that is signed by 2 different people participating in the same sortition chain, and sent to the validators.
The tx is not included in the blockchain or in the sortition chain.
If the validators see that it is signed by 2 different people, then they update the ownership tree to make them both 2nd in line to own each other's value.
So I could sign this tx, and publish it publicly, and if anyone else signed the other side of it, then they could make a contract with me, even while I am offline.
If the validators don't include the tx, it is easy for anyone to verify that the tx exists and that the validators are not including it, which destroys their reputation.
So this tx could work the same was as a channel_offer currently works for state channels.
1) withdraw from the exchange directly to the sortition chain.
2) sign the smart contract offer, and go offline.
3) someone accepts the offer, signing it and giving it to the validators
4) once we know who won, we sign an update to collapse the history proof and maintain privacy
5) send veo from the sortition chain to an exchange.
Now it looks as convenient as state channels.
The tx is not included in the blockchain or in the sortition chain.
If the validators see that it is signed by 2 different people, then they update the ownership tree to make them both 2nd in line to own each other's value.
So I could sign this tx, and publish it publicly, and if anyone else signed the other side of it, then they could make a contract with me, even while I am offline.
If the validators don't include the tx, it is easy for anyone to verify that the tx exists and that the validators are not including it, which destroys their reputation.
So this tx could work the same was as a channel_offer currently works for state channels.
1) withdraw from the exchange directly to the sortition chain.
2) sign the smart contract offer, and go offline.
3) someone accepts the offer, signing it and giving it to the validators
4) once we know who won, we sign an update to collapse the history proof and maintain privacy
5) send veo from the sortition chain to an exchange.
Now it looks as convenient as state channels.
Z
22:12
Zack
In reply to this message
besides destroying their reputation, it is also not profitable to do censorship, and they can't force you to take on lottery risk this way, because you have one final chance to sell your probabilistic veo at the end.
22:24
so next lets analyze it as far as who needs to be online in which order.
Lets say Alice is offering a contract, and Bob is accepting.
With state channels:
to create:
Alice publishes and offer, and goes offline.
Bob accepts the offer.
to settle:
Alice sends a settlement offer to Bob, and goes offline.
Bob accepts the offer.
Next looking at sortition chains:
to create:
Alice publishes an offer valid inside the same sortition chain, and she signs something saying she will give up her spot as first in line, if a secret is revealed. only she knows the secret.
Bob accepts the offer and sends it to the validators.
Bob signs something saying he will give up his first spot in line if the secret is revealed.
Alice sends the secret to Bob.
optional: they both sign something to collapse the proof of history, for privacy and savings on fees.
to settle:
optional: they both sign something to collapse the proof of history for privacy and savings on fees.
It looks like the sortition process could actually be even simpler than the state channel process. Since Bob only needs to come online once, instead of twice.
Lets say Alice is offering a contract, and Bob is accepting.
With state channels:
to create:
Alice publishes and offer, and goes offline.
Bob accepts the offer.
to settle:
Alice sends a settlement offer to Bob, and goes offline.
Bob accepts the offer.
Next looking at sortition chains:
to create:
Alice publishes an offer valid inside the same sortition chain, and she signs something saying she will give up her spot as first in line, if a secret is revealed. only she knows the secret.
Bob accepts the offer and sends it to the validators.
Bob signs something saying he will give up his first spot in line if the secret is revealed.
Alice sends the secret to Bob.
optional: they both sign something to collapse the proof of history, for privacy and savings on fees.
to settle:
optional: they both sign something to collapse the proof of history for privacy and savings on fees.
It looks like the sortition process could actually be even simpler than the state channel process. Since Bob only needs to come online once, instead of twice.
Z
22:52
Zack
In reply to this message
So does this mean we need smart contracts both on proofs of ownership, and on proofs of giving up ownership?
23:01
let me try again, this time without using a smart contract to give up control.
to create:
Alice publishes an offer inside the sortition chain, that will make someone else 2nd in line for some of her money, if she can be 2nd in line for some of theirs. This ownership is only valid if a secret is revealed.
Alice makes herself 3rd in line for her own channel, but it is only valid if a secret is never revealed.
Alice gives up her spot first in line.
Bob accepts the offer and sends it to the validators.
Alice has a spot 2nd in line, but only if the secret is revealed.
bob makes himself 3rd in line, but only if a secret is not revealed.
Bob gives up his spot as first in line.
Alice sends the secret to Bob.
to create:
Alice publishes an offer inside the sortition chain, that will make someone else 2nd in line for some of her money, if she can be 2nd in line for some of theirs. This ownership is only valid if a secret is revealed.
Alice makes herself 3rd in line for her own channel, but it is only valid if a secret is never revealed.
Alice gives up her spot first in line.
Bob accepts the offer and sends it to the validators.
Alice has a spot 2nd in line, but only if the secret is revealed.
bob makes himself 3rd in line, but only if a secret is not revealed.
Bob gives up his spot as first in line.
Alice sends the secret to Bob.
Z
23:24
Zack
Ideally, I think it would be better to only do smart contracts for giving up control, and none for having control.
Because having control requires waiting for the sortition validators to put a root onto the main chain.
Giving up control is instantaneous.
Because having control requires waiting for the sortition validators to put a root onto the main chain.
Giving up control is instantaneous.
23:25
If you don't need to tell the sortition operators what smart contracts you are involved in, that also has privacy and scalability benefits
23:28
Oh, I think I have a trick so we can convert every contract to be at the giving up control stage.
Let's say you want to give someone control, if contract C returns true.
So first off, have them make a contract giving up control of something they do not yet have, if C should turn out false.
Then you can assign the value to them.
Let's say you want to give someone control, if contract C returns true.
So first off, have them make a contract giving up control of something they do not yet have, if C should turn out false.
Then you can assign the value to them.
23:31
This upgrade is a big benefit for settling complicated finance contracts in sortition chains, because the computation is like a fraud proof instead of a validity proof.
It only goes on-chain if we actually need it.
When I claim my winnings in a stablecoin contract, I don't have to say that it was a stablecoin contract.
If someone else knows I am lying about having won, they can prove it was a stablecoin contract along with the proof that I didn't win that contract.
It only goes on-chain if we actually need it.
When I claim my winnings in a stablecoin contract, I don't have to say that it was a stablecoin contract.
If someone else knows I am lying about having won, they can prove it was a stablecoin contract along with the proof that I didn't win that contract.
23:32
Another benefit is that I don't have to program the ownership tree to handle smart contracts.
7 February 2020
Z
05:02
Zack
In reply to this message
ok, trying an arbitrary smart contract and resolution again. this time only using smart contracts at the giving up control step.
1) withdraw from the exchange directly to the sortition chain - 6 confirmations.
2) find someone to trade with. you sign an agreement to give up control over the value in their coins if contract C is false. They sign an agreement to give up control over your coins is the contract C is true.
3) you both become 2nd in the line for each other's coins, and 3rd in the line for your own coins. - 6 confirmations
4) you generate a secret S, and an agreement to give up control of your spot first in line, if secret S is revealed.
5) they sign an agreement to give up their first spot in line, if S is revealed.
6) you send secret S to them.
7) optional: you work together to simplify the history proof.
8) optional: once you know who won the bet, you can work together to simplify the history proof.
9) withdraw from the sortition chain to an exchange - 6 confirmations.
1) withdraw from the exchange directly to the sortition chain - 6 confirmations.
2) find someone to trade with. you sign an agreement to give up control over the value in their coins if contract C is false. They sign an agreement to give up control over your coins is the contract C is true.
3) you both become 2nd in the line for each other's coins, and 3rd in the line for your own coins. - 6 confirmations
4) you generate a secret S, and an agreement to give up control of your spot first in line, if secret S is revealed.
5) they sign an agreement to give up their first spot in line, if S is revealed.
6) you send secret S to them.
7) optional: you work together to simplify the history proof.
8) optional: once you know who won the bet, you can work together to simplify the history proof.
9) withdraw from the sortition chain to an exchange - 6 confirmations.
05:03
It seems like this actually works, and it is a major improvement to the sortition settlement process. Increasing scalability, and reducing the amount of data that goes on-chain.
05:04
but it seems like it requires you both to be online at the same time?
05:04
Maybe we should allow turing complete contracts at both steps, to maximize flexibility?
05:07
In reply to this message
I think there might be a way to move the order of stuff around in this protocol, so you don't both need to be online at the same time.
We need some piece of data signed by both participants that the sortition validators could look at, to know to make them both 2nd in line for each other's coins, and 3rd in line for their own.
We need some piece of data signed by both participants that the sortition validators could look at, to know to make them both 2nd in line for each other's coins, and 3rd in line for their own.
Z
05:36
Zack
In reply to this message
1) withdraw from the exchange directly to the sortition chain - 6 confirmations.
2) make an offer that requires 2 signatures, telling the sortition operators to make you 3rd in line for your own coins, and 2nd in line for someone else's. and it makes them 2nd in line for yours, and 3rd in line for their own. You sign an agreement to give up your first spot in line, if a secret S is revealed. only you know the secret. You sign an agreement to give up your second spot to own their coins, but only if contract C returns true.
3) someone accepts your offer by signing it and sending it to the sortition validators. they sign an agreement to give up their first spot in line, if secret S is revealed. they sign an agreement to give up their second spot in line to own your coins, but only if contract C returns false. - 6 confirmations
4) you send secret S to them, and a simplified agreement to give up your first spot in line for your own coins.
5) they send a simplified agreement to give up their first spot in line for their own coins.
It seems like with this process, we both need to come online twice, bet we don't have to be online at the same time.
A nice feature of this protocol is that we can start out owning value in different sortition chains, and it still works.
Is there any way to do this without needing to come online a second time to deal with revealing the secret?
2) make an offer that requires 2 signatures, telling the sortition operators to make you 3rd in line for your own coins, and 2nd in line for someone else's. and it makes them 2nd in line for yours, and 3rd in line for their own. You sign an agreement to give up your first spot in line, if a secret S is revealed. only you know the secret. You sign an agreement to give up your second spot to own their coins, but only if contract C returns true.
3) someone accepts your offer by signing it and sending it to the sortition validators. they sign an agreement to give up their first spot in line, if secret S is revealed. they sign an agreement to give up their second spot in line to own your coins, but only if contract C returns false. - 6 confirmations
4) you send secret S to them, and a simplified agreement to give up your first spot in line for your own coins.
5) they send a simplified agreement to give up their first spot in line for their own coins.
It seems like with this process, we both need to come online twice, bet we don't have to be online at the same time.
A nice feature of this protocol is that we can start out owning value in different sortition chains, and it still works.
Is there any way to do this without needing to come online a second time to deal with revealing the secret?
Hmd invited Hmd
Z
05:52
Zack
so, the nice thing about having smart contracts in sortition_claim, is that the sortition validators can work with you to simultaneously assign value to multiple people on condition of a smart contract's outcome. This means we don't need to come online a second time to reveal a secret for hashlocking, which also means that there is less of a free-option opportunity, because the person who made the contract offer doesn't have the option to not reveal the secret.
what is nice about having smart contracts in the sortition_evidence tx, is that sortition validators don't have to know who is making what contract with who. the sortition operators just blindly keep reassigning value to different people, without knowing anything about who is betting with who. Another benefit is that the expected amount of on-chain data needed per sortition chain is a lot lower. You don't need to put any of your winning smart contracts on-chain to claim a win.
what is nice about having smart contracts in the sortition_evidence tx, is that sortition validators don't have to know who is making what contract with who. the sortition operators just blindly keep reassigning value to different people, without knowing anything about who is betting with who. Another benefit is that the expected amount of on-chain data needed per sortition chain is a lot lower. You don't need to put any of your winning smart contracts on-chain to claim a win.
05:52
maybe we should just support smart contracts at both steps, to give the maximum amount of flexibility going forward?
05:58
In reply to this message
oh, I think you still need to come online a second time, even if we have smart contracts in the sortition claim tx. How else can you give up control of your first spot in line, to activate the smart contract.
So I am thinking that it is always better to do the smart contracts at the sortition_evidence step, and we shouldn't bother supporting them at the sortition_claim step.
But this raises a deeper issue.
If sortition smart contracts require coming online twice, but state channel contracts only require coming online once, maybe that means users will prefer state channel contracts for now.
So I am thinking that it is always better to do the smart contracts at the sortition_evidence step, and we shouldn't bother supporting them at the sortition_claim step.
But this raises a deeper issue.
If sortition smart contracts require coming online twice, but state channel contracts only require coming online once, maybe that means users will prefer state channel contracts for now.
06:00
Maybe we need to look more at the UX of a state channel embedded inside a sortition chain.
06:11
I think embedding a state channel doesn't help.
We still need some way to give up our first spot in line and activate the state channel, so we would still need to come online twice.
We still need some way to give up our first spot in line and activate the state channel, so we would still need to come online twice.
06:21
If the secret gets published on the main chain in a proof of existence tx, then only one of the 2 participants needs to come online twice.
state channels really fit well for p2p derivatives. We came up with the design of p2p derivatives based on the capabilities of state channels.
So maybe p2p derivatives are not a good example as far as predicting if users will prefer state channels or sortition chains.
If we look a single price batch markets as an example instead, maybe sortition chains will be preferable.
single price batch markets are a superior tool than p2p derivatives, so if sortition chains are a better platform for them, that is probably justification enough to dive straight into sortition chains.
state channels really fit well for p2p derivatives. We came up with the design of p2p derivatives based on the capabilities of state channels.
So maybe p2p derivatives are not a good example as far as predicting if users will prefer state channels or sortition chains.
If we look a single price batch markets as an example instead, maybe sortition chains will be preferable.
single price batch markets are a superior tool than p2p derivatives, so if sortition chains are a better platform for them, that is probably justification enough to dive straight into sortition chains.
06:23
assuming the batch price gets published in a proof-of-existence tx on the main chain, only the operator needs to come online more than once.
And the operator needs to stay online anyway, so this is not worse than the state channel version.
And the operator needs to stay online anyway, so this is not worse than the state channel version.
06:23
it would be really nice if we could show that sortition chains have less capital lockup requirements for single price batches in comparison to state channels.
06:25
even if the market operator and the sortition validators are the same entity, that would be a worthy sacrifice, if we could have single price batches without such onerous lockup requirements.
06:34
I guess the advantage of sortition chains is that it is free to create the embedded channels at the beginning, and to settle them at the end.
The capital lockup costs during the lifetime of the market aren't less in sortition chains vs in normal state channels.
The capital lockup costs during the lifetime of the market aren't less in sortition chains vs in normal state channels.
06:38
maybe we need some sort of dedicated data structure. like embedding channels in sortition chains, we could embed a prize-pool object.
Your probability of winning the prize pool is based on how many shares you purchased, and whether you correctly guessed the outcome of an oracle, and the batch price when you first bought in to the pool.
Your probability of winning the prize pool is based on how many shares you purchased, and whether you correctly guessed the outcome of an oracle, and the batch price when you first bought in to the pool.
Z
07:00
Zack
it's kind of disappointing.
One of the major incentives for doing all this research into sortition chains was the dream that we could have single price batch markets without needing to lock up so much money, and now it seems like we won't have that feature.
One of the major incentives for doing all this research into sortition chains was the dream that we could have single price batch markets without needing to lock up so much money, and now it seems like we won't have that feature.
07:02
well, if creating new channels is practically free, maybe the solution is to make more channels and move the bets from indirect paths in the market to direct paths between the people who are betting.
T
10:15
The Ancients
lol zack still being zack i see
10:15
dead coin hahah
T
12:28
Seems amoveo is losing stem. The oracle is the most decentralized one but without anybody using it I see no future ahead. What is your opinion?
C
14:04
Craig
The debates Zach was getting into about PoS vs PoW over the summer
Maybe a good use of energy to do something like that criticism/ debate towards some of the other projects working on derivatives.
Such as ftx or synthetix.
Take the case for amoveo to those communities.
Particularly snx has problems currently with frontrunning. They might be open to outside voices
Maybe a good use of energy to do something like that criticism/ debate towards some of the other projects working on derivatives.
Such as ftx or synthetix.
Take the case for amoveo to those communities.
Particularly snx has problems currently with frontrunning. They might be open to outside voices
14:07
People on those platforms have first hand experience of difficulties that I assume (not gonna lie +90% of amoveo is over my head still) veo is going to solve
H
14:24
Hmd
Hello everyone, I'm really interested in this project and I'll like to buy this token with 3.5btc or BCH, any trusted and honest seller (admin) can DM for transaction
I
Z
Z
17:52
413 blocks until the hard update activates.
I am excited to sync blocks backwards.
I am excited to sync blocks backwards.
8 February 2020
Z
05:47
Zack
haha, I did ask a couple people if any rumors like that are true.
As far as I can tell, they don't have any evidence of extraterrestrials, or the earth being flat instead of round, or anything super surprising.
I did learn some mildly surprising stuff though.
they use a lot of ancient hardware, because it is too expensive to test out how newer versions will stand up to orbit over time. It seemed like there is plenty of funding for politically exciting missions like visiting the moon, asteroids and mars, but not enough in making economically useful technology advances.
The level of corruption, and way it manifests itself. You keep your job by being friends with the right people.
They were nice to me, it is a comfortable place to work. For a while my office was in the building where they assembled the MSL, which is one of the mars rovers. There was a glass wall so I could see into the clean room where it was assembled.
As far as I can tell, they don't have any evidence of extraterrestrials, or the earth being flat instead of round, or anything super surprising.
I did learn some mildly surprising stuff though.
they use a lot of ancient hardware, because it is too expensive to test out how newer versions will stand up to orbit over time. It seemed like there is plenty of funding for politically exciting missions like visiting the moon, asteroids and mars, but not enough in making economically useful technology advances.
The level of corruption, and way it manifests itself. You keep your job by being friends with the right people.
They were nice to me, it is a comfortable place to work. For a while my office was in the building where they assembled the MSL, which is one of the mars rovers. There was a glass wall so I could see into the clean room where it was assembled.
ŽM
05:53
Živojin Mirić
I am confident that futarchy will provide a solution for every possible human need because it is superior to any other form of governing of society. Have patience my son.
05:53
Truth will win in the end, it is inevitable.
05:53
Hail Zack
Z
05:54
Zack
i don't know. I didn't meet anyone involved in asteroid mining.
It is still so cheap to mine minerals on earth. transporting the minerals down earth's gravity well is probably more expensive than just mining them on earth.
It is still so cheap to mine minerals on earth. transporting the minerals down earth's gravity well is probably more expensive than just mining them on earth.
05:56
I think if we wanted to do large scale manufacturing off-planet. like on the moon, or in orbit. then maybe it would make sense to catch a space rock. Because it would be cheaper to use metal that is already in space, instead of lifting it off of earth.
I doubt we will have much space manufacturing any time soon, so asteroid mining probably wont matter either.
I doubt we will have much space manufacturing any time soon, so asteroid mining probably wont matter either.
ŽM
05:58
Živojin Mirić
Ok
Z
05:58
Zack
In reply to this message
Yes, I think futarchy is needed to help guide us in building the technology that will enable us to conquer places off-earth.
The decision making process at NASA today isn't good enough, they are focused on politically impressive goals instead of actually useful ones.
The decision making process at NASA today isn't good enough, they are focused on politically impressive goals instead of actually useful ones.
06:07
Maybe POW mining will motivate the first large scale space manufacturing.
We will want to build ASICS in outer space, and then send them to Titan, a moon around Saturn.
Titan has oceans of simple hydrocarbons, so the mining hardware can use that as an energy source to mine VEO.
And it is super cold there, so getting heat off the ASICs is cheaper. It might be the best place in the solar system to do POW.
We will want to build ASICS in outer space, and then send them to Titan, a moon around Saturn.
Titan has oceans of simple hydrocarbons, so the mining hardware can use that as an energy source to mine VEO.
And it is super cold there, so getting heat off the ASICs is cheaper. It might be the best place in the solar system to do POW.
06:09
hydrocarbons are the basis of a lot of chemical engineering we could do. We could make mineral oil for efficient heat transfer. We could make plastics, to protect the ASICS, and contain the mineral oil.
ŽM
06:10
Živojin Mirić
Ok but what about H2O?
06:10
Very important for 3rd stage civilazation
Z
06:10
Zack
ASICs don't need water, or people.
ŽM
06:11
Živojin Mirić
Asics are not. People
Z
06:11
Zack
No people want to live on Titan haha
ŽM
06:11
Živojin Mirić
Robot not human for 330 years atleast
06:11
Ok
Z
06:12
Zack
but maybe people would live in orbital manufacturing facilities where they make drones that go to titan to set up more mining equipment.
A
06:12
In the Black World of Technology
06:13
That the missing 29 trillion is still here on earth and not off-World
06:14
You assume that it’s really 2020
ŽM
06:14
Živojin Mirić
I have to think about this
Z
06:18
Zack
blockchain oracles can only be used for information that will become common knowledge before the oracle expires.
So if we really are trapped in a hypnotic ground-hogs day scenario, re-living the 21st century over and over, I think futarchy wont solve that. Because the fact that we are in a simulation wont become common knowledge before a known expiration date we could program into the oracle.
So if we really are trapped in a hypnotic ground-hogs day scenario, re-living the 21st century over and over, I think futarchy wont solve that. Because the fact that we are in a simulation wont become common knowledge before a known expiration date we could program into the oracle.
06:22
But you can make markets for stuff like this:
"if not (we invested $X amount of money to find out if we are really in the 21st century), return
return(we found out it is actually 30th century or later)"
This kind of contract could give us a hint that we might be in the 30th century or later, and it could help financially incentivize people to look into that possibility more.
"if not (we invested $X amount of money to find out if we are really in the 21st century), return
bad question.return(we found out it is actually 30th century or later)"
This kind of contract could give us a hint that we might be in the 30th century or later, and it could help financially incentivize people to look into that possibility more.
ŽM
Z
06:31
Zack
This seems like a general solution for conspiracy theories.
If you really think the conspiracy happened, then make one of these contracts to financially incentivize an investigation. Put your money where your mouth is.
You can specify all the details of the kind of investigation in the oracle contract.
If you really think the conspiracy happened, then make one of these contracts to financially incentivize an investigation. Put your money where your mouth is.
You can specify all the details of the kind of investigation in the oracle contract.
ŽM
06:31
Živojin Mirić
Wat if conspirators have more money to bluff?
06:32
Aint that the limit of futarchy?
Z
06:32
Zack
futarchy gets more accurate if your try to manipulate it.
ŽM
06:32
Živojin Mirić
Who has more money has the power to bluff and manipulate?
06:32
How come?
06:32
I believe rotschild is vampir ok?
Z
06:33
Zack
wolves go where the sheep are.
Investors are seeking opportunities to profit.
If one person makes a bad investment, that is a profit opportunity for everyone else.
Investors are seeking opportunities to profit.
If one person makes a bad investment, that is a profit opportunity for everyone else.
06:33
http://mason.gmu.edu/~rhanson/biashelp.pdf Robin Hanson wrote about how manipulators make the market more accurate.
ŽM
06:34
Živojin Mirić
You kbow that most people are retards and most people dont have enough money by themselves to be interesting to vampirs
06:34
Theory fails ok
06:34
Not every profit opportunity is enough to make vampirs take action
06:35
Because they dont deal with small money ok
06:35
They have tactical investment
06:35
To retain control
06:35
They ignore laws of futarchy
Z
06:36
Zack
Our current financial system locks almost everyone out. Only the elite have access to powerful financial tools.
Amoveo makes these tools available to everyone.
Amoveo makes these tools available to everyone.
ŽM
06:36
Živojin Mirić
If futarchy decides that some people should die for the benefit of others is that still ok for you?
Z
ŽM
06:37
Živojin Mirić
I am not!
A
ŽM
06:37
Živojin Mirić
I am very peacful
06:37
I am just asking
06:37
This is pure theory
06:38
I am not familiar with it
06:38
But can presume
06:38
From life experience
A
Z
06:39
Zack
In reply to this message
futarchy is not moral. If you have a goal, futarchy can tell you what decisions are most effective to achieve your goal.
ŽM
06:40
Živojin Mirić
In reply to this message
Then futarchy does not care about morals and life or death
A
06:40
Aries
I mean a lot of them were super weird this year and space Orientated
ŽM
06:40
Živojin Mirić
So you confirm my presumption
06:40
Are you GOD Zack?
06:40
Who are you?
06:41
You unleashed futarchy on this world
06:41
Our faith is final and fixed
06:41
We have no choice
06:41
Futarchy will decide
06:42
I mean - people with money will decide
Z
06:42
Zack
You could say the same thing about the scientific method. the SM is used so people can more effectively make decisions to achieve their goals.
06:43
but we tend to look positively at the scientific revolution
ŽM
06:43
Živojin Mirić
Futarchy is not ok when you start using it in a late state of society when stakeholders are already defined and small amount of people can decide everything with their existing resources
06:43
It's unfair
06:43
You should wait for an apocalypse
06:43
Then release a futarchy project
Z
06:43
Zack
being rich doesn't give you an advantage in futarchy.
ŽM
06:43
Živojin Mirić
It does
06:44
You can bribe anyone
06:44
That's your own words
06:44
Put your money where your mouth is
Z
ŽM
06:44
Živojin Mirić
Ok
06:44
Thx
06:44
For info
06:44
Brb by
Z
06:44
Zack
people who make bribes or bets to try and manipulate the result of futarchy only make it more accurate
ŽM
06:45
Živojin Mirić
I have to think about this
06:45
Thank you for advice
06:45
Sensei Zack
Z
06:46
Zack
This is a forum to talk about Amoveo, not me.
ŽM
06:46
Živojin Mirić
😇
06:47
You are amoveo, amoveo is us, we are futarchy, it is everything
06:47
I believe
06:47
I am really excited to see this live, to live this
06:47
This is human evolution
06:47
Next level shit
Z
09:39
Zack
I'm thinking I'll make tests of batches of txs for all the basic things we could want to do with sortition chains.
Atomic swaps, p2p derivatives with frontrunning protection, micropayments, single price batches.
Having tests with these txs will help us find bugs in the sortition txs design, and it will guide our efforts to develop an api and javascript interface for this new tool.
Atomic swaps, p2p derivatives with frontrunning protection, micropayments, single price batches.
Having tests with these txs will help us find bugs in the sortition txs design, and it will guide our efforts to develop an api and javascript interface for this new tool.
g31st invited g31st
H
19:29
Harmony is lifer • $ONE 🦄
Whats up guys?
Z
21:31
Zack
no, the facility I worked at didn't do anything with manned missions. Only robotics.
21:40
I made a test for sortition_evidence_tx, which is where we are putting the smart contracts.
21:42
you can see all the code changes that are being done for the sortition chain update here. https://github.com/zack-bitcoin/amoveo/compare/sortition
Deleted invited Deleted Account
S
21:57
Sy
Did we activate 27 yet?
Z
21:58
Zack
In reply to this message
not yet, we are on 102000
it activate at 102260.
there are about 130 blocks per day, so about 2 days left.
it activate at 102260.
there are about 130 blocks per day, so about 2 days left.
S
22:01
Sy
Ah okay
I
9 February 2020
OK
T
13:31
The Ancients
yfw Amoveo prices are the same or lower when BTC was valued at $3800
13:32
yfw Zack has full blown autism and 0 marketability.
13:33
yfw you can't even sell this Shitcoin even if you wanted too cause the volume is non-existant
Deleted invited Deleted Account
A
20:53
Alex
In reply to this message
Zach is one of the sharpest and forward-thinking minds in all of crypto. You're totally off base
b
Z
23:58
Zack
It is nice finally seeing the sortition chain come together like this.
I can think more clearly now that we have a concrete example.
I can think more clearly now that we have a concrete example.
10 February 2020
C
11:18
Craig
https://mobile.twitter.com/_BenWang/status/1225437776478425089
Someone mentioned futarchy?
Perhaps a chance for Zack or someone to mention amoveo
Someone mentioned futarchy?
Perhaps a chance for Zack or someone to mention amoveo
Z
19:42
Zack
he calls it "futarchy" and "governance".
But it sounds like he is talking about dominant assurance contracts
But it sounds like he is talking about dominant assurance contracts
19:46
I don't understand why they are making a new governance token, instead of just going with the decision that maximizes the value of Eth.
19:49
"After buidlers have received funding there is nothing stopping them from walking away with the money and not building anything, except that they would lose significant reputation value and consequently, the ability to receive further funding"
So, this is a trustful protocol.
This seems like a broken version of dominant assurance contracts.
So, this is a trustful protocol.
This seems like a broken version of dominant assurance contracts.
19:53
> Buidler Governance uses inflation funding to fund wealth generating innovations/ideas
oh, so they are just printing more Eth out of nothing to fund these ideas.
That seems like a really bad idea.
oh, so they are just printing more Eth out of nothing to fund these ideas.
That seems like a really bad idea.
19:56
> This form of governance only allows one proposal to be evaluated at a time because concurrent proposals would result in the price reflecting an average of all proposals rather than any specific one.
Sounds like Buidler governance is a lot worse than futarchy.
Futarchy can simultaneously make many different decisions to improve the price of VEO.
Sounds like Buidler governance is a lot worse than futarchy.
Futarchy can simultaneously make many different decisions to improve the price of VEO.
19:59
This mechanism is so complicated, and has so many moving parts.
It creates a governance sub-currency, but people don't hold the governance coins directly, they only hold a derivative which will be worth governance coins if the proposal succeeds, otherwise it turns back into DAI.
They don't give reasoning for why they have created so much complexity.
It isn't clear why these governance tokens would ever have any value. What are they used for?
It creates a governance sub-currency, but people don't hold the governance coins directly, they only hold a derivative which will be worth governance coins if the proposal succeeds, otherwise it turns back into DAI.
They don't give reasoning for why they have created so much complexity.
It isn't clear why these governance tokens would ever have any value. What are they used for?
11 February 2020
Z
01:56
Zack
this is a place to talk about amoveo.
Alternative ways of doing futarchy is related to amoveo.
Alternative ways of doing futarchy is related to amoveo.
Z
21:50
Zack
I have been working on recursive sortition chains.
I got the first version ready, and I started making a test.
I got the first version ready, and I started making a test.
21:51
That hard update activated, so now it should be ready for me to set up reverse syncing.
12 February 2020
Deleted invited Deleted Account
Z
07:56
Zack
I added the ability for sortition chains inside sortition chains, with a passing test.
ŽM
08:05
Živojin Mirić
( ͡° ͜ʖ ͡°)
( ͡⊙ ͜ʖ ͡⊙)
( ͡◉ ͜ʖ ͡◉)
( ͡⊙ ͜ʖ ͡⊙)
( ͡◉ ͜ʖ ͡◉)
alx invited alx
Deleted invited Deleted Account
13 February 2020
Z
00:04
Zack
It seems like when we pay out winnings from sortition chains, sometimes instead of putting the money into a winning account, we should put it into a winning state channel.
00:06
that way we can use the existing system of channel txs to enforce the rules inside of the sortition chain.
00:08
and we can use the existing javascript tools for enforcing the outcome of the channels.
Z
03:03
Zack
I found a small vulnerability with how we do channels. The problem is that the channel ID is something that you can just pick.
So an attack could take the chanel I'd that you needed for your tx, and he can pay a slightly higher fee to prevent your tx from going on-chain.
So an attack could take the chanel I'd that you needed for your tx, and he can pay a slightly higher fee to prevent your tx from going on-chain.
S
03:04
Shaun
Would there be a way to leverage Amoveo's tech for the recent DeFi hype?
Z
03:06
We also need to fix this for sortition chains. Because when you settle the sortition chain, you need to be sure that the I'd is available.
03:07
In reply to this message
Amoveo is always great. Doesn't matter what buzz words people are saying today.
S
03:11
Shaun
it does matter Zack, you have a perfectly fine engine with no gas to work it. Those "buzzwords" are the gas.
03:12
no one cares about futarchy or dacs or sharding
03:12
not trying to sound hostile, just want to see Amoveo succeed just like everyone else here.
Z
03:14
Zack
Amoveo is for financial derivatives, which are one of the basic tools in finance.
Amoveo is a decentralized blockchain.
Decentralized. Finance.
Defi.
Amoveo is a decentralized blockchain.
Decentralized. Finance.
Defi.
S
03:15
Shaun
exactly my point, going back to my first message, since Amoveo is perfect for this, can we make things on Amoveo that people will actually use while the DeFi hype is peaking?
Z
03:16
Zack
There is a tool for pairs of people to bet on any topic they want.
S
03:16
Shaun
a less complex MakerDAO alternative per se
03:17
You can make stablecoins too
03:17
Or leveraged bets
S
03:18
Shaun
the ethereum ecosystem and DeFi in particular are suffering from poorly designed oracles. Perhaps Amoveo could help with that also.
Z
03:25
Zack
Amoveo's oracle works great. And in most cases, you don't have to use it.
03:25
If the contract participants agree on how it would resolve if they did use an Oracle, then they can save the cost of the Oracle and just agree on the outcome.
T
04:07
Tromp
I would love to see more liquidity but qtrade is still too small
04:07
But it works great
Lartistograf invited Lartistograf
T
04:42
Tromp
Is the wallet for ledger working?
Z
06:55
Zack
In reply to this message
I got the p2p tool in the light node to work correctly with the hard update we would need to fix this bug.
07:09
I guess I will schedule this hard update for a week from now
07:09
ill do a little more testing first
I
07:09
Instinct
In reply to this message
It’s not official integration but you can use this guide https://t.co/LZtQGc6E9t?amp=1
T
07:27
Tromp
Thankss
Z
07:31
Zack
What would you guys think if we dropped support for verifying very old blocks from the core client?
07:32
you could still sync them, and check that their merkle root matched the headers. But you can't actually process the txs.
07:32
This would let me delete a lot of old code from before hard updates happened. And the code base could be easier to read.
Z
07:49
Zack
Around February 27, hard update number 29 will activate.
The purpose of this update is to restrict what kinds of channel IDs you can make.
This prevents attackers from using the same channel id as you to get your tx kicked out of the tx pool. it also prevents an attack against sortition chains, because the sortition chain needs to have an available channel id to put the winnings into.
Here is a link to the documentation about updating https://github.com/zack-bitcoin/amoveo/blob/master/docs/getting-started/updating.md
This update does not need a re-sync.
@potat_o @Simon3456
The purpose of this update is to restrict what kinds of channel IDs you can make.
This prevents attackers from using the same channel id as you to get your tx kicked out of the tx pool. it also prevents an attack against sortition chains, because the sortition chain needs to have an available channel id to put the winnings into.
Here is a link to the documentation about updating https://github.com/zack-bitcoin/amoveo/blob/master/docs/getting-started/updating.md
This update does not need a re-sync.
@potat_o @Simon3456
Sebastian invited Sebastian
C
11:21
Callum Wright
In reply to this message
If Amoveo takes off in the future there will be someone dig this up and criticize us for sure
11:21
if we're fine with it then yeah
Z
11:23
Zack
Maybe I could have a different github repository for code to sync wih different parts of the history.
Nick Yakutilov invited Nick Yakutilov
Z
22:33
Zack
In reply to this message
An issue with this strategy is that if your channel partner stops cooperating, you are left holding lottery risk.
22:38
we had a similar problem like this with hashlocking.
And the solution was to do an on-chain proof of existence, but only if your partner refuses to cooperate to update.
It seems like if your channel partner in the sortition chain is refusing to cooperate, we should start doing some channel settlement txs on-chain, so that when the channel is finally created, it will be created in an already settled state, and everyone knows who will get how much of the channel.
That way you can re-sell the part of the channel that you own.
But for this to work, we probably can't create the channel on-chain. We need to give 100% of the value to one of the participants, and make it so you are more likely to win if you own more of the value in the channel.
That way the channel contract can be compatible with the sortition chain.
And the solution was to do an on-chain proof of existence, but only if your partner refuses to cooperate to update.
It seems like if your channel partner in the sortition chain is refusing to cooperate, we should start doing some channel settlement txs on-chain, so that when the channel is finally created, it will be created in an already settled state, and everyone knows who will get how much of the channel.
That way you can re-sell the part of the channel that you own.
But for this to work, we probably can't create the channel on-chain. We need to give 100% of the value to one of the participants, and make it so you are more likely to win if you own more of the value in the channel.
That way the channel contract can be compatible with the sortition chain.
22:47
Maybe putting channels inside the sortition chain at all is a mistake.
The sortition ownership contracts are already turing complete.
If it is possible that channels inside sortition chains need an on-chain component, then in the worst case we would only be scaling linearly with the number of channels.
The sortition ownership contracts are already turing complete.
If it is possible that channels inside sortition chains need an on-chain component, then in the worst case we would only be scaling linearly with the number of channels.
22:53
One-way channels only have 1/2 of the problem of 2 way channels.
Once the money is spent in a 1-way channel inside a sortition chain, it becomes normal spendable money.
Maybe we can use a system of probabilistic payments and one way channels to enable instant finality micropayments.
Once the money is spent in a 1-way channel inside a sortition chain, it becomes normal spendable money.
Maybe we can use a system of probabilistic payments and one way channels to enable instant finality micropayments.
22:55
Oh, I think for prob payments we need to wait for a confirmation too. Might as well do a normal payment instead.
22:58
The main goal of amoveo has always been derivatives, not instant micropayments.
But still, it is kind of disappointing if amoveo can't be used to buy a coffee.
But still, it is kind of disappointing if amoveo can't be used to buy a coffee.
23:11
I asked Fernando. Maybe he knows the solution.
14 February 2020
Z
01:04
Zack
Single price batches without channels would be different.
Everyone would make their trades. Then we would wait for 60 minutes of confirmations.
Then the server would publish the batch price.
Everyone would make their trades. Then we would wait for 60 minutes of confirmations.
Then the server would publish the batch price.
Z
02:35
Zack
Before the sortition chain is settled, some specialist will buy up most of the value to hedge the lottery risk.
That specialist wouldn't mind being on the dangerous side of a one-way channel in the sortition chain, since they will hold all the lottery risk either way.
So maybe we can have one-way channels, as long as they are with this specialist.
That specialist wouldn't mind being on the dangerous side of a one-way channel in the sortition chain, since they will hold all the lottery risk either way.
So maybe we can have one-way channels, as long as they are with this specialist.
Z
03:05
Zack
In reply to this message
Fernando got back to me.
It seems like 2-way channels still have use cases, even if there is a possibility that you could end up holding lottery risk.
If you just store a small amount of value at a time, it could be convenient for instant-finality micro payments, like buying coffee.
In sortition chains it is free to make and close these channels, so we can make lots of small ones as needed, that way the total possible lottery risk stays low enough.
But for making big derivatives trades, we probably shouldn't use these channels. Since we don't want the lottery risk.
We should take the slower route, and use normal sortition chain contracts for derivatives.
It seems like 2-way channels still have use cases, even if there is a possibility that you could end up holding lottery risk.
If you just store a small amount of value at a time, it could be convenient for instant-finality micro payments, like buying coffee.
In sortition chains it is free to make and close these channels, so we can make lots of small ones as needed, that way the total possible lottery risk stays low enough.
But for making big derivatives trades, we probably shouldn't use these channels. Since we don't want the lottery risk.
We should take the slower route, and use normal sortition chain contracts for derivatives.
JS
Z
05:10
He is trying to do something like sortition chains, but on bitcoin. it is called "channel factories"
Deleted invited Deleted Account
15 February 2020
Z
00:38
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/sortition_chain_history.md I wrote this document of the history of how sortition chains got designed the way that they are.
It is kind of like a works cited, or an acknowledgements section.
It is kind of like a works cited, or an acknowledgements section.
Liaskas E. invited Liaskas E.
S
04:19
Sy
neat little sell wall at 0.00644
JS
06:13
Jon Snow
A big bag to off load
S
14:11
Sy
Just one BTC tho
C
15:28
Callum Wright
In reply to this message
this makes sense for me (obv not an expert in this field)
15:29
"Thank you to Paul Sztorc for figuring out that financial derivatives are the kinds of smart contracts that we most need to put onto blockchains, other kinds of smart contracts don't really matter in comparison to how important derivatives will be. Financial derivatives don't depend on shared state, this lack of shared state means that financial derivatives can be much more scalable than other kinds of contracts"
15:29
Zack did this statement private or public somewhere?
15:31
Paul's statement about financial derivates on blockchain I mean
Z
18:04
Zack
In reply to this message
Looking at the kinds of contracts that truth coin supports. Also http://www.truthcoin.info/blog/contracts-oracles-sidechains/ and http://www.truthcoin.info/blog/wise-contracts/
K
22:49
K
'For example, if there are 2 txs that are contradictory, and you would benefit from having tx B included instead of tx C, then it could be in your interest to always predict that B will win, even if a majority of the peers that you query choose C.' Do you have an example of such a tx?
Z
23:04
Zack
In reply to this message
sure. double spending.
If I bought something using Avalanche coins, then it is in my interest for that tx to be undone so that I can keep my money.
More generally, someone could be bribed to censor certain txs. Censorship is equivalent to soft forks, which can be used to change any part of consensus.
If I bought something using Avalanche coins, then it is in my interest for that tx to be undone so that I can keep my money.
More generally, someone could be bribed to censor certain txs. Censorship is equivalent to soft forks, which can be used to change any part of consensus.
16 February 2020
Z
01:24
Zack
In reply to this message
thats good news for amoveo. if people start attacking oracles more, then oracle security will start to matter more.
A
01:33
Alex
Secure, low-cost Oracles is a far stronger value proposition and the utility of futarchy. For better or worse, money and security talk exponentially louder than does high level economic theory
Z
01:34
Zack
it seems like both secure and insecure oracles can be made to be basically free
Deleted invited Deleted Account
04:57
Deleted Account
hello any update on amoveo?
04:57
any real use cases?
04:57
also does anyone know if zack has sold any amoveos yet?
04:59
In reply to this message
seems so. people think that technology is what is important, but actually ethereum spent more money on marketing than development at beginning
Z
05:07
Zack
In reply to this message
https://github.com/zack-bitcoin/amoveo/blob/master/docs/light_node/p2p_derivatives.md I think this tool has the opportunity to get popular
05:07
Deleted Account
zack has not sold anything yet, that is a good sign
05:08
but zack why do you think the price is so low?
Z
05:08
Zack
Until we have active users, the price probably should be low
05:09
Deleted Account
not true, most projects do not have active users yet the price is high
Z
05:10
We want to get sortition chains working first before we focus on getting users https://github.com/zack-bitcoin/amoveo-docs/blob/master//design/sortition_chains.md
05:10
This way we can scale
05:10
Deleted Account
sounds silly
05:10
scaling only matters if you already have users
Z
05:11
Zack
Having many users on a tool that cannot scale is not good.
You have to shut down the old version and try to convince them to migrate to the new one.
You have to shut down the old version and try to convince them to migrate to the new one.
05:11
Deleted Account
scaling is not even a problem worth addressing, your assumption is that your product has any use at all
05:11
the market has shown it has 0 use for it
05:12
that's why you need either a real use case, or marketing to get price up
Z
05:12
Zack
The market loves financial derivatives. One of the most popular use cases for both currency and cryptocurrency.
05:12
Deleted Account
and it has already been 1 or 2 years of development
05:12
sure, but that has no relationship with your project
05:13
as in your project has no real use case
05:13
if it did, after a year it would at least have enough real users or more than a few hundred of trading volume a day
05:14
do you at least recognize that this past year or two has been a massive, total failure? only after recognizing failure is it possible to succeed.
05:15
for this project to be worth anything, I believe a huge change in priorities and strategy needs to be made.
Z
05:15
Zack
Product market fit can take a lot of time to get right.
We are still adding useful features which could lead to product market fit.
Amoveo doesn't have big expenses, I will keep working on this even if it takes many more years.
We are still adding useful features which could lead to product market fit.
Amoveo doesn't have big expenses, I will keep working on this even if it takes many more years.
05:16
Deleted Account
the most successful companies never had such low traction in after a year or two
Z
05:16
Zack
Amoveo is not a company
05:16
Deleted Account
for that matter, I can't even think of any product like that
05:17
company, product, whatever
05:17
anything in the universe of business has not shown such low traction as amoveo after a year
05:17
I think as users as investors, it would give us confidence if you can at least admit that the past year has shown that amoveo has been a big failure
05:17
then this would signal a shift in finding a serious use case or at least in marketing
05:18
I advise you to talk to people in real life, and find a marketing head
05:18
it would help this project a lot
05:19
autism only works if you're social, like vitalik
05:19
at least in business and in creating something people use