10:05
mr x
parimutuel market is pretty good for onchain prediction market?
10:06
money just piles on in making it move slower and slower
10:07
and its super simple if i understood it
10:07
Zack
it looks like a one-batch market
10:08
mr x
hmm is that bad
10:08
Zack
no. it can be good to have fewer batches in low volume markets
10:09
mr x
can you make it do value prediction rather rhan outcome probability?
10:09
Zack
those are the same thing
10:09
you just give it range before hand
10:23
parimutuel markets have problem because why not wait until the last moment hmm?
10:24
Zack
oh, with parimutuel you don't have a limit price you are willing to pay
10:24
so you could end up paying a higher price than you had wanted to pay
10:24
mr x
yeah its really lol
10:24
Zack
so I guess it isn't measuring the price/probability as well as other kinds of markets
10:25
it feels pretty good in the context of futarchy
10:25
the close date gets pushed if betting occurs...
10:25
Zack
why not have multiple batches and use limit orders? why would we get rid of those features?
10:26
mr x
what is the predicted value in those cases?
10:26
mr x
some volume average?
10:26
Zack
the current market price is the current best estimate
10:26
mr x
it keeps moving?
10:26
just stick in last minute bet
10:27
parimutuel just gets more and more bloated and slower moving xD
10:27
at some time close date stops being pushed back
10:28
and always liquidity
10:29
Zack
that sounds like a drawback. so it can't react to new information effectively, and people are exposed to unnecessary risk.
10:29
it isn't possible to have a fair market on chain
10:30
Zack
off-chain is more scalable anyway.
If it had to either be on-chain or off-chain, we are lucky that it works off-chain.
10:33
mr x
but you cannot use last clearing price for futarchy right?
10:34
Zack
no, but that isn't a property we wanted anyway
10:35
so, part of futarchy is that the price is a prediction, and part of futarchy is that everyone who wants to can use the market to hedge against their perceived risk in the decision being made.
10:35
Once everyone is fully insured against their perceived risks, then no one will be opposed to the decision being made.
10:36
mr x
how is the decision chosen?
10:36
Zack
if everyone in the community is in agreement about what should be done, then that is what we do
10:37
if they aren't in agreement yet, then we make a market so they can get insured against whatever risks they believe in, until we are in agreement about what should be done.
10:39
mr x
people get insure so that they become indifferent about the choice??
10:40
mr x
so what we do? xD
10:40
Zack
i don't know what you are asking.
10:41
mr x
what choice do we make?
10:41
Zack
the one that we have agreed to make
10:41
mr x
how do we know what we agreed to make
10:41
Zack
futarchy is a tool for us to come to agreement about what to do. if it works, then we will come to an agreement.
10:41
everyone knows for themselves what decision they want to make
10:51
everyone just the chooses what fork to run?
10:51
Zack
if you don't care enough about a decision to buy insurance, then it must not really matter to you.
10:51
mr x
talking about blockchains
10:52
Zack
if there arebig unmatched orders sitting in the market for a long time, it is pretty obvious that no one cares to buy them at that price
10:52
people run the version that is the most valuable on the market.
10:52
mr x
but if u wanna make the blockchain state updates automatic...
10:52
Zack
that was not a goal
10:53
mr x
its a nice goal though?
10:53
Zack
we want to use futarchy to make decisions, not some AI
10:55
mr x
well yeah... im still thinking about on chain hashrate futarchy
10:56
the futarchy to rule all other futarchies
10:56
they can be offchain
11:20
mr x
parimutuel betting rocks tbh
11:20
just dont bet all your money at once
Deleted invited Deleted Account
17:02
Josh
This does cut down on the number of on-chain txs so it makes this kind of market cheaper.
17:03
Seems like you don't need a market maker for parimutuel.
19:55
Josh
I wonder what percentage of human life is spent arguing about stuff that should be decided by futarchy. Probably 90% of Twitter.
19:57
The stock market was a good invention but it's basically useless now.
21:01
Ben
Can you elaborate? Useless in what way? Good invention in what way?
21:03
I think its futures and options markets are useful as models for amoveo from a ux perspective. It should be similarly possible in amoveo to create singular multilegged vertical spreads that enable very specific control over risk windows
21:05
Like to profit from a low volatility movement in an underlying asset class using a spread strategy such as an iron condor
22:04
Josh
sure, I mean that the signal has been attenuated by fed ETF purchases and worldwide money printing and ridiculously low interest rates
Deleted invited Deleted Account
15:10
Josh
I'm not sure if this will work. You could have thousands of txs over the course of the SC. You don't want to put that all in a tx so you have to break it up anyway, so why not scale it down to O(1) best case, O(log n) worst case?
15:11
Zack
the proof at the end is O(1) for how long the history is.
15:12
is is O(log2(# of elements in the sortition tree))
15:12
if the sortition tree has 1 element, it doesn't matter if we spend that one element back and forth between us 1000 times. Proving the final owner is still a 1-step merkle proof.
16:19
Josh
but won't those ownership transfers each have different contracts that have to be checked?
22:36
Zack
so, I guess I should do a couple examples.
Lets say that Alice makes a new sortition tree.
Alice Bob and Charlie have pubkeys Pa, Pb, Pc
So initially, the sortition tree is: Pa.
A sortition tree node looks like:
{node, contract, owner_if_true, owners_if_false}
A tx to spend some sorititon value looks like:
{sortition_spend, from , to, where}
Next, Alice splits her vlaue into btc-stablecoins and long-veo. She makes a tx like {sortition_spend, Alice, Alice, BTCstable}
so the 2nd version of the sorititon tree looks like:
{node, BTCstable, Pa, Pa}
Next, alice wants to spend all her stablecoins to bob. she makes a tx like {sortitoin_spend, Alice, Bob, BTCstable}
And the 3rd version of the soritiotn tree looks like:
{node, BTCstable, Pb, Pa}
Next Alice wants to spend 1/2 of her long-veo to charlie.
she makes a tx like {sortition_spend, Alice, Charlie, [not(BTCstable), RNG<1/2]}
and the 4th version of the sortition tree looks like:
{node, BTCstable, Pb, {node, RNG<1/2, Pc, Pa}}
so you can see, in the transition between the 2nd and 3rd versions of the tree, it did not get any bigger.
So the size of a proof that you had won, also did not get any bigger.
in the transition between the 3rd and 4th version, it did get bigger. so a merkle proof that Pc or Pa won, it would involved 2 steps.
22:54
mr x
hash rate prediction error as a reward signal in blockchain brain
23:05
Josh
Right, so if the txs are reusing the same contracts it doesn't get bigger, but if people are using new contracts on each transfer it will grow.
23:05
Zack
it could shrink too
23:05
if someone owns adjacent regions
23:06
Josh
but I think it will be pretty common for someone to spend only part of his value
23:07
Zack
we have to think about what users would practically want.
Like, how many layers deep of contracts would they ever actually want.
I can imagine like 2 layers.
If you want to bet on sports or whatever using stablecoins. but 3 or more layers seems unlikely.
23:07
just spending a fraction of your money isn't a smart contract. we just divide up the probabilistic value based on the RNG. no contract ever needs to be put on-chain for that.
23:08
Zack
I could imagine this tree getting pretty unbalanced
23:08
like, if alice spends 95% of her money, to someone who spends 95%, to someone who spends 95%...
23:09
{node, 95%, Pa, {node, 95%, Pb, {node, 95%, Pc, {node .... }}}}
23:10
and then the merkle proof that needs to be included with each tx could get really big
23:10
I wonder if they could be incentivized to atomic swap to own more convenient chunks with smaller proofs.
23:11
Josh
but they'd have to pay for onchain txs
23:11
seems like it would be easier to just get the proof down to log n
23:11
Zack
you mean proving ownership at the end using the fraud proof?
23:13
Zack
Amoveo uses the stateless full node design.
So in order to spend some value in any tx, you need to have a merkle proof showing that you own this value.
if the sortition tree is unbalanced, then these merkle proofs could become too big.
It is a problem unrelated to proving ownership at the end.
We already handled the case of proving ownership at the end
23:17
Josh
are you referring to the sortition_spend tx here?
23:17
Zack
proving ownership at the end is more complicated, because you need to run smart contracts on-chain. But we only do it once per sortition tree, so it is not an issue.
All the small txs to transfer ownership while the sortition chain is still active, we need these txs to each be individually small
00:08
Zack
I guess there could be a specialist who buys up deep branches and merges them to balance the tree.
But every time he swaps some value this way, it involves on-chain txs.
Besides a tx to spend some value in the sortition tree, and a tx to merge adjacent regions, I think we need a tx that requires 2 signatures for swapping 2 regions.
02:26
mr x
maybe hash rate futarchy can be used to make the native token stable
Deleted invited Deleted Account
04:09
Zack
There are ways to re-balance the sortition tree without anyone's permission.
As long as in the rebalanced version, everyone is owning exactly the same slices of the probabilistic-value-contract-space.
04:11
{node, <1/4, Pa, {node, <1/2, Pb, {node, <3/4, Pc, Pd}}}
is the same thing as
{node, <1/2, {node, <1/4, Pa, Pb}, {node, <3/4, Pc, Pd}}
except the second one is balanced and the first is not.
04:11
I wonder how much of the tree we need to load into ram to do these re-balance operations.
04:12
maybe some combination of atomic swaps with re-balances would be more efficient than just doing one of the strategies.
04:14
maybe this strategy isn't as good as subcurrencies like in ethereum. we need to compare the tradeoffs more carefully.
05:24
mr x
can you choose to pay higher fee in amoveo?
05:24
mr x
fees are burned?
05:25
Zack
Goes to miners
05:29
mr x
burning fees is the only way to remove coins from circulation
05:30
Zack
A fixed amount is burned for each tx type.
Specified by governance values.
So the miner needs to receive at least this much of a tx fee to cover the cost of the burn fee.
The burn fee comes out of the block reward.
05:31
mr x
right so some of it is burned
05:32
block reward = money printing, fee burning= taxes
05:34
Zack
The block reward had a cost. Of the pow.
Money printing has no cost.
Economically, it is more similar to mining gold, than it is to printing fiat.
It is like they are converting value from electricity form to cryptocurrency form.
05:35
mr x
yes it is fair way to bring money into circulation
05:46
hahs rate futarchy on block reward and feeburning gives optimal monetary policy?
05:47
no more magic numbers
06:31
Zack
I don't think there is an ideal stablecoin.
Everyone has unique financial needs.
Eslam Ramadan invited Eslam Ramadan
07:25
mr x
this stablecoin is not derivative
07:26
it is the native coin of the chain
07:45
mr x
how would you implement onchain hash rate futarchy?
07:46
Zack
On chain markets aren't secure. Miners can front run
07:47
mr x
parimutuel protects against frontrunning?
07:47
everyone gets same price in the end
12:49
Zack
with the subcurrency design, everyone's ownership in the subcurrency is recorded in a balanced tree. So we wouldn't have to deal with rebalancing.
In an Augur-style shares subcurrency, there are 2 main steps everyone needs to go through.
buying the shares, and then selling them when you are done, or when the contract ends. So, at least 2 txs per person.
in sortition trees it is the same way. You have one tx to buy in, and then one tx to sell your value to the RNG-liquidator at the end.
12:57
So, how about we have a subcurrencies tree. each subcurrency in the tree contains a pointer to it's own merkle tree of accounts. It specifies an input subcurrency type.
So once a subcurrency exists, you can make a tx that splits some of your input currency into 2 or more new currencies. And it allows for the reverse. if you have both kinds of subcurrency, you can merge them back into the input currency.
The subcurrency has the hash of a smart contract written on it, and an expiration.
After the expiration it becomes possible to run the smart contract, which calculates the final relative price of the 2 subcurrencies. So you can cash-out either one back to whatever the input currency was.
I guess for the single price batch market to work, we would need lots of channels that are priced in the different currencies.
So each subcurrency would need a channels tree as well.
13:07
maybe we store the sub-currency accounts and channels in the same accounts and channels tree as everything else, and we just include an extra field to specify which currency it is denominated in.
13:10
we get basically the same security guarantees with pruning by trusting the headers, and only syncing the most recent 2 months or so of blocks.
So pruning really isn't an advantage.
13:11
and since you need to write on-chain twice to get in and out of the sortition tree, the RNG process isn't helpful for scalability.
13:14
I think we should probably add N-party channels to Amoveo.
Based on our discussions about scaling up the lightning network.
This seems to be a feasible way to solve a lot of the liquidity issues.
13:15
Crypt Dweller
What is your biggest goal to accomplish over the next 6 months, Zack? What would you like to see built by 2021?
13:15
Zack
This isn't as exciting as we had hoped that sortition chains could have been.
But it is compatible with the stateless full node model.
It is entirely secured by nakamoto consensus.
It only uses technology that we already understand.
And it is probably the best way to do blockchain-secured financial derivatives given the technology that is available today.
13:16
Crypt Dweller
That sounds good
13:17
Zack
I think this will keep us in a good position to continue adopting scaling technology as it is invented in the coming years.
13:27
the limitation of channels is that you either need your partner to cooperate, or you need to wait a delay and post the contract on-chain.
the limitation of a sub-currency is that you can't update the contract once it has been made.
So I am thinking, instead of using channels priced in the subcurrency for each trade in the market, we can make sub-sub-currencies. and the smart contract to enforce single price batches could be the contract that defines the new subcurrencies.
That way, you can sell your unmatched order without needing the permission of the market maker.
or you can sell your unmatched order back to the market maker, to cancel your trade.
13:28
Crypt Dweller
Oh, that sounds like an important functionality
13:29
What you are building is so novel and different from the rest of the crypto projects, it's hard to make sense of it all sometimes
13:31
I'm glad there are people like Josh and Mr Flintstone who really understand and thus can provide good feedback to you, although sometimes I worry you get so wrapped up in the technical design you lose sight of what ordinary users will want and be able to use--but I don't think that's the case, because I know how much you care about making it functional, and you are doing the best you can do with the resources available
13:43
I'm clueless myself, but it's objectively true that Amoveo is superior to Augur and other DeFi projects that purport to provide blockchain solutions for derivatives trading. First, Amoveo can do a lot by merely surviving and proving that it's invulnerable to the kinds of attacks that will eventually destroy competitors, secondly it needs to offer a better betting tool than those platforms, so that their former user base will prefer Amoveo
13:46
It's really an all or nothing proposition with Amoveo. If it succeeds, there's basically no limit to its growth, like it has been with Bitcoin. But so far it has failed to attract any organic betting activity.
13:47
I guess it's still like a less than 5% chance of success, as Zack as estimated before
13:49
I wonder what the bottleneck is. The Vikings weren't able to sail across the high seas until they invented a keel for their dragonboats. Is there some simple feature Amoveo is missing? Or has Zack already discovered it, and other people haven't realized how to use it yet?
Deleted invited Deleted Account
Deleted invited Deleted Account
Ammar Ashraf invited Ammar Ashraf
19:40
Josh
Can you elaborate on the sub-sub-currencies? I didn't really get that.
Truong Van Dung invited Truong Van Dung
21:22
Zack
For example.
There could be a subcurrency for stablecoins.
And we might want to have a stablecoin denominated bet on the result of a football game.
We could make a subcurrency to split stablecoins into 2 types.
A-coins, for if Alices team wins. And b-coins, for if her team loses.
So anyone can send stablecoins to this subcurrency, and get the 2 types.
Or they can send the 2 types to get stablecoin back.
Once the game ends and we know who wins, the correct type can be exchanged for stablecoins, and the wrong type is worthless.
21:23
Making a new subcurrency is a way to have a turing complete contract, and you can sell your position in the contract without anyone's permission
21:24
Channels have the advantage that the contract can be updated.
Subcurrencies have the advantage that you can sell your side immediately without needing permission of the other side.
21:30
It is possible for everyone to sell their position in a subcurrency without us needing to execute it's smart contract on chain.
21:30
Since they know what would happen
22:20
Zack
so in this way, the contract is off-chain the same way that contracts inside channels are off-chain.
22:52
Zack
Calling this the "subcurrency strategy" seems fine.
But calling the new on-chain data structures "subcurrencies" is probably not right.
It is a tool for splitting one currency into 2 or more other currencies. And having a smart contract that determines the relative value of each.
So what should we call it?
A "smart contract"?
22:55
A channel contract is mutable, but not shared with the network.
This on-chain contract is shared with the network, but it is not mutable.
Sebastian Anggarda invited Sebastian Anggarda
23:17
Zack
I think bitcoin blocks are available, because you need to download all of them to verify new blocks.
It is part of the proof that miners share to show that their block reward has value.
23:19
If we want to make data available, I think it needs to be folded into a proof that someone needs to share in order to get a reward.
I wonder if we can prove that Nakamoto consensus is the only way to do this.
It would be another way to show that PoS does not work.
00:38
Zack
So what if I lock up some money to act as a block reward in a new temporary blockchain.
The new blockchain could exist for some finite number of blocks. say, 10.
And at the end, we use the RNG process to collapse the state of this new blockchain small enough, so that it can be imported back to the main chain.
00:39
the only way miners of the new blockchain can receive the block reward is if they make the new blockchain's blocks available, so we can know that their blocks are valid.
00:41
so if the amount of txs becomes too big, and miners can't process it all, they could specialize in mining one of these sidechains and storing some blocks that other miners don't need to store.
The mining hardware would be the same on each sidechain, the difference is the data that you need to store and process.
00:42
seems like these sidechains could have faster block times than the main chain. especially if it is being used in one city.
00:45
using a fraction of the mining power probably isn't secure against double spends.
But maybe if we merged mined it could work.
00:54
The merge mining strategy fails the same as drivechain. It is cheap to bribe the miners to do censorship attacks.
00:55
So how about if every sidechain has its own mining algorithm and it's own Asics?
So, one blockchain with a different kind of mining hardware for each shard.
00:59
isn't tether on multiple blockchains?
Something like that. one currency spread across multiple shards.
And we would use the RNG lottery process to collapse the history back to the main chain to make sure that money on each shard stays fungible.
01:36
Zack
if this is how it needs to be done, then the cost of each additional shard is very high. and we shouldn't add more shards until there is sufficient demand to afford them.
01:37
maybe it can be cheaper to add shards if we recycle some ASICS that had been developed for a different blockchain project.
01:39
so maybe the on-chain smart contracts should be called "shared contracts"
and the ones in channels should be called "mutable contracts".
If we start allowing n-party channels, the channel-analogy stops working so well.
01:39
mutability and sharability are the distinguishing features of the 2 kinds of contracts we could support.
01:40
or we could name them by what they are incapable of.
the on-chain ones could be "immutable contracts", and the channel ones could be "unsharable contracts".
02:06
mr x
fee burning makes blocksize issues moot?
02:07
mr x
miner cannot create artificial big block
02:21
Josh
That off-chain scaling channel is really good but there are a ton of smart people in there all working on this L2 problem and it seems the best they came up with so far is optimistic rollup. I think it might be a lot easier to scale L1 at this point.
02:22
if we have subcurrencies do we still need channels? what's the use case?
02:25
Zack
Contracts in channels are mutable.
02:26
So any sort of unplanned update to the contract state, you would want a channel.
micro payments for example.
02:28
Josh
any other examples of unplanned updates?
02:31
Zack
Slot machine.
Blackjack
02:33
There is one thing sortition trees could do that I'm still not sure how to do with subcurrencies.
Lotteries.
02:33
The subcurrency design we talked about so far has a small finite number of kinds of coins that the input currency gets divided into.
02:34
For a lottery we would want a basically continuous region of probabilistic value space.
02:45
mr x
how to do retargeting without timestamps?
02:47
orphan rate measures block interval?
02:49
Zack
Orphan rate is too cheap to fake, or else it is too high and encourages centralization.
What is wrong with timestamps?
02:50
mr x
blockchain supposed to be objective clock or something
02:50
not refere to other clocks
02:52
you can include hash of orphan block in next block to get some minireward
02:55
timestamps and blocksize must be removed from blockchain designs
02:56
block reward and fee burnrates must be set by hash rate futarchy
03:10
monetary policy(reward and fees) must be set to maximize the size of the economy(hash rate)
03:12
Zack
as long as the blockweight algorithm is right, i don't think it is an issue.
03:12
the side that had the most work done is longest. not the side with the most blocks
03:13
miners are incentivized not to pick times in the future. their block might not get included.
03:13
and they are limited in the past because of the times of other recent blocks
03:14
i think the timestamp is fairly accurate
03:18
it would be nice to get rid of them
03:21
blockchain should be kept pure
03:22
and when you finally let outside world in it should be through hash rate futarchy
03:22
Zack
What are you worried about in regard to the timestamp?
We want blocks to happen at a regular interval, right?
03:23
mr x
yea it refers outside time
03:23
orphans are objective measure of block interval
03:23
do everything internally as far as possible
03:24
Zack
We are trying to make a useful product.
HERMAN NOH invited HERMAN NOH
03:25
mr x
maybe this is also the simplest design
03:27
oracle resolution would also happen ultimately in heavens court
Alip Amir invited Alip Amir
19:14
Josh
Might have to basically do the sortition chains but without the off-chain stuff it would avoid a lot of the problems.
19:14
Really just an extra merkle tree, right?
19:17
Zack
A merkle tree that says how many coins are in each branch. And the rng process.
19:17
Maybe lotteries aren't useful though.
19:24
Josh
It's probably not the most important thing, although might help with adoption.
19:26
I think the subcurrency stuff is the most crucial.
20:27
Zack
im wondering about the cleanest way to do this.
like, do we want a different accounts and channels tree for subcurrencies, or will we modify the current trees to support them?
Maybe we need a tx type to move your veo from the old accounts tree to the new one.
20:28
I feel like using the same format for all the accounts and channels is going to make programming light wallet stuff easier. in comparison to having a different format for veo-channels and subcurrency-channels.
21:38
Josh
How will the multiparty channels work? Would all the parties have to sign everything? Or more like the waivers idea?
21:40
Aggregated sigs would be useful for this.
23:22
Zack
Everyone would sign.
Yeah, it might be a good use case for a different signature format to save space.
00:29
Josh
I think I read that Ed25519 verification is something like 70x faster than secp256k1 but we'd have to benchmark. That has scaling implications if sig verification is a bottleneck.
00:31
Zack
yeah, I think it works better for the multi-party signatures too.
it might make sense to switch now, if we are going to make an entirely new tree for accounts and channels anyway
00:32
looks like ed25519 is in erlang's standard libraries now too
00:32
Josh
yeah i believe you can set up a mutual pubkey for a bunch of privkeys and then everybody just cooperates to get a single sig
00:33
and the hubs have to cooperate on signing anyway so shouldn't be an issue to generate a shared pubkey
00:35
you can also do batch verification which speeds things up when verifying blocks which should double the speed
00:35
Zack
verifying any signatures is paralelizable
00:38
Josh
it's not just parellelizable, checking each signature takes half the number cycles than checking just one at a time.
00:38
on top of that you can parallelize it
00:39
Zack
interesting.
I wonder what the relative costs are of signature verification vs merkle proof verification.
A signature involves taking the hash of the contents. and the merkle proof is like 5 or 6 hashes.
00:40
i think because of the way sha256 works, taking the hash of a bunch of chunks of data is about as costly as taking the hash of the entire data at once
00:41
I guess in the current version of Amoveo, serializing from JSON to the binary format that we take the hash of, that is the cpu's bottleneck.
00:43
if we kept things serialized more of the time, it would probably be a more significant improvement in comparison to anything we do to make signatures faster.
00:43
Josh
isn't blake3 faster than sha256? maybe these decisions are a big deal for scaling.
00:44
more than an order of magnitude faster
00:52
Zack
these kinds of updates aren't very controversial or technically difficult to implement, and we wont get any immediate benefit from doing them now.
getting the subcurrency update active should give immediate usability benefits, because we could have markets with less wasted liquidity.
00:54
i'm just thinking more about L1 scaling since that's all we have now. definitely don't need to do it all right away.
00:55
nice thing about merkle trees is they shouldn't require much memory to verify. just have to be smart about ordering the leaves.
00:56
also lots of parallel processing
01:05
Zack
the merkle tree library already supports batch writing
01:05
and you can run it in RAM or hard drive.
01:21
Josh
How are the accounts in the merkle tree ordered? By date of creation?
01:22
Zack
the hash of the pubkey
01:29
Josh
Doesn't that mean I have to keep all the bottom level hashes in memory so that I can sort them each time there's a new account?
01:58
mr x
expain me why hash rate futarchy doesn't solve everything
01:58
its the biggest idea since bitcoin itself
02:00
Zack
It is like ethereums account tree.
the path you walk to store/retrieve an account is determined by the pubkey.
So given a merkle root, and a proof of a current account state, and a change in balance to execute for that account, you can calculate the new merkle root and create a proof for the new version of that account.
02:03
mr x
is that like sparse tree?
02:05
just fund public goods like: print money to this proposal if hash rate futarchy says so
02:05
everything onchain wtf
02:06
all ths collect money to fund public goods is backwards
02:06
you should print money for public goods
02:07
Zack
Yes. It is sparse.
02:08
mr x
what if collision?
02:09
Zack
If 2 pubkeys hash to the same value, then Sha256 is broken.
02:10
Collision of Sha256 is cryptographicaly impossible.
02:10
mr x
2 pubkeys can map to same merkle path?
02:10
it jsut deep enough?
02:10
Zack
No. The path is determined by the hash of the pubkey
02:11
mr x
its 256 deep tree
02:11
Zack
You can get a partial collision, of like the first 80 bits.
But a collision of all 256 bits is impossible.
02:12
It is base 8.
So the depth it supports up to 32 steps.
But in practice, more than 10 is too difficult to cause.
02:12
It is computationally infeasible with today's tech to get much more than 80 bits of collision.
02:15
so it branches 256 times each level wut
02:18
Zack
No. It is either 8 or 16 per level
02:18
Zack
I wrote this library before they came up with that proof that binary trees are always best
02:19
Because the cryptographic parts can be stored together in pages on the hard drive.
02:19
So you can optimize the size of the proof and the size of pages to read from the hard drive individually.
02:30
mr x
hash rate futarchy is the real rokos basilisk
02:39
Zack
So, "sparse" I think means that it is possible to make a proof that the tree lacks an account for a particular pubkey.
This is important for the stateless full node design, because we need to know that an account does not exist in order to create it.
02:44
Josh
You get that by ordering the leaves, right?
02:53
mr x
position of every possible account is predetermined
Deleted invited Deleted Account
04:36
mr x
pow is not there to the extent it helps us achieve our goals, pow is the goal
04:39
the move to lower block reward was borne out of fear and greed
04:40
it was no true futarchy
04:40
if you concentrate purely of hash rate you are immune to self deception
04:59
mr x
and this is not only about amoveo but whole crypto space
04:59
bitcoin cheering block halving, ethereum going pos...
05:00
we are in position to be first to confess our sins...
05:02
futarchy always felt like a great idea but applying it never quite worked
05:03
amove got close by using it to make choices about itself
05:05
but the objective was something external like "price" or "market cap"
05:05
the correct choice obvious in hindsight
05:06
blockchain finally closing on itself
05:24
Gregory
zack, when will you admit failure? :)
05:50
Zack
In entrepreneurship is is called "pivoting", and it is a good thing.
06:02
Gregory
ok. when pivot?
Deleted invited Deleted Account
08:44
Topab
Why? I don't understand why futarchy for hash rate is that of a deal
08:52
mr x
because hash rate is objective measure how much stuff is happening on the chain
08:52
we want to maximize that
08:52
and it is fully accessible from within the chain
08:54
or how much stuff is happening in the economy of that chain
08:54
something like that
08:58
Topab
Can you give an example of that being applied into something practical?
09:00
Zack
Different blockchains compete against each other almost like animals in an ecosystem, or cultures in humans.
Probably there is something that should be optimized which would allow a blockchain to out compete the others.
09:09
mr x
hash rate is sign of life
09:15
we are building a god here
09:15
if it helps us achieve something practical then great
Deleted invited Deleted Account
09:56
Topab
I get this. No hash rate = its dead, but what is the use of futarchy and hash rate, how can it be use to increase its life?
09:59
mr x
we ask market about future hash rate given network does x vs not x
09:59
if x leads to increase compared to not x network automatically does it
10:02
Zack
I feel like what we are really trying to maximize is the long term expected market cap.
And the rate at which the market cap is growing in the long run is determined by how much value is being pumped into it by miners converting electricity value into new cryptocurrency.
So the best way to maximize the long term expected market cap, it might be to maximize the hashrate.
It is hard to be sure about these things. People don't really agree on what are the most accurate ways to model <why things have the prices that they do>
10:03
and hash rate is property of the network unlike market cap
10:13
maybe this also gives stable crypto coin
10:13
but let's not talk about that xD
Deleted invited Deleted Account
10:34
Zack
so I think im going with the positive version. "mutable contracts" "shareable contracts"
Deleted invited Deleted Account
Deleted invited Deleted Account
12:24
mr x
why do assurance conracts when you can just do hash rate futarchy about money prinitng for a proposal
12:27
choices have to be big enough
12:28
package many choices into single proposal maybe
12:28
Zack
But then can't bad choices get mixed into a proposal, I they are too small the matter much?
12:29
Maybe it is better to maximize the sum of hashes in the next month
12:29
mr x
they could but then again thye dont matter much hmm
12:30
Topab
Price (market cap) and cost (electricity/hash rate) can not be the only two variables. I think value should not be excluded, what is the value of all that hash rate? The value can be quantify somehow, for example in terms of fees reduction, access to otherwise non accessible markets to people, elimination of third party risk, ... Is Amoveo providing all that? I recently hear that for oil it goes like this: price now = 25 USD, average production cost = 60 USD, value estimated in calories and made those calories equivalent to a man work force = 4.5 years man power. Basically oil is very undervalued right now according to this. Of course man not only have brute force but can think and are more versatile than a machine. Also, there are alternative forms of energy.
12:30
mr x
bumper of hashes?
12:47
mr x
maybe how far into future the futarchy looks should not be determined before hand
12:48
like depend on how long it takes for the futarchy to settle down
12:49
big volume futarchy settles after long time and the extent it looks into future grows along with it
12:52
fully generic futarchy about anything that has no free parameters
12:54
not sleep long time
12:58
futarchies only have effect if they get big enough
12:58
they start without certainty if they ever get to have effect
12:59
they join together to get big enough
12:59
and as they grow they gain more time to become relevant
Shersingh Anand invited Shersingh Anand
13:04
mr x
futarchypreneurs
13:30
mr x
what happens on chain should be about the chain
Samson Kassu (#Chosen) invited Samson Kassu (#Chosen)
Cypto Bit invited Cypto Bit
14:00
mr x
people could do good things for the network even without telling anyone before hand
14:00
then there could be hash rate futarchy about printing a prize money
14:01
it would set a nice precedent that the network rewards nice behavior...
14:03
no complicated setting up stuff..........
14:03
you could trust that the network will reward you
14:10
thinking about the basilisk usually means mental breakdown imminent
14:29
mr x
can also print money for people who torture those who could have helped the network but didnt
14:29
future hash rate would approve
14:39
there is noone giving money for torture
14:39
only network operating according to protocol
14:41
no torture crowd funding or assurance contracts
14:41
just money printed according to protocol rules
14:43
anyway evil things are not good for the hash rate so no worries imo
14:53
Josh
Could go the opposite way, frozen contracts and private contracts
15:46
Enri Topciu
Where to exchange veo to eth
17:16
Enri Topciu
Don’t work
Deleted invited Deleted Account
19:41
Zack
"frozen" and "private" are more known words.
"mutable" is kind of CS specific.
MotaL OP invited MotaL OP
20:42
Zack
ive been thinking it might be nice to drop support for early blocks at some point.
We could maintain a legacy version of amoveo to sync them.
It would be nice to get rid of all the code from before hard updates. code that will never get executed for verifying future blocks.
20:44
mr x
ruthless checkpointing but keep the data somewhere so that it is somehow possible to replay history
20:46
Zack
you can calculate the entire state tree at any point in history just by looking at the merkle proofs included with each block. without having to process txs.
Deleted invited Deleted Account
junior kabuba invited junior kabuba
Kodwo Armah invited Kodwo Armah
حسن البرهوم الأموي invited حسن البرهوم الأموي
anonymous airtel invited anonymous airtel
02:13
Zack
im thinking of making a rule, that new members need to say something about amoveo within 5 minutes of joining, or they get kicked.
02:28
sanket
Maybe, an intro is god enough I think.
Tsehay Sima invited Tsehay Sima
Ramesh Kurade invited Ramesh Kurade
Young Mike invited Young Mike
07:34
AlexShelpin
The most accurate definition of value I have ever heard and thus drives prices along the demand supply game is something like “Value is that quality that makes anything desirable” of course this can and should be understood under specific contexts,timeframes,cultures....imho miners motivation is not bringing value but grabbing value,then there is a virtuous loop because they make the network more desirable for others...cleanse,rinse and repeat... electricity being converted into cryptocurrency is not bringing value...value comes from solving problems that the society at both individual and company level has by making lives easier/more pleasant / profitable etc ...then miners and value come...when real value is delivered the business model is not relevant anymore ... it will naturally find its fit
07:53
mr x
Electricity being converted into value means that there is value being created in the economy of the chain.
07:58
Blockchains are not tools. They are lifeforms.
08:00
Life is maximum entropy production.
08:01
or something like that xD
08:06
At this point blockchains basically only form primordial soup
08:07
So not real life going on yet.
08:09
There needs to be proper autocatalytic cycle.
08:09
Hash rate futarchy creates this.
08:10
AlexShelpin
Interesting
debate might be coming here...😝 electricity converted into coins via pow does not necessarily mean value creation in the same way that electricity converted into heat does not necessarily imply any vale, if no one desired that heat ,or that coins...there is no value,loved your analogy about blockchains and lifeforms,we are in the same page... lifeforms have a function in a given ecosystem that makes them valuable for that particular ecosystem...blockchains should do the same,they are not here to automate business processes they are here to solve serious problems for everyone...sometimes there is cool stuff being built from a technical point of view but then they turn into solutions searching for a real problem
08:11
mr x
Bitcoin explosion is runnign out of steam. It actually doesn't properly feed back to itself...
08:12
AlexShelpin
Not saying it is amoveo case,wanna make this clear just in case ...I do not have enough knowledge about amoveo...would love to read more about hash rate futarchy ,any material out there ?
08:13
Ive taken the idea seriously for couple of days
08:14
AlexShelpin
👍will be paying attention to it
raxit mevada invited raxit mevada
Solo Solo invited Solo Solo
13:06
mr x
yeah sounds reasonable. still references outside time :P but whatever
13:26
mr x
initially just onchain hash rate futarchy about monetary policy (rewards, feeburns)
13:26
nice monetary policy experiment with built in gambling
13:31
what happens onchain should be about the chain
Pecador Inocente Mazive invited Pecador Inocente Mazive
Ali Belkheir invited Ali Belkheir
Ankit Porwal invited Ankit Porwal
17:36
Josh
There are lots of fake accounts on the internet. The goal isn't to get lots of accounts into the channel, it's to get quality people to discuss ideas.
Deleted invited Deleted Account
kaleabe worku invited kaleabe worku
Deleted invited Deleted Account
Mathiu Zatch 4 años en cripto 🇦🇷 invited Mathiu Zatch 4 años en cripto 🇦🇷
Hollar bb invited Hollar bb
Deleted invited Deleted Account
01:23
Josh
is the contract-id the id of the subcurrency? the subcurrency type is one of the types of coins that can be created by that subcurrency? So in the case of usd stablecoin with p-usd (pegged usd) and 2-veo (double volatility veo) the subcurrency type could be p-usd or 2-veo?
01:25
when you run the recombination tx, how do we determine what proportions of each subcurrency type you have to send in? is that when we run the contract?
01:26
the idea of subcurrencies with source subcurrency is huge. also having subcurrency denominated channels is great.
01:26
Zack
1:1 for creation and destruction. So the supply of Veo is the same
01:27
Probably the contract I'd is like hash (contract-hash ++ number of subcurrencies)
02:11
Mr Flintstone
can we make these shareable contracts fungible in recombination if hash of oracle info and contract code is the same?
02:13
Zack
You can just reuse the same one. If they are programmed to do the same thing, then they will have the same I'd.
02:14
Ownership in the shareable contract is spend able in fractions. It is a kind of subcurrency.
02:15
Mr Flintstone
you could trade these on exchanges
02:16
Zack
id like it if we were using amoveo tech to trustlessly trade them. but sure.
02:16
Mr Flintstone
ok haha so atomic swap into synthetic btc
02:17
Zack
you could do a swap to buy an open order in the market, and then wait to see if it gets matched in a batch
02:17
Mr Flintstone
even if they are traded on exchanges they are still doing a good thing providing people with additional financial & risk management tools
02:17
Zack
the open order is it's own subcurrency
02:19
Mr Flintstone
why wouldnt you swap into an existing subcurrency so you dont need to rely on getting your trade matched?
02:19
Zack
so that you trade at the correct price
02:20
Mr Flintstone
oh cool
02:20
Zack
it works as a limit order
02:20
and the market has batches
02:24
swapping between pairs of currencies also works.
02:25
but I think to really succeed, we need to have the best prices. so we need good markets.
Deleted invited Deleted Account
02:31
Zack
hi luna. same something.
04:48
mr x
how about difficulty adjustment algo that works every block like: if there was orphan in previous stage increase some amount, and if not decrease some amount
04:56
sorry this is now my learn blockchains channel
04:57
Josh
If I take 1 veo (say it's worth $100) and split it into p-usd and 2-veo; later, 1 veo is worth $25, so my p-usd is worth 2 veo. Does that mean it's not worth it for me to exchange it back into veo?
05:07
Mr Flintstone
your p-usd can only be worth how much went into the contract initially, so 1 veo
05:09
Josh
Ah right, need to be careful about margin call type situations.
05:11
So is there a way to create a stable coin that can handle a 50% drop?
05:12
you allocate 0.1 veo to the p-usd and 0.9 to the 2-veo or something
05:12
that could handle a 90% drop
05:13
would be an interesting way to get small amounts of leverage on your stack while at the same time providing a good drawdown resistant + spendable synthetic to amoveo users
05:13
Josh
Ok but that wouldn't be 1:1
05:14
Mr Flintstone
cant it still be 1:1? Two tokens make one veo unit
05:14
even if the tokens have different margins
05:15
Josh
So let's say veo goes from $100 to $200
05:17
Mr Flintstone
it seems nice to do this and shift the burden of the margin management from the bad times when price goes down (pusd holder) to good times when it is going up (2x holder) for stablecoin contract participants
05:22
Josh
So in your example the p-usd starts at 0.1 veo and can go to 1 veo. The 2-veo starts at 0.9 veo and can go to 1 veo, but it can also go to 0. What's the incentive to hold 2-veo?
05:24
Mr Flintstone
i dont think it is 2-veo anymore lol
05:28
if you create both the stablecoin and the leveraged coin and sell the stablecoin for 0.1 veo, you now have 1.1x exposure from just 1 veo of capital.
05:33
Josh
Let's call the leveraged veo lveo
05:34
Why is lveo worth 1 veo? That would mean p-usd isn't worth anything.
05:36
Oh you only have 0.9 lveo which is worth 0.9 veo, so one lveo is worth 1 veo.
05:36
Jon Snow
Should rearrange the letters and call it love
05:40
I'm still confused about this, need to go through a full example.
06:00
Živojin Mirić
Omg Josh is altZack :O
06:02
Živojin Mirić
Amoveo Josh Vision
AJV
06:02
Živojin Mirić
Whatever it takes to complete its vision
06:35
It’s like watching Satoshi discussing bitcoin with hal finney in the early days
07:33
Mr Flintstone
If you wanted to convert your synthetic usd back to veo in this subcurrency model, i bet you could get something like a flash loan for the leveraged side ? Then you can effectively redeem on-chain while only holding one side
07:34
Zack
you could swap to veo directly. or you could use a market. or you could buy the other half of the contract and combine them.
07:34
Mr Flintstone
i mean the last part
07:35
you borrow veo, buy the other half and then combine then return the veo before the end of the block
07:35
all in one, so if any fail they all fail
07:36
Zack
oh, like if I have type A, and you have type B, and we both want a certain portion of veo. we should be able to make one tx that sends both our types to the contract, and outputs veo to both of our accounts in the ratio we had agreed upon
07:38
would we want that in both directions?
07:39
so if 2 people want to make a bet. one doesn't have to like, make both types of tokens and then sell one type to the other.
Instead a single tx can cause them both to end up holding opposite kinds of subcurrency, all in one step.
18:12
Josh
it's not really 1.1x though, since the formula only has addition: pusd + sveo = veo
18:17
the leverage starts at 0 and gradually goes up to a max of 1.1x as the price goes up
Deleted invited Deleted Account
20:27
Josh
The sveo seems a little strange to me if I'm understanding this right. How useful is this token?
20:33
Zack
the product we want to make hasn't changed.
Financial derivatives are still financial derivatives.
The sum of the 2 sides of a contract needs to be the same as the source currency that denominates that contract.
20:33
Financial derivatives are a way for people to make bets together. To sell risk to each other.
20:55
Josh
Do you have an idea for how to do this stablecoin contract? I don't think it's easy to just get simple leveraged veo, so I'm trying to understand what deal the different players make with each other.
20:57
Zack
You can already make stablecoin contracts like this on amoveo.
20:57
But currently only inside of state channels
21:14
Josh
Do you have an example of the logic of the contract? I'm interested in seeing how it works.
21:16
but basically, the idea is that one side of the contract should be worth a constant amount in USD terms, and the other side gets whatever veo are left over.
21:17
and it is only enforceable within some margins, and the margins are limited by how much veo we each put into the contract.
21:21
Josh
ok, that sounds like what I was discussing with
@Jbreezy0
21:27
the leveraged veo should still be useful, it's just not a simple 2x or 1.1x leverage but gradually goes up as there's more price change in either direction.
21:59
Zack
Yeah. The opposite sides are inverse of each other.
You could make the leveraged Veo side more smooth if the stable side was less smooth.
22:04
Zack
Maybe it is possible to do a 3 way split so that 1 is a normal stablecoin and 1 is a smooth leveraged Veo.
22:06
Josh
what would the 3rd part be?
22:06
Zack
Whatever is left over so the 3 things can sum to normal Veo
22:06
Josh
but who would want to own that?
22:07
Zack
If the other 2 things are highly demanded, then there could be a premium for people willing to hold the 3rd
22:07
It is usually more profitable to be on the less popular side of contracts.
22:08
Josh
yeah, possible. i wonder how crypto-facilities does their perpetual future contract.
22:08
Zack
Derivatives are a deep subject. The math can get intense.
22:09
But luckily it is already well studied. We don't need to re-derive anything.
22:14
Josh
i hope it doesn't have to get as complex as makerdao
22:58
Zack
Makerdao is like a central bank.
22:58
What we are doing is derivatives
22:58
It is very different
23:26
Josh
but we're trying to do a stable coin, I'm not sure that's a simple derivative
23:48
Zack
Hedging your risk is exactly what derivatives are for.
Derivatives are the best way to do stablecoins, and that entire family of contracts.
23:50
Trying to use a central bank strategy for stablecoins is inefficient.
Different people have different stablecoin needs.
The central bank is a one size fits all solution. It forces some people to have smaller margins than they need. And it forces some people to pay for bigger margins than they need.
Derivatives are optimal because we can fine tune every contract for every customer.
You can buy exactly what you need.
23:52
Gregory
Fungibility is what is valuable and not the fine tuning
23:53
Zack
Why do you think that?
23:53
Gregory
Fine tunning only needed for well capitalized hedge funds who do this through prime brokers like gs jpm
23:55
Zack
You can pay for what you want with Veo. And hedge your risks with derivatives to have whatever risk profile you want.
Whoever you are paying, they can use that Veo to make derivatives for whatever risk profile they want.
23:56
I don't see what any of this has to do with brokers or hedge funds.
Amoveo is for getting rid of the middle man. So you don't need a broker or hedge fund.
Anyone can buy whatever risk profile they want, without having to pay or trust any middle man.
00:27
Mr Flintstone
the leverage is just a point in time measurement of the sensitivity of your pnl to veo’s price
00:28
you can do the math yourself, but within small moves it acts like 1.1x leverage, and then as the price increases/decreases the leverage decreases/increases
00:29
By 1.1x leverage i mean: i am only holding 1 veo, but my profit and loss acts like i am holding 1.1
00:45
Josh
If we take your example of 0.1 pusd and 0.9 sveo (say veo is worth $100), and you sell the 0.1 pusd to Alice for 0.1 veo. Now you have 0.1 veo and 0.9 sveo, which is worth a total of 1 veo. For small moves like 10% I think you'd have 1.01x leverage.
00:46
Zack
im not understanding josh's example.
00:47
if I have 1 veo, I could convert it to 1 s-usd, and 1 v-veo.
If the price of usd drops relative to veo, then the 1 s-usd is worth fewer veo, and the 1 v-veo is worth more veo.
1 s-usd + 1 v-veo = 1 veo. always.
01:05
Zack
I think the math is easiest if you leave everything in veo terms.
So like, if 1 s-usd is 0.2 veo, then 1 v-veo is 0.8 veo.
if the price of usd relative to veo increases, so that 1 s-usd is 0.4 veo, then 1 v-veo becomes 0.6 veo.
01:22
Josh
yeah, that's what i meant. in my example s-usd is 0.1 veo and 1 v-veo is 0.9 veo.
01:24
if the price goes up 10%, s-usd is worth 0.091 veo and v-veo is worth 0.909 veo
01:24
that 1.01x leverage for the v-veo at that point
01:39
Zack
If the price of usd goes up 10%, then s-usd goes from 0.1 to 0.11
And v-veo goes from 0.9 to 0.89
So v-veo has 0.1x leverage against negative usd in this example.
Or negative 0.1x leverage against positive usd.
01:42
Josh
I meant the veo price goes up 10% so from $100 to $110
01:54
Zack
If the usd/Veo price moved 10%.
Then the veo/usd price moves what, 1/(1-0.1)? Well, it is about 10% anyway.
01:55
So it is best to do all the math in Veo terms, then convert units as the last step
01:55
It makes it a lot easier
02:30
Josh
No because the s-usd starts at only 10% of the value so it doesn't contribute much veo to the v-veo
02:30
It has to go to zero to get the v-veo up to 10% leverage
02:55
Zack
so leverage = (how much your asset changed in value) / (how much the reference asset changed)
Lets say the s-usd starts at 0.1 veo per coin
and v-veo at 0.9 veo per coin.
if the value of usd increased by 10% relative to veo.
Now s-usd is worth 0.11 veo, and the v-veo is worth 0.89
so the v-veo changed by 0.01/0.9, which is about 1% and the reference asset changed by 10%
1% / 10% is 10%
So that is why v-veo's leverage is about -0.1 USD at this point.
and s-usd's leverage is 1 USD at this point.
Deleted invited Deleted Account
04:07
Mr Flintstone
say veo starts at 100 usd. If im holding 1 veo normally and veo goes up 10% vs usd i have 10% more usd and 0% more veo. If i have 1 veo, then sell 10 dollars of it as a stablecoin for 0.1 veo and keep the other part of the contract, then veo goes up 10% vs usd i have 11% more usd and 1% more veo
04:08
so for the second example you could say i now have 11%
/10% = 1.1x exposure in usd and 1%
/10% = 0.1x exposure in veo
04:11
bluematt sort of agrees but don't know how to do it...
04:22
Josh
Yeah almost 1% more like 0.9% more veo. And this number goes up as the price increases.
Deleted invited Deleted Account
Deleted invited Deleted Account
05:46
mr x
Politics fill the void of not explicitly trying to maximize hashrate.
Deleted invited Deleted Account
07:55
Jon Snow
As long as Zack is alive
10:08
Zack
further generalizing based on mr flinstones suggestion about buying subcurrencies on-chain.
Lets say there is a contract with N types of subcurrency.
In general, we could have N people involved in a trade.
Each one wants to either pay or receive veo, and for each of the N types of shares, the same amount needs to either go to or come from each person on the list.
10:08
so we can have a list of veo-participants like [{Pub1, amount1},{Pub2, amount2}|...
10:09
and a list of who gets/loses the types of subcurrency [Pub1, Pub2|...]
10:13
so for the sharable contracts, do we want people to be able to provide evidence to them at expiration?
10:13
and if so, do we allow others to show counter-evidence?
10:14
it could work like settling a channel.
10:14
showing evidence like this would be necessary for the on-chain limit order idea we had discussed previously.
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
13:42
Zack
How many sub-types is the most we could ever want from a sharable smart contract?
I feel like there should be a way to show that we don't need more than 3.
Having a limit on this will let us use a more efficient algorithm.
13:43
for a lottery we would want like, 1000 different sub-types.
17:24
Josh
We could try to build a bunch of use cases and see how we'd implement them with subcurrencies: stablecoins, betting on sports or other events, options on stocks or precious metals, combining a few stablecoins into a basket, combining a few different bets in different ways.
Crypto Ape invited Crypto Ape
17:28
Ben
first zack has to declare a "stable Version" and then we would need to get an UI/UX otherwise it will be all theoretical effort.
17:31
Josh
You need the theory before you can build it
17:48
Ben
of course, i thought you passed that stage and were looking for field verification.
18:07
Josh
nope, not yet. amoveo's biggest advantage is getting the theory right.
18:16
Ben
fair enough, back to my cave waiting for D-day ;)
18:27
Josh
feel free to help develop the theory, too 🙂
20:50
Zack
I guess we will just use 32 bytes to store the winning value.
If one type wins, we can store the integer for that type.
If more than one type divide up the winnings, we can make a merkle tree.
key 0 will store the denominator, and N; many_types>=N>0; will store the relative amounts. so for example:
0: 10
1: 3
2: 5
3: 2
Would give 30% of the value to type 1, 50% to type 2, etc
00:26
Zack
as far as the hard update, it looks like we need 3 merkle trees, and like 6 new tx types. then we can start adding it to the light node.
Deleted invited Deleted Account
07:37
It isn't much different from the existing database used for accounts.
07:40
I guess the important change to notice is how the key that defines the location of your object has changed.
make_key/3
so this means each account can only hold value for one pubkey, in one contract, of one type.
If you hold subcurrency for 5 different shareable contracts, then you have at least 5 different accounts in the merkle tree.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
21:14
Zack
It was a mistake to write the initial balances on the channels.
That part should stay off chain, and it makes everything simpler.
21:15
The new version of channels will support any number of participants, and require fewer bytes of on chain data.
And it is possible to put normal Veo into the new kind of channels.
So maybe we will get rid of the old kind.
21:25
We hash together the txs in each block to make a merkle root to write on the header.
This way you can prove to a light node that a tx exists.
21:25
Currently we use the same strategy as bitcoin. Adjacent txs are hashed together to make a binary tree.
21:29
I'm thinking we should switch to the sparse merkle tree format. So you can also have a proof that your tx has not been included.
21:31
Is that something we want?
19:43
Zack
thinking about the shareable contracts, we have a choice.
1) there is a set expiration date, and anyone can provide evidence during a certain evidence period.
2) it works like channels. every time someone provides new evidence, the timer resets, and everyone has more time to provide evidence.
19:46
advantages:
1) you can be sure when the shareable contract will expire.
This would make it impossible to write contracts that never expire.
2) you don't always need to provide all the evidence. It can work like a fraud proof, so you only provide evidence if you get challenged.
This can be useful if you will wait for your opponent to provide evidence, and re-use some of their evidence when you create your own evidence.
So this gives us some flexibility in smart contract design.
Deleted invited Deleted Account
07:00
Vitalik agrees but is of course too ego invested in POS wireheading.
Deleted invited Deleted Account
10:26
The idea of tokens or currencies within a chain. Amoveo is avoiding this and sounds reasonable to me but look at Ethereum
12:25
Zack
I guess ill go with (1) for now. it seems simpler. we can switch later if we need to.
12:27
oh right.
Maybe we shouldn't write any expiration on the sortition contract object at all, instead it should be an output of the smart contract code.
12:39
so then the choice is between whether it should become immediately close-able or if it should have some delay for others to provide counter-evidence.
Mgerara Mogithi invited Mgerara Mogithi
Deleted invited Deleted Account
18:55
Josh
Hey Christopher.
Deleted invited Deleted Account
03:11
Deleted Account
Hey guys, whats the circulating supply/max supply/amount mined per day and market cap?
03:11
Can you tell me more about mining protocol? Is it PoW/PoS or something else?
03:12
I think around 71k total Veo. Around 15 new Veo per day
03:12
Deleted Account
explorer isn't working, that's why I'm asking those questions
03:13
Deleted Account
So, the current capitalization is around 1.35 million?
03:13
Zack
something like that
Deleted invited Deleted Account
03:14
Zack
that was our old explorer
03:15
Deleted Account
okay, gotcha
03:18
Thank you for your time, I'm out of this group until I decide wether or not will I buy
03:32
Crypt Dweller
So the "pivot" right now to built a stablecoin on Amoveo? Definitely makes sense.
03:33
^i'm not saying that with sarcasm, btw
03:33
Exposure to synthetic USD is number one usecase of blockchains rn
03:34
And if we're going thru the big debt cycle reset, this use case will remain preeminent for the foreseeable future
03:35
Keep coding Zack! Keep learning and asking questions Josh! Keep being super cool Mr. Flintstone!
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
23:11
Zack
How about, when a channel expires, instead of immediately paying out the source currency to the owners, instead it creates a new shareable contract, and each of the owners are holding subcurrency in it.
This way, if your channel partner isn't responsive, you only need to pay to put the hash of the contract on chain, not the entire contract. And then you can sell you stake in the contract.
Even if the contract has references to unexpired oracles in it.
23:11
It could get rid of duplicate code
23:12
And it reduces the damage of spam attacks.
23:12
It allows individual contracts to benefit from both shareable and mutable formats.
18:04
Zack
one of the features we discussed in regard to shareable currency, is we would like a tx type that can atomically allow a pair of people to buy opposite sides of a contract, or sell opposite sides.
Also a tx type to atomically swap different kinds of currency on-chain.
The current channels in Amoveo have a feature where you can post an open offer, and anyone can accept the other side of the new channel tx to participate in the opposite side of the contract from you.
So a feature I am considering is that we should allow open offers for making txs to buy/sell/swap subcurrencies.
I am imagining a process like this. If you start with VEO, and want to buy stable USD.
First you do an on-chain swap to change from VEO into a subcurrency that acts as an open order to purchase stablecoins. Because the batch price isn't yet known, the exchange rate between the limit-order subcurrency and VEO is stable, this prevents front running and allows us to do it on-chain.
When a batch occurs, if it is inside the limit price of the shareable contract, then the 2 kinds of shares of this contract become long-veo and stablecoins.
If the batch price is outside the limit price, then the 2 kinds of shares become regular veo. It works like a refund.
If you end up holding stablecoins after the batch, you can use a on-chain swap tx to convert these stablecoins into stablecoins defined by a more standard contract, without risk of front running. because the relative price between the stablecoins defined by the 2 contracts, it is the same.
18:36
Zack
going back to the mutable -> shareable transition idea, another benefit of this strategy is that if multiple channels are all using the same contract internally, that contract will only ever need to go on-chain once, because the channels are all going to reference the same shareable contract.
18:40
so I guess ill write the shareable contract txs first. then build the mutable contracts, and have them become shareable contracts at resolution.
We will allow mutable contracts to be priced in veo.
Then after everything is updated to use the new kinds of contracts, we can turn off the old version of channels so we don't need to maintain them.
18:55
Zack
If you have a mutable contract, and they aren't cooperating, you just put a hash of the last smart contract on-chain, and it becomes shareable, so you can sell you stake as subcurrency, or make channels out of it with other people.
If you and someone else want to do something faster or at higher bandwidth than the blockchain offers, you can make a mutable contract out of any subcurrency in the system.
So smart contracts can switch types over time, depending on the needs of the users.
18:58
shareable contracts don't ever need to be resolved on-chain.
If one person buys up all the subcurrencies, they can combine it into the source currency.
19:11
It would be really cool, if instead of fully resolving one of the shareable contracts, if there was a way of showing that it can be partially-resolved to become equivalent to another existing shareable contract, and then the 2 shareable contracts combine, so the subcurrencies in each are fungible, and when spent, they automatically convert to the simpler type.
Which allows us to smoothly prune obsolete parts of the code from shareable contracts, and reduces the amount of data you need to provide to prove the value of your partially resolved sub-sub-currency.
This would help us avoid running the same computation more than once. and it would reduce on-chain traffic, because participants in sub-sub-currencies wont need to use a market to swap to the sub-currency, it will be automatic.
It also provides a natural way to break up complicated computation into steps in multiple blocks.
19:18
for example, if we have a long-veo/usd-stablecoin market, then there will be different prices people are making limit orders at.
$18.92 per veo
$19.00
$19.05
etc
The full software to enforce the correct usd-stablecoin price is very complicated, it involves reading 10 bits from 10 different oracles. Putting this on-chain is expensive. ideally we would only put it on-chain once.
But the logic to say "my limit price is 18.92" or "my limit price is 19.05", this is very simple. putting this on-chain is cheap. it is like 10 bytes of data. you could pay the miner in a channel, so you don't even need to pay to store your signature on-chain.
19:33
you could make a channel out of veo that references dozens of different sub-currencies, and so could resolve into any of them.
19:37
so channel resolution will be about finding the smart-contract-hash that all participants have signed, and it has the highest nonce.
This creates the shareable contract defined by that smart-contract-hash.
Then shareable contract resolution will involve putting some code on-chain that either converts it into a different type of shareable contract, or causes it to get stuck in a completed state, which allows us to withdraw our veo from the contract.
20:27
Zack
I think if we write a quine in the shareable contract, it would give the contract persistent shared mutable state, at the cost of an on-chain tx per mutation.
20:33
this actually makes the txs simpler. it reduces repetition.
Whyarewehere invited Whyarewehere
Deleted invited Deleted Account
Crypto Twin invited Crypto Twin
Deleted invited Deleted Account
00:26
Topab
Great progress on DEX
00:26
Topab
alex crow 03.06.2020 20:49:15
Deleted invited Deleted Account
04:14
Emänüél 🇧🇷
Where I find Amoveo wallet app?
Deleted invited Deleted Account
Deleted invited Deleted Account
09:59
NM$L
How's veo going？
Judd Keppel invited Judd Keppel
16:23
Callum Wright
if VEO becomes more liquid and less spread then would work yes?
19:09
Zack
It works now.
But yes, it would work better in thst case.
20:13
Zack
so, im thinking about these new tx types we want to make for the subcurrency plan.
we want people to be able to swap different kinds of subcurrency.
We want people to be able to atomically buy/sell different kinds of subcurrency.
We want people to be able to post offers for swaps/buys/sells, so anyone can match their offer.
So lets say Alice wants to exchange her VEO for some stablecoin.
It doesn't really matter to Alice if we use a swap tx to accomplish this, or if we buy some new subcurrencies from the smart contract and give her some.
So it seems like the trade offer that Alice makes, it needs to work for both kinds of txs.
20:14
if we buy new currency from a smart contract, it might have more than 2 flavors.
If there are 4 flavors, and 4 different people make open orders that are all compatible together.
I guess it should be possible to collect the 4 open orders together and make a tx for them to buy the subcurrency that they want?
20:16
the smart contracts are turing complete, and we do expect people to use them because off-chain markets can prevent front running.
So we want the on-chain tools for exchanging subcurrencies to be pretty simple.
20:20
============
A compromise:
im thinking for buying new subcurrency, im going to limit it to 2 accounts dividing up the kinds of subcurrency that can be produced from this contract.
And for swapping, im going to limit it to 2 accounts and 2 kinds of subcurrency being swapped.
And I will only allow open trade offers for swaps, not for buying/selling to a contract.
00:58
K
Are there any downsides to using state channels as opposed to on chain smart contracts?
00:59
Zack
State channels, or as we are calling them now, mutable contracts, have the downside that the only people who can participate are those who initially signed up.
And that any update of the state requires everyone's permission.
Deleted invited Deleted Account
Parezar 87 invited Parezar 87
Deleted invited Deleted Account
13:16
Jon Snow
It’s Schrodinger's VEO.
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
02:43
K
Do you have an opinion on Celer's state channel design?
He.pen sorn CHRC member invited He.pen sorn CHRC member
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
ramaraju vanam invited ramaraju vanam
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
05:18
Zack
hello new members. say something or get kicked.
Eric Chen invited Eric Chen
05:55
Eric Chen
Something
02:00
Zack
say something Narhet.
02:05
Instinct
Proof of life
Vishal Prajapati invited Vishal Prajapati
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
10:50
Mr Flintstone
maybe we could get a join captcha bot like in the loopring telegram
10:50
so that when you join you have a few mins to fill out the captcha or you get autokicked
14:22
Minieep21
Good idea
20:46
whats the main use of amoveo admin?
20:47
Zack
admins are for moderating the discussion and deleting spam.
20:47
Amoveo is for financial derivatives contracts.
00:07
mr x
Blocked by bitcoin maxi Pierre Rochard for suggesting that the number that should go up is hashrate not coinvalue :(
00:19
coins of a chain should only be hodled to the extent you want to have the option to participate in onchain hash rate futarchy
00:37
mr x
more tokens locked up in on going futarchies the more plutarhic the system becomes
00:48
Zack
Maybe you are living ahead of your time Mr X, and the world isn't ready for your message.
16:42
Please help bump by posting some cool responses
18:39
K
Have you heard back from the people who made
amoveo.io? Are they still supporting VEO?
00:18
Mahnoor
Hi there,
I'm Mahnoor from Xperts Studio, one of the leading crypto related Youtube Channel with 36k plus subscribers.
Are you looking for Marketing of your project? We can help with it via making videos of your project.
Please tell with whom I can talk to?
00:30
leigh
Hi thanks for getting back to me I sent 1 veo on your exchange bot 12 hours ago but received no btc can u help with this?
00:43
Denis Voskvitsov
we've got in touch already, payment is on the way
00:43
Zack
Awesome. Thanks Denis :)
02:36
leigh
Thanks guys all sorted.
Deleted invited Deleted Account
Inge Borg invited Inge Borg
18:07
Tudor
What's the most exciting thing happening in Amoveo now?
18:48
Tudor
Thank you, will go through it. Wishing you all the best!
21:00
Bo Smubo
How much does 1 veo now?
23:41
K
Amoveo should market it's oracle more, so many oracle coins exploding
Ammar Hakimi invited Ammar Hakimi
Deleted invited Deleted Account
01:59
Živojin Mirić
Hello frens
02:31
K
Hello please do ur duty and reply to every link thread about the amoveo oracle
02:31
Živojin Mirić
Wat is?
02:41
Zack
Which one did I miss? Sequoia?
It seems to be on tendermint. I wrote about PoS.
And there is nothing I the article about who oracle design they will use.
02:44
K
Na this is just to try spread the amoveo word
02:44
Zack
Oh. Chainlink.
They would just block me anyway
02:59
Deleted Account
Nest protocol seems like a promising oracle implementation. Quite hyped in China
03:05
Živojin Mirić
Veri gud
Deleted invited Deleted Account
Cire MXIV invited Cire MXIV
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
01:45
Mr Flintstone
im not sure finality with validium is any different than the on chain checkpoints
01:45
its just like dpos off chain to decide what happens in between commits or something?
Jelena Mich invited Jelena Mich
Deleted invited Deleted Account
Deleted invited Deleted Account
Jâçk Mâhîî 💫 invited Jâçk Mâhîî 💫
A7m3dov CC invited A7m3dov CC
Deleted invited Deleted Account
Deleted invited Deleted Account
08:31
Deleted Account
Hi 👋
10:43
Callum Wright
Is the Rosetta API announced by Coinbase useful to integrate Amoveo to exchanges and wallet?
Zack
10:47
Zack
the github page is a test to see if you are compliant with a bunch of standards that coinbase came up with.
I think this is a way for coinbase to more cheaply integrate bitcoin clones onto their exchange. I think it is only useful for coinbase and bitcoin-clone projects being listed on coinbase.
Deleted invited Deleted Account
05:20
Crypt Dweller
Hi Zack, I am wishing you well. Amoveo only grows more important as our social and economic problems escalate. You have immense potential inside you to effect good in this world, your hardwork and soulful feeling are needed now more than ever.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
16:15
mr x
hashrate futarchy solves the reverse oracle (agency?) problem
16:15
how to take action in real world
16:15
or more boringly public good problem
16:17
good is public with respect to blockchain if printing money for it will lead to an increase in hash rate?
16:18
fees should not be burned
16:19
they should be sent to a treasury account which is controlled by hashrate futarchy
16:20
mining is a public good for a blockchain also
16:20
blockchains need a brain
16:20
current chains are retarded plants
20:31
Zack
Be careful of a fake Zack direct messaging people.
20:43
I set my unique username to
@zack_amoveo.
So now you can know if it is the real me, or if someone is pretending
Deleted invited Deleted Account
23:53
Mr Flintstone
was bch btc split hashrate futarchy?
00:25
mr x
Hmm no? I think hashrate futarchy as the way blockchain takes action. It is cool because everything can happen totally onchain and hashrate is ungameable measure of network size... What actions blockchain can take then? Well adjusting parameters like blockreward, burnfees, blocksize but also printing money for some address... :P
00:33
I'm basically imagining a network that pretty much only talks about its own hashrate xD
00:45
what happens onchain should be about the chain...
00:51
it can reward people for doing good things for the network after the fact...
01:45
mr x
p1 = totalwork will be greater than some value at some future date if network does x. p2 = same but not do x
02:40
Zack
This project is called "amoveo". The currency is called "veo"
02:43
Zack
Sy did the Explorer, and the mining pool, helped design the checksum system to prevent counterfeiting, and he designed the optional system in the full node to collect meta data about the blocks.
Mr flintstone helps more with the design of markets and derivatives contracts and futarchy.
Deleted invited Deleted Account
Deleted invited Deleted Account
05:10
Zack
In the subcurrency branch on github, we now have tx types for creating shareable smart contracts, and for an individual to buy shares in a shareable smart contract.
05:10
next up will be for spending subcurrency.
Deleted invited Deleted Account
06:45
Zack
I made the tx for spending subcurrency, with a passing test.
06:46
I guess next will be a tx for combining the different flavors of subcurrency back into the source currency for that contract.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
02:40
Zack
there is a price talk channel in discord
07:58
Zack
I added the ability to combine different flavors to get back the source currency
07:59
I guess next will be some txs for resolving a shareable contract.
19:42
Zack
One feature I am adding to shareable contracts. It is kind of hard to explain.
First a more practical example:
Lets say there are several contracts for USD stablecoins: USD_A, USD_B...
we have multiple because they resolve at different expiration dates.
Alice and Bob want to have a contract ContractAB, and if it doesn't work, they want to be refunded.
Alice wants to be refunded the USD equivalent of what she had put in, and she wants it in the USD_* contract that will expire as soon as possible.
if ContractAB gets cancelled, Alice's tokens in ContractAB all get converted to USD_* tokens, which are totally fungible with all the other USD_* tokens, because their outcome is deteremined by the same USD_* on-chain contract.
Now a more computer science description.
Our contracts are very lazily executed. This allows us to avoid redundancy, because contracts that share code, they can wait and just run that code once for everyone.
This also allows us to spread out a very long contract into multiple blocks. So your contract's size isn't limited by the availability of space in a single block.
Now a more finance description.
We can have contracts where the result of one contract is a reference to another, possibly still active contract.
20:55
Zack
I made the txs for resolving a shareabe contract.
I guess next will be for withdrawing your winnings from a shareable contract that has been resolved.
or maybe a test that it works to have a contract priced in a subcurrency.
21:09
K
Veos got a really small community I guess lol
22:00
Mr Flintstone
excited to play around with these subcurrencies when they are ready. i bet we can beat the yield from farming on ethereum :)
23:08
Zack
Mr flintstone had that idea about allowing pairs of people to create a tx together. They each own opposite sides of the contract, and they want to combine them to get Veo.
There is front running risk for doing this on chain. I've been thinking of more efficient ways to do it.
I'm thinking what we really want is to atomically create different kinds of channels simultaneously.
Like, if I have C-coin, and I want B-coin, I could find someone who owns B-coin and we could simultaneously make both channels at once.
We can write and sign the smart contracts before the channels are created. So as long as both channels are created atomically, then both contracts activate atomically.
So the process is like
* atomically create both channels.
* atomically swap part of the value in the channels
* now we each have the proper mix to combine our assets into Veo.
Deleted invited Deleted Account
12:25
Callum Wright
I like this. what's the use cases of this that you can think of?
12:58
Zack
idk, maybe just swapping is better.
12:58
anyway, I wrote the tx type for withdrawing your winnings from a closed shareable contract.
13:00
I guess next will be tests to be sure that we can build shareable contracts priced in subcurrencies from other shareable contracts.
13:01
or maybe code for allowing a shareable contract to resolve into a different shareable contract. for partial execution.
Deleted invited Deleted Account
01:03
Zack
Amoveo channels aren't vulnerable to this.
When you settle an amoveo channel, you provide evidence, and the contract outputs a nonce.
Whatever evidence produced the highest nonce, that is how the channel ends.
It doesn't matter if your partner is willing to pay a higher fee.
02:37
Zack
Here is a kind of interesting math problem.
Let's say there is a contract with N flavors of subcurrency, and we want it to resolve into a different contract with M flavors.
How do we represent the rule for converting the N subcurrencies into the M subcurrencies?
I guess it is some kind of NxM matrix.
Is there some way to look at this matrix and quickly verify that the total number of Veo is conserved after the transformation?
I think the component vectors of the matrix need to sum to [1,1,1,...,1].
I wonder what is the most efficient way to Merkelize this matrix so we can keep the txs small, and keep the data off-chain?
02:48
I guess since each contract-winnings-tx only does one flavor of subcurrency, that means we should optimize the merkle tree to prove one row of the matrix at a time.
09:46
x
“Ethereum 1.0 is a couple of people’s scrappy attempt to build the world computer; Ethereum 2.0 will actually be the world computer.” theoretically is that possible? there isn't working solution for scaling even bitcoin
09:47
Zack
I think good trustless finance at scale is more important than a generalized computer.
09:53
x
i also think so, Difi is a hot word now
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
15:38
x
@zack_amoveo can you invite me to the design group you created?
20:00
Zack
I don't know what group you mean
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
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
11:45
Zack
The stuff about the Oracle at the end is very pro-amoveo
11:46
Topab
Yes, I think all ends up in Amoveo
11:46
Only observation is, is taking too long
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
21:38
Zack
Nice. Let me catch up on what was already discussed.
22:19
Mr Flintstone
would be tight if twitter let you do matrices in tweets
22:19
probably a picture suffices
22:20
Zack
Yeah; a pic is probably a better strategy
22:29
Ava shills just don't care if it is secure or not.
It seems like finance systems are mostly built by survival of the fittest evolutionary processes.
Not by logic or reasoning.
22:45
K
Why can't VEO have the level of marketing as Avalanche?
22:48
Zack
Amoveo tokens are called "Veo"
22:49
It just takes me to a login page.
22:50
K
Basically you get rewarded AVA for retweeting tweets, tweeting about AVA, writing things about AVA, making videos etc
22:57
Most of it apart from tweets are monitored by real people so spamming does nothing. You get rewarded more if you reach more people
22:57
Zack
Sounds like ava is a good advertising company.
Too bad they are trying to compete in the cryptocurrency industry.
22:59
Instinct
For one they just raised $12m in private sale & will get more in ico
23:04
K
Why can we use futarchy to create some VEO to auction off in an ICO. AVA is only using like 15% of their total supply for an ICO
23:14
sanket
what's the reason for this?
23:31
Mr Flintstone
need something to market
23:31
probably will have that with trust free and transferable usd on chain soon tho
23:51
sanket
stablecoin or transferable usd is a good thing
23:52
K
Ah true. Isn't the betting market live though? Exan tech build a user friendly wallet for it too
00:13
Zack
We only support p2p betting currently
00:26
Mr Flintstone
i think the new subcurrency stuff should fit into the existing p2p betting tools? so i could make a p2p bet offer denominated in synthetic usd easily?
00:29
Zack
I will need to make some minor updates to the javascript, since the new channels are formatted differently to be able to have more than 2 participants.
But it should be able to work the same way.
00:32
once we have that, the last piece of the puzzle is a tight bid-ask in the veo spot book since it’s being used as the settlement price for the stablecoin
00:32
any spread is like an added cost
00:34
given how small the coin has gotten would only take a few hundred usd to get there. and i think someone (maybe bis dev?) has released a qtrade market making script
00:35
so in a few weeks or whenever this update is ready, i think either i will try to set it up myself or if someone has competency in market making maybe they could help me / correct how much $ they think it would take to get a tight bid ask
Crypto Movement invited Crypto Movement
05:08
Zack
I added a feature to the shareable contracts.
Now you can have a shareable contract priced in a subcurrency.
05:08
I guess next will be a shareable contracts that only partially resolves, if you hold subcurrency from from the resolved contract, you get paid with zero or more subcurrencies from a different contract according to a payout matrix.
05:10
after that I will shift to focusing on the mutable contracts.
05:10
oh right. I will make a tx for swapping subcurrencies, and it will work like our current channel_accept tx does.
So one person can publish an open offer for a swap, and anyone can accept.
Deleted invited Deleted Account
Deleted invited Deleted Account
08:08
Josh
This sounds like a good goal to shoot for. Might be worth prioritizing dev tasks to hit it.
Deleted invited Deleted Account
09:51
Mr Flintstone
im also happy to just give someone the capital to do it
09:52
if u have the skills and want to help out veo, just need to get the snowball to start rolling down the hill
09:53
but lets get the subcurrency update live and then test the life cycle of the various functions first
Deleted invited Deleted Account
Deleted invited Deleted Account
21:13
Zack
Having shareable contracts result in other shareable contracts gives us some cool tricks.
For example, we could make something like the DAO in ethereum.
A shareable contract could have a list of pubkeys inside of it, and it is only able to resolve if some fraction of the people in the list of pubkeys sign over the update.
And when it resolves, it creates a different shareable contract with a different list of pubkeys inside of it.
The shareable contract could contain the merkle root of a tree of account balances, to embed a subcurrency inside of it.
A shareable contract could work as a name registration system. It could be set up so anyone can register a connection between a unique name and a pubkey. It could possibly require you to burn some veo or subcurrency to register your name.
If shareable contracts can resolve into other shareable contracts, it acts like persistent on-chain state, which can be very slowly updated. It gives us almost all the capabilities of Ethereum, but with a very different model of smart contracts.
Since Amoveo smart contracts have an ID based on the code, a reference to a smart contract always does exactly what you expect, preventing a lot of bugs.
In Ethereum the contracts call each other like functions, which creates many subtle bugs, like reentry bugs.
In Amoveo the contracts only resolve into each other, so these kinds of bugs are impossible.
With ethereum smart contracts, the entire bytecode of the contract is on-chain and it can get mutated.
In Amoveo only the root hash of the merkelized abstract syntax tree is on-chain, and each contract is immutable. The contract code is off-chain. To change something you need to make a new contract, and have the first contract resolve into subcurrency of the second contract.
21:14
Storing mutable contract state on-chain makes ethereum complicated.
With our smart contract design, only a single root hash is stored per shareable contract. This keeps it simple.
21:23
One feature I am wondering about.
What if we want a smart contract that pays out in a mixture of stable-USD and stable-Euro.
So when the first contract resolves, it would give you subcurrency in the stable-USD contract, and it would also give you subcurrency in the stable-euro contract.
Is this a feature we want?
Or is it acceptable that each contract can only resolve into 1 other contract?
21:25
for now I will only allow it to resolve into 1 contract, we can update it to support more later, if people want that.
21:32
sanket
I guess only 1 stable- USD contract makes sense.
21:33
Zack
we need different stable-usd contracts that have different expiration dates.
21:53
sanket
can't we have a perpetual contract?
21:55
Zack
Financial derivatives are the optimal way to format stablecoin contracts.
22:44
Mr Flintstone
i think usd only is probably fine
22:46
i cant think of any derivatives where you receive multiple currencies at the end
22:46
Zack
We can reference multiple oracles in a single contract.
23:16
sanket
Isn't perpetual swaps a derivative? minus the expiration
23:29
Zack
No.
This is the first I have heard of perpetual swaps.
A perpetual swap cannot be secure. The only secure way to trade a derivative contract is with a secure market.
Being able to exercise a contract early is not a secure alternative to selling the contract in a market, because there is no secure way to exercise at the correct price.
The act of selling your contract is a trade in the market and should have influence on the market price. You need to participate in a market for this to work.
Financial derivatives have been actively researched since prehistory. They are a fundamental part of what it means to be human.
It is embarrassing how people in cryptocurrency feel like they can throw away tens of thousands of years of human progress.
00:30
Mr Flintstone
i think its probably more important to look at why would you want a perpetual swap. you would want a something like a perpetual swap so you can hold some synthetic usd in your veo wallet and not worry about it expiring and taking on the veo price risk
00:33
i think that we can overcome this limitation with some financial engineering
00:40
since i think we can know what all the monthly forward stablecoin contracts will look like, i think we can publish trade offers between them that become valid after a certain block height. so i can trade my usd expiring at the end of july for some that expires at the end of august, without me needing to be online at the end of july
00:51
i also wouldnt think coming online once a month to roll your contracts is a huge burden
02:26
sanket
this sounds great
Darragh Brady invited Darragh Brady
02:42
Darragh Brady
Hi all. Wondering is there’s an issue with transfer amoveo
02:43
Zack
If you are having issues transferring, we are here to help.
Can you provide more information?
02:43
Why do you think it isn't working?
02:44
Darragh Brady
Sent from qtrade to amoveo mobile wallet
02:44
Did a test transfer with small amount and went fine.
02:45
Zack
Which mobile wallet?
02:46
Darragh Brady
iPhone