1 July 2020
DB
02:46
Darragh Brady
iOS
Z
02:47
Zack
CD
02:47
Crypt Dweller
"Bitcoin runs into its scaling limit. If scaling not fixed, Bitcoin will crash. If the Lightning Network fixes scaling, Bitcoin will rise a lot further, and all other crypto currencies fade. If the Lightning Network fails, a crypto currency that can scale will replace Bitcoin."
Z
02:47
Zack
In reply to this message
this is the one that I maintain
02:48
In reply to this message
lightning network isn't for scaling. it is for contracts that can mutate more rapidly.
DB
02:48
Darragh Brady
In reply to this message
The one for iPhone that can be downloaded from the amoveo site
Z
02:48
Zack
https://github.com/zack-bitcoin/amoveo this is the amoveo website that I maintain.
02:48
what is your address?
DB
02:48
Darragh Brady
In reply to this message
Mine?
Z
02:49
Zack
right.
02:49
your amoveo address.
DB
02:49
Darragh Brady
BNitWy0VKzw3edyaqKL3ejBXShHqAQnA/Xc2+e8WVtw0kWaLMHsof8iavDpLxosOypA3xfCGxWlpDFKJw9TWoh8=
CD
02:49
Crypt Dweller
You would know better than me, but the layperson's idea of Lightning is that it's a workaround to Bitcoin's small block size limit
Z
02:49
Zack
In reply to this message
it is a workaround for slow finality. you have to wait so many confirmations.
DB
02:50
Darragh Brady
In reply to this message
Only the first transaction went through though (and it’s the smaller test one)
Z
02:50
Zack
it says you have 0.06 veo
02:50
is that the first one?
DB
02:50
Darragh Brady
Yes
Z
02:51
Zack
there aren't any txs in the mempool. so waiting longer wont change anything.
02:51
do you have the txid from the tx you tried to make?
02:51
how long ago did you attempt to make it?
DB
02:52
Darragh Brady
In reply to this message
Less than a couple of hours ago
02:52
Sent you a screenshot of my qtrade withdrawals for amoveo privately
02:53
In reply to this message
Almost 3 hours ago, rather.
Z
02:54
Zack
I think you should contact qtrade.
They have a channel on our discord for problems like this.
02:54
in the #qtrade-exchange channel
DB
03:00
Darragh Brady
Thanks for your help!
Deleted invited Deleted Account
C
09:37
Callum Wright
In reply to this message
this is cool to eventually build an "index" on Amoveo
09:38
but step by step first I guess
MF
09:43
Mr Flintstone
the same process you use to create veo-backed usd, you can do the same for an arbitrary index
09:44
then send it around, trade it etc
Deleted invited Deleted Account
Deleted invited Deleted Account
J
16:23
Jeans
Hi, do you think it’s possible that the haven protocol project will one day use the oracle Amoveo, instead of chainlink oracle?
Z
18:59
Zack
In reply to this message
Anyone can use Amoveo's oracle.
The amoveo light node is small and easy to embed in other protocols.
It is possible.

Keep in mind that an oracle is only one ingredient to make a stable asset.
Even if haven protocol had a secure oracle, their product is still not secure.
J
19:59
Jeans
Thanks Zack! You have certainly several moves ahead and I would like to suppose that haven is not currently the most secure. That said, it could be interesting to encourage projects like Haven to use the Amoveo oracle, even if the rest of the project is not completely secure. This would make the whole project more secure, and probably less expensive. And that can allow Amoveo to prove itself. I submit this idea to the Haven team on their discord channel, we’ll see.. Have a nice day!
Z
22:33
Zack
https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/resolve_contract_tx.erl#L51
I wrote this code to handle contract resolution where the result of a contract is another contract.
2 July 2020
Z
01:10
Zack
Here is an interesting math question.
Lets say we have contracts A, B, and C.
Contract A resolved into contract B according to matrix ab.
Contract B resolved into contract C according to matrix bc.

given ab and bc, how do we calculate ac, where ac is a matrix that brings us directly from contract A to contract C.
01:11
A solution to this can potentially let us prune stuff.
Like, if you hold some subcurrency in contract A, ideally you would only need one merkle proof for ac, rather than needing 2 merkle proofs, one for ab and one for bc.
01:18
The identity and inverse matrices seem to be the same as in normal matrix multiplication.
T
01:51
Topab
Can you do options in Amoveo? This article name some options platforms in Ethereum. Perhaps interesting to read https://medium.com/coinmonks/a-comparison-of-decentralized-options-platforms-140b1421c71c
MF
01:54
Mr Flintstone
yeah binary options
01:56
they have been live for a while but the ux is rough
Z
02:18
Zack
We have scalar derivatives too.

Options are popular for centralized tools. Because options are the kind of derivative where only one of the participants needs to be trusted.
So with options there can be one single trusted node that everyone connects with to trade, and that central hub doesn't need to trust any of the customers.
This makes enforcement cheaper, because only that one central node can possibly cheat.

With trustless tech, it is usually better to use forward contracts instead of options, because forwards contracts are the kind of derivative that is symmetric. This makes it simpler for the kinds of p2p stuff we want in a decentralized network.
s
02:35
sanket
In reply to this message
I guess amoveo has a lot of features but not a good ui/ux for someone to use it. Or is there?
T
02:42
Topab
Thanks for the explanation
Z
02:46
Zack
In reply to this message
The light node is ok.
You can ask questions here if anything is confusing.
02:49
In reply to this message
the more I look at this, the more I think it is normal matrix multiplication.
RAPOSTLE Sam invited RAPOSTLE Sam
B
13:28
Ben
Amoveo has no usable UX at all, i mean for the average joe. I guess as soon as Zack is comfortable with the base Technology the next step would be to get a UI/UX that average Joe can use.
Chris B invited Chris B
Z
19:04
Zack
In reply to this message
The light node works ok. It is beautiful, but most people seem able to use it, especially if they can ask questions here.
B
19:12
Ben
that is your perception, i spoke to a some people and no one like your light node.
19:13
for a POC totally ok
19:13
but for Production, this is not sufficent
Z
19:13
Zack
Were any of them able to offer constructive criticism?
What do they want to see changed in the light node?
s
19:18
sanket
if I may, he means from a UI PoV it's very basic.
Compare it to other things like Veil or Flux or Augur V2. it's not easy to understand and navigate
19:18
Deleted Account
Kinda sad that while literally dozens of defi projects are flying in terms of volume and engagement, Amoveo is nowhere to be seen. With all these well organized teams gaining ground and recognition, it's going to be increasingly harder for a one man team to grab a piece of the pie.
s
19:19
sanket
correct me if that's not what you meant
19:19
I should able to
1. Deposit veo
2. Create or trade a contract with ease, or no help
3. withdraw veo.

it should be this simple.
Z
19:21
Zack
In reply to this message
what does "deposit veo" mean? what does "withdraw veo" mean?

Creating a contract is a simple one step process in the light node.
making a trade is 2 steps: 1) fill out the form. 2) publish your trade somewhere public.
19:22
In reply to this message
is there something specific you would like changed?
"not easy to navigate" isn't helpful for me to know what to change.
s
19:22
sanket
In reply to this message
I was assuming that you need to deposit veo first to trade.
My bad.
Z
19:22
Zack
what does "deposit veo" even mean though?
s
19:23
sanket
In reply to this message
I tried a while back. Let me try it out again today.
Z
19:23
Zack
like, deposit where/
s
19:23
sanket
In reply to this message
generally the other platforms I mentioned require you to first deposit "tokens" for trade.
19:23
Anyways, chuck it.
Z
19:23
Zack
usually "deposit" means when you send your coins to an exchange
19:24
amoveo is trustless. you don't give your coins to any server.
s
19:25
sanket
yeah. I know. that's why I said my bad in terms of confusing other platforms with veo
Z
19:28
Zack
If I have 2 matrices where the columns sum to 1, and I do matrix multiplication, the result is always another matrix where the columns sum to 1, right?
19:32
https://en.wikipedia.org/wiki/Stochastic_matrix
I think these matrices we use for resolving contracts into other contracts, if they are square then they are stochastic matrix.
19:33
left-stochastic. since the columns sum to 1.
J
19:49
Josh
@zack_amoveo Do you know about the statebox channel? They have a lot of mathematicians, especially category theory, and they're interested in blockchain stuff.
Z
19:50
Zack
I don't know about statebox
J
Z
19:54
Zack
so, they use category theory to try and write smart contracts without bugs? it doesn't seem related to amoveo.
J
19:57
Josh
or program in general with less bugs. but their telegram channel could be useful for asking math questions.
Z
20:03
Zack
formal methods are nice for making and verifying large mathematical proofs that are too big for humans to read. Like when they did they proved the 4-color theorem.

I am not a fan of using formal methods for writing safety-critical software.
Formal methods can be used to prove that 2 different pieces of software are equivalent, but there could still be a bug hidden in both sides.

I think these tools are popular with mathematicians who haven't actually written much software.

When I worked at NASA, they had a whole protocol for writing mission critical software. There were lots of rules about how to write code so that it is easy to verify that there are no bugs, and it does what you expect.
They don't use formal verification.

Personally, my favourite tools for safety critical software are classic CS strategies.
Make every function as pure as it can be.
Reduce the number of possible states of the system as much as possible.
keep the namespace small.
For every loop, make a proof to show that it will exit in a reasonable amount of time.
20:06
I like the erlang strategies too.
Separating resources into small independent threads that do not share mutable state.
Fail-fast, let it crash.
J
20:06
Josh
a lot of category theory is about composing small state machines into bigger state machines
20:07
with different kinds of petri nets you can prove stuff about liveness, boundedness, etc
20:07
and petri nets can be modeled in category theory
Z
20:08
Zack
"category theory" is incredibly broad.
looks like statebox is about formal verification.
J
20:08
Josh
they started off with category theory, they seem to be branching off into formal verification and type theory
Z
20:09
Zack
In reply to this message
I don't see any telegram channel of theirs.
there is a way to contact an individual from their team on telegram.
J
20:09
Josh
"If I have 2 matrices where the columns sum to 1, and I do matrix multiplication, the result is always another matrix where the columns sum to 1, right?" I'm not sure why this would be true.
20:09
do you mean the rows of the first matrix and the columns of the 2nd matrix sum to 1?
Z
20:10
Zack
In reply to this message
these kinds of matrices form a closed group under matrix multiplication. they are stochiastic matrices.
20:10
In reply to this message
no. the columns of both sum to 1.
they are left-stochastic.
20:12
you can think of one of these matrices as a function that takes a probability vector to another probability vector.

So for example, 3 independent events. [0.5, 0.2, 0.3]
there is 50% odds of first, 20% of second, 30% of third.

a matrix could take this vector, and output some other probability vector like [0.1, 0.1, 0.8]

Each probability vector, the probabilities need to sum to 1, because the different possible outcomes are independent.
20:13
the way to make sure that the input and output probability vectors both sum to 1 is if the matrix that transforms them, it needs columns that each sum to 1.
20:14
If one matrix preserves the property that the probability vector sums to 1, then using 2 of these matrices one after the other should also result in a probability vector that sums to 1.
20:14
so, if we multiply the 2 matrices together, we must result in another matrix with the same property. that it preserves the fact that the probability vector sums to 1.
20:15
so matrix multiplication between pairs of stochastic matrices must result in another stochastic matrix.
J
20:16
Josh
what if the first row of the first matrix is all 0s?
Z
20:16
Zack
but in the case of Amoveo, we aren't doing probability vectors. Instead the vector is for who has how much VEO. We want to conserve the total quantity of veo.
20:16
In reply to this message
it can still be left-stochastic.
left-stochastic means the columns sum to 1.
20:18
This is pretty basic linear algebra, not very difficult or exciting.
but it is cool to see it appear in the wild.
J
20:19
Josh
it's been a while since i did this stuff, not immediately clear to me why it preserves that but i'd have to work through it
Z
20:20
Zack
since we are using left-stochastic matrix, the probability vector needs to be a column vector, not a row vector.
20:22
left-stochastic is preferable for us because we want to build a merkel tree based on the rows.
When you convert subcurrency from the resolved contract into subcurrencies in the new contract, you only need to use one row of the matrix.
So we want it to be convenient to build proofs based on the rows.
J
20:23
Josh
sounds like a cool application of these stochastic matrixes
Z
20:29
Zack
normally, if you have some subcurrency in contract A, and contract A resolved to B, and contract B resolved to C, and contract C resolved to veo so you can withdraw, it could take a lot of txs to withdraw your veo.

first you need to convert your subcurrency in A into one or more subcurrencies in B. (one Tx)
For each subcurrency you have in B, you convert it into one or more subcurrencies in C. (as many txs as there are subcurrencies in B)
For each subcurrency in C, you withdraw to veo. (as many txs as there are subcurrencies in C).

But if we do matrix multiplication, we can create a direct path from contract A to contract C.

so the process is shorter:
first you convert subcurrency A into one or more subcurrencies in C (one Tx)
then for each subcurrency you have in C, you withdraw to veo (as many txs as there are subcurrencies in C)

So maybe we should have a tx type to update resolved contract A to point to C instead of pointing to B.
20:30
It is especially useful if A and C have few subcurrency types, and B has many subcurrency types.
or if the path has many more than three steps.
contract A could resolve to B could resolve to C, then D, E, F .... for dozens of steps.
20:34
Keeping the on-chain contracts immutable makes it a lot easier to build amoveo, to achieve scalability, to verify security.
but it means every time we do want to change a contract, we are creating a new contract on-chain, and the old one resolves to the new one.

So we want this process to be efficient.
B
21:12
Ben
in regards to the Usability, take any modern interface and compare it to amoveo, you will notice that amoveo is not easy to understand/navigate and use. If you doubt it, take a non Crypto user from your Family and ask them for feedback about the lightnode, you will see that they have no idea what it is all about.
Z
21:14
Zack
lets try to keep the criticism constructive.
If you have no idea on how to improve something, then complaining about it is not helpful.
B
21:15
Ben
as somone above mentioned, user expect something as frontend like the other oracle Implementations are offering.
Z
21:17
Zack
This is still not constructive.
You need to point to some specific change that you would like to see, and give reasoning for why you think that change would make the interface better.
B
21:19
Ben
could you give me the URL to the latest Version? will give you an example
Z
21:19
Zack
As far as I know, Amoveo is the only blockchain offering P2P derivative bets based on custom question text where you don't need to build the oracle on-chain, unless there is a disagreement about the outcome.
21:20
In reply to this message
so we can't copy anyone else.
No one else has anything like this.
B
21:20
Ben
you don't get the point. it is not about the underlying Technology it is about the presentation Layer to the User.
21:21
i don't question Amoveo is superior in regards to oracle Technology
21:21
thats a given.
Z
21:21
Zack
it is an entirely different service than anyone else offers.
Not just the tech differs.
It is a different product.
21:22
making a bet in an existing on-chain oracle-powered market is very different from a P2P bet on custom private text.
B
21:23
Ben
for example, the wallet part of the light node is pretty common in all blockchains, could you agree on that point?
21:23
if you compare modern wallets/webwallets to the lightnode you will recognize that is far harder for the user to understand what he is doing in your lightnode.
Z
21:24
Zack
Maybe I should take some time and look at other blockchain light nodes. haha
B
21:24
Ben
and since he is dealing with money, it should be cristal clear.
Z
21:24
Zack
In reply to this message
not constructive.
21:24
In reply to this message
not constructive.
B
21:26
Ben
take a look to other projects, maybe you will recognize something.
21:26
maybe also a question what your targeted usergroup is.
Z
21:26
Zack
In reply to this message
yes, that makes sense
B
21:27
Ben
if you only target "Blockchain Nerds" then you are all set.
Z
21:29
Zack
choosing a target demographic before you know the product you are selling is a recipe for failure.
MF
21:30
Mr Flintstone
something constructive: right now, the light node is like handing someone a blank ethereum blockchain and telling them they can do anythjng they want, they just need to build the smart contract themselves. Which is technically challenging. instead, people should be using applications built on top of the light wallet with preset smart contracts coded rather than create the contracts themselves
Z
21:31
Zack
In reply to this message
yes, that makes sense.
We need pages that have more pre-set defaults so there are fewer choices when doing popular things.
MF
21:31
Mr Flintstone
but i think this is the goal for this next update, as we discussed we would want to have USD stablecoins built in, which is like an application. and the user doesnt worry about the tricks underneath the UI that make 1 stablecoin = 1 dollar
B
21:31
Ben
btw. the amoveo wallet is pretty good in shaping your technology into a form that an average user can interact with it. maybe you should team up with the exantech guys.
Z
21:33
Zack
In reply to this message
yes, that seems like the right order.
* subcurrency update
* good stablecoin tools
* simple light node interface to use the stablecoin for contracts.
B
21:36
Ben
👍 agree
3 July 2020
Z
02:36
Zack
One thing we can do is have contracts denominated in subcurrencies from other contracts.

Another thing we can do is to have a contract resolve into another contract.

Are these two things identical, as far as use-cases enabled, or do we need both?
Marcus Kain invited Marcus Kain
Z
02:41
Zack
I think we need (1) to make betting denominated in stablecoins convenient.
Otherwise we would need to bundle the bet denominated in stablecoins along with someone buying long-veo all in the same moment.
02:53
The advantage of (2) is that we can get rid of repetition in smart contract execution.
If 2 smart contracts share some code, that can be extracted into a 3rd smart contract that they both reference.

And we can have persistent contracts with permissions about who can make a new version. Which could be useful for domain name registries, or other non-finance use cases of blockchain.

And the smart contract can be updated in ways that had not been anticipated when it was first written.

And we can split up contract execution into multiple blocks, for very big contracts that don't fit into one tx.

And we can potentially keep more code off-chain.
If all the participants in a contract sell their subcurrency to one person, he can extract all the source currency from that contract, without actually having to execute it.

For example, the first contract might have 4 kinds of shares, but 2 kinds end up worthless, and the last 2 kinds are converted to a new contract.
If everyone with positive value subcurrency sells it to the same person, then the second contract never needs to be executed.
02:54
I think maybe this combination allows for everything you can do with ethereum, but with a couple benefits.
It is a stateless full node.
The contracts are immutable, which makes for an easier development environment with less bugs.
Deleted joined group by link from Group
Z
03:41
Zack
I found a big simplification for these matrices.

Lets say contract A resolves to contract B, and B resolves to veo, and lets say that both A and B have resolved.

When B resolves, there is a vector of how many veo each of the subcurrency types is awarded.

matrix AB converts a vector of ownership of veo in contract A into a vector of ownership of veo in contract B.

So if we calculate the inverse of AB -> (AB)^-1,
We can use this to go backwards.
We can convert the payout vector from contract B into a payout vector for contract A.

So now the users who own value in A, they can withdraw directly to veo without having to deal with contract B at all.
03:46
In reply to this message
if we use either strategy (1) or (2) for the same contract, lets compare how many txs we need on-chain.

A simple example with 2 steps: We start with veo, and we want to make a bet priced in stablecoins.

So with strategy (1), we first make a tx to convert the veo into stablecoins. then we make a tx to buy your side of the bet. a tx to sell your side of the bet, then we make a tx to convert the stablecoins back to veo. 4 txs total.

With strategy (2), you can use one tx to use your veo to participate in a bet where you can get paid stablecoins.
And as long as someone else does the tx that calculates the inverse of AB, you are able to withdraw directly to veo with a single tx. 2 txs total.

So this can reduce the number of txs on-chain, and it can reduce how many merkle proofs we need for our txs.

I think we should allow contracts to resolve to contracts.
03:50
oh, I think it isn't the inverse.
MF
03:51
Mr Flintstone
i put a trade on this website http://159.89.87.58:8090/main.html
03:51
if bitcoin drops to below 8200 at the end of the next 28 hours or so you get 50 veo, if not you lose 3.25 veo
03:52
the trade offer expires in 5 veo block which is about an hour
CD
03:55
Crypt Dweller
Nice, not gonna take it tho
Z
03:56
Zack
If you can make the Oracle lie, this is your chance to win 50 Veo.
MF
03:57
Mr Flintstone
whatever shitcoin your heart desires, i can do the same thing for
CD
03:57
Crypt Dweller
"it is an entirely different service than anyone else offers.
Not just the tech differs.
It is a different product."

Indeed. It's good that Amoveo is not lumped into the current DeFi bonanza, which is not going to end well. Amoveo stands apart from everything else. It either supersedes everything else on the market (unlikely) or dies a slow, quiet death (likely). Despite these odds, there are still very good reasons to stay interested in Amoveo and root for its success. What it is trying to accomplish is fundamentally different than DeFi, much grander.
03:58
Amoveo is the only crypto project that I believe has actual value in it.
03:58
Aside from Bitcoin of course.
Z
03:59
Zack
In reply to this message
It might be the biggest be we have had?
03:59
50 Veo
MF
04:00
Mr Flintstone
in veo terms probably, maybe if we put 1000 veo on 2+2 =4 that one will be bigger
Deleted invited Deleted Account
Z
04:48
Zack
I figured it out.
Let S be the column vector of the subcurrencies you own in contract A.
Contract A uses matrix A to convert your subcurrencies into subcurrencies for contract B.
B goes to C, and C results in a payout row vector = C which converts subcurrencies into an integer value of how many Veo you own = V.

So the formula is
SABC = V.

Matrix multiplication is associative.
So the payout row vector for contract A is (ABC).
The payout row vector for contract B is (BC).

The matrix that takes subcurrencies from contract A to contract C is (AB).
MF
05:22
Mr Flintstone
In reply to this message
i refreshed this trade with the same terms. expires in 6 veo blocks
C
16:00
Callum Wright
In reply to this message
If you change to 8.6k I'll take this bet
16:00
:P
s
16:20
sanket
In reply to this message
I would be willing to take a bet.
16:20
I didn't see this before
Altpl invited Altpl
B
20:01
Ben
if you do so please give feedback if you think that the Lightnode Interface is sufficent.
Z
20:15
Zack
In reply to this message
MF
23:10
Mr Flintstone
In reply to this message
sure, i can make an offer for 8.6k
23:10
the premium will be higher though
23:10
In reply to this message
and i'll add another trade to the UI
23:10
i got tired of making these trades manually so i wrote a bot to automatically generate these trade offers every so often, the last step is to push them to the website
s
23:19
sanket
awesome. is there a way someone can be notified of this trades?
MF
23:19
Mr Flintstone
hopefully in a day or so you'll just always be able to see btc -10% insurance available on the website
23:22
anyways
23:22
this ends on Jul 4 2020 as reported by coinmarketcap historical data. so it's about 32 hours or so
23:23
you win 50 veo if you're right, premium paid is 3.25 veo
23:23
also whenever i add a new underlying coin to the bot to buy insurance on i'll let this chat know
4 July 2020
B
00:14
Ben
the page is emtpy
MF
00:15
Mr Flintstone
yeah someone took the trade
00:15
i think
00:15
or it expired
B
00:19
Ben
so there is no history on that?
MF
00:19
it expired
Z
00:19
Zack
http://explorer.veopool.pw/index.php recent blocks look empty
B
00:20
Ben
ok
MF
00:20
Mr Flintstone
these are all off chain offers until someone accepts
B
00:20
Ben
right
00:21
btw. usability enhancment: would be nice to say when this trade approx. would expire and maybe give a current block height as Indication.
MF
00:21
Mr Flintstone
yeah that makes sense
B
00:22
Ben
and to give it a bit more format and color, to avoid me getting goosbumps.
Z
00:22
Zack
In reply to this message
I added that to the todo list so we wont forget.
B
00:22
Ben
perfect zack.
00:25
and maybe to visualize with some nice graphics what side you can take in this bet. that is all very cryptic.
Deleted invited Deleted Account
Z
05:24
Zack
Mr flintstone made the first trading bot.
This is a new era of amoveo.
AI algorithmic traders.
Tauredunum invited Tauredunum
EA
11:50
Eric Arsenault
Zach have you looked at realit.io? Looks like Gnosis is using them as their oracle
Z
12:31
Zack
Looks like they tried to rebuild Amoveo's oracle in ethereum.
I think that doesn't work.

Amoveo is willing to fork over a bad question in a way that ethereum is not willing to.

They also support a bunch of other broken designs.
MF
12:34
Mr Flintstone
another issue is the ether will be valuable even if it comes from a dishonest report
12:35
i think this game degenerates into something like poker
12:35
but we will see
MF
13:10
Mr Flintstone
there should always be an offer for a bitcoin put option expiring between 24 and 48hrs from now with a strike of -10% on this page now:
http://159.89.87.58:8090/main.html
13:11
it will pay out 10 veo
13:13
if you can figure out how to game the bot, you can win up to 50 veo
C
14:20
Callum Wright
In reply to this message
any link?
14:23
In reply to this message
just an opinion, I think make it lower like -5% (obv with lower rewards) would encourage participation more
MF
14:24
Mr Flintstone
sure, ill do a -5% one
14:26
strike is 8630
14:26
there will always be a -5% put option here
14:28
i think probably what makes sense in the future is to run the above page locally and load keys then just accept a trade with one click instead of the copy paste stuff you have to do now
C
14:41
Callum Wright
In reply to this message
is the reward decrease as time come closer or price get closer to strike?
MF
14:41
Mr Flintstone
how much you have to pay changes based on the time
14:42
since they would be anywhere between 24 and 48 hours, you have to pay more for one that lasts 48 hours vs one that lasts 24 hours. it will always keep the strike price about 5% below spot
C
14:43
Callum Wright
In reply to this message
yeah I mean like, instead of paying now for example, if I wait until price get below 8.9k in next 4 hours, let's say, is the reward gonna be less?
MF
14:43
Mr Flintstone
sorry
14:44
no the strike will go down, the reward will stay the same
14:44
so if bitcoin's at 8.9k youd still win 10 veo but the strike price would be 8455
14:45
these trade offers are constantly expiring and i am replacing them with fresh ones, so i can update the strike price
C
14:45
Callum Wright
I see
14:45
dumb question but the expiry time 121685 is in miliseconds?
MF
14:46
Mr Flintstone
block height
C
14:47
Callum Wright
oh yeah obvious, dumb question haha
14:47
ok understood how it works now, thanks
MF
14:49
Mr Flintstone
np it isnt very intuitive yet
C
16:11
Callum Wright
In reply to this message
How much does it cost your bot to keep generating channels like this?
Z
18:58
Zack
In reply to this message
Channel offers are off-chain. If no one accepts, then it costs him nothing.

He just leaves his browser open.
Z
23:10
Zack
It seems like certain computations get exponentially more expensive if we increase the number of subcurrencies in a shareable contract.
So I guess we need some upper limit.
I guess ill make a governance variable for that.
5 July 2020
Z
01:03
Zack
I'm thinking when you withdraw winnings from a contract, if you own more than one subcurrency in that contract, maybe it should do them all in a single tx.
MF
01:57
Mr Flintstone
In reply to this message
also when you accept the trade, you should also simultaneously sign a channel close offer which gives you 99+% of the value in the channel. nobody would agree to this unless they were going to lose 100%, so as soon as the event happens and you win,the other party will close the channel to get some veo instead of losing it all, and your winnings will just show up in your pubkey balance without needing to do anything
01:57
i think this would mean you could get the user experience down to a 1 click on accept trade offer, and a fast settlement
mx
02:01
mr x
good thinking
mx
02:25
mr x
just copy every betting site by scraping the odds :P
MF
02:26
Mr Flintstone
you can offer better odds in theory
mx
02:26
mr x
yeah...
MF
02:26
Mr Flintstone
costs are way less
mx
02:30
mr x
binary events better for ui
02:30
because presigning
MF
02:33
Mr Flintstone
for stuff like cfd, you can do kind of take profits/ maybe stop loss too by integrating binary conditions and presigning with the scalar
Z
02:35
Zack
It is turing complete.
You could reference a different oracle that checks if the price ever crosses a limit.
Deleted joined group by link from Group
MF
02:39
Mr Flintstone
In reply to this message
actually if you presign 99% for a scalar, you get your money out before the other side runs out of margin
02:39
that seems like a nice feature
02:42
maybe in the same block, you can make another transaction to get your exposure back, and make these atomic somehow?
Z
02:43
Zack
In reply to this message
Atomically connecting trades in single price batches is what we made that market tool for.
Deleted invited Deleted Account
6 July 2020
MF
04:05
Mr Flintstone
In reply to this message
now additional logic to the light wallet has been coded where when you accept a trade, it concurrently signs a channel close offer giving you 99% of the possible winnings and pushes this close offer to the trade explorer so it is public. next steps are to program the trade explorer to display these close channel offers for people who want to see them, and then after that, make the trade explorer local so you can with one click, enter a trade & sign a channel close so you don't have do anything in the case of winning or losing
mx
06:56
mr x
06:58
where code? 😇
MF
07:33
Mr Flintstone
i'm testing the part where the trade explorer hosts the sent channel close real quick, then ill put it on github
MF
09:26
Mr Flintstone
ok
09:27
so if you go into src/js/ folder, you can open up otc_listener2.html
09:29
when you load keys and then accept a trade, it pushes it the trade offer on-chain, then also signs and pushes a channel close offer so it is hosted by the trade explorer. if you hit go with a valid trade offer, if you wait a few seconds then click check balance you can see an unconfirmed negative balance.
09:30
the trade explorer UI doesnt show the channel close offer. but it is accessible by API pull, where you can put in your pubkey and find all the channel close offers addressed to you. but this step is only for specialists so regular users wont need to know about it
Z
09:31
Zack
In reply to this message
We can make a button on your new page to display them all
MF
09:31
Mr Flintstone
you can see the lines where the channel close offer is pushed to the trade explorer here:

https://github.com/mr-pookenstein/light-node-amoveo-2/blob/master/src/js/otc_finisher2.js#L374
09:32
and you can see where an example API pull is done to pull any channel close offers hosted by the server:

https://github.com/mr-pookenstein/light-node-amoveo-2/blob/master/src/js/otc_finisher2.js#L382
09:33
now we are at the point where we can make the trade explorer run locally, then we have enough to just add a button to the trades to accept and everything happens automatically after that
MF
09:52
Mr Flintstone
there are some small offers up here
09:52
cost ~0.014 veo
mx
11:19
mr x
Ok accepted. My work is now done... :P
11:23
now bet explorer on same page...
11:24
autosync and balance update xD
11:25
and you start sucking the blood out of all internet betting sites
MF
11:45
Mr Flintstone
i think we can also create like a network of these explorers since the full nodes host them on startup. so as soon as you send your trade to one it is passed to all of them
11:46
then it would be funny if you put like an "undercut" button on the trades that copied it but at a better price and rebroadcast it to the network
11:50
you could also, when you broadcast a trade, pay someone else on-chain contingent on that trade getting matched into a block. so you are basically paying them for the service of getting your trade matched
11:50
trust free
MF
20:17
Mr Flintstone
sometime later today, i am going to work on making the explorer local
20:17
im thinking at first, something simple. like just copy and paste the code, and maybe do some kind of API pull?
20:18
i think it has all the stuff already to check if the trades are valid, and will remove expired trades with existing logi
20:18
logic
Z
20:18
Zack
you want the p2p explorer page to be a part of the light node?
MF
20:18
Mr Flintstone
yeah
20:18
oh wrong chat lol
20:18
but yeah
Z
20:18
Zack
sounds good
20:20
1) copy paste the javascript and html
2) add a link in the light node to the new page
3) teach the amoveo node to serve these new pages of js and html by adding them to the whitelist
4) update some api requests of the p2p server to use our new request function instead of the old variable_get function.
MF
20:25
Mr Flintstone
yeah
7 July 2020
Deleted joined group by link from Group
MF
01:04
Mr Flintstone
im thinking, potentially we want some kind of update to the channel creation transaction that lets you make a channel offer, but the person accepting it can choose to only take some proportion of it instead of all of it.
MF
02:01
Mr Flintstone
In reply to this message
we can maybe consider this if the tools we’re building to simplify the ux get popular
mx
03:00
mr x
things starting to look like an order book :P
Z
05:26
Zack
In reply to this message
maybe we should wait for the layer 2 market for this feature
MF
05:30
Mr Flintstone
yeah
MF
09:31
Mr Flintstone
maybe a “request for quote” button could be made on the trade explorer
09:32
where you just describe some kind of trade you want in simple english, and then it is broadcast to the network, and maybe a specialist will craft it for you and broadcast it back out.
Deleted invited Deleted Account
Z
22:03
Zack
im having a little trouble with these shareable contracts.
We have this tool to keep track of the total amount of veo going in and out of every block, to verify that no new veo comes from no-where.
I want this tool to be compatible with the shareable contracts.
So that means it needs to be able to scan these contracts and know how much veo is in them.

The difficulty is that we can have contracts priced in other contracts, and we can have contracts resolve into other contracts.
So given a handful of contract objects being used in a block, it isn't clear how much veo we should be assigning to each one.
22:05
I guess any contract that can resolve into veo should have the total quantity of veo written on it, and it isn't complicated.

But what if that contract resolves into another un-resolved contract?
If I convert some type 1 subcurrency from the first contract into a few different kinds of subcurency in the second contract, what numbers should be written on the 2 contracts to keep track of how much total veo is being used?
22:06
Seems like the solution is that as soon as the first contract resolves, we should change the volume_of_veo number on it to 0, and add all those veo to the volume_of_veo number on the second contract.
22:07
So what if we have a contract priced in a subcurrency? what number should we write for the volume?

I guess in this case, volume should indicate the total amount of subcurrency in that contract, and we should teach the checksum tool to count this kind of contract as if it owns zero veo.
MF
22:25
Mr Flintstone
couldnt you have all the child shareable contracts point to the on chain parent which just has the initial veo locked amount written
22:26
or like, contracts that are generated by other contracts point to the original one
Z
22:26
Zack
yeah, that is part of it
22:26
we need to handle all the cases
MF
22:27
Mr Flintstone
or i guess, since you can get veo out of one of the children without going all the way back to the parent, you need to manage that case
22:27
In reply to this message
doesnt this solve it?
Z
22:27
Zack
a contract can either pay out the source currency it was made with, or it can payout in subcurrencies for another contract that has the same source currency.
22:28
if the source currency isn't veo, it can't pay out veo
Deleted invited Deleted Account
8 July 2020
Deleted invited Deleted Account
11:40
Deleted Account
Are there any write-ups available on the subcurrencies update?
MF
11:41
Mr Flintstone
In reply to this message
i finished doing this, so the trade explorer is local, and then you just accept the trade with one click after loading keys
11:41
and then it broadcasts the 99% channel close offer to the server and also puts the trade on chain
11:42
once you accept, you can see it show up in your unconfirmed balance
11:43
it sync automatically as well and refreshes the sync every 10 seconds i think
11:44
things to consider: if you dont have a pubkey, generate one and throw the private key in localstorage immediately so you dont have to sign in and you already have an account
11:45
probably also need some kind of verification that you actually want to accept the trade cuz its literally one click and its out at the moment
12:08
Deleted Account
Thanks
MF
12:10
Mr Flintstone
imagine you lock veo up in a special account for a month, and by locking it up you get to create 2 different transferable tokens. each token gets to claim the locked up veo at the end of the month in a proportion determined by some smart contract logic. so if you wanted to do like, a us dollar stablecoin, you would say in the smart contract language this token has a claim to $1 of value in the special account. and then the other token has claim to the lower of either total veo in the special account minus 1 dollar of veo, or 0. so then arbitrageurs should be willing to buy the token that has claim to $1 for very close to $1 provided appropriate collateralization. and if the token goes over $1, you can create more and sell them
12:11
i would imagine that if you were to collateralize these kinds of monthly maturity us dollar stablecoins with 7 to 8 times their value in veo, they would be pretty high quality
12:11
then since they are transferable, you can use them to create contracts and participate in betting, and they could be plugged directly into the trade explorer or amoveobook or w/e
12:13
you would need to use fungible tokens, so we would need to come up with some kind of standard to use, but probably weekly or monthly would be fine
12:14
what i described isnt the exact process but it is more or less a high level summary of my understanding of how subcurrencies will work
12:25
In reply to this message
localstorage could also be used to manage all of your position data when you accept a trade. so we could generate a list of your current positions on the page too.
12:26
and we can add a way to download it and re upload for backup
9 July 2020
Deleted invited Deleted Account
G
04:02
Gregory
veoscan dead?
Z
04:02
Zack
yeah, it has been down for a while
G
04:03
Gregory
zack, do you have resources to buy food?
Z
04:05
Zack
my survival needs are secure.
G
04:06
Gregory
till the end?
aqua invited aqua
a
04:29
aqua
Hey
MF
07:20
Mr Flintstone
i pushed some updates to github, looks like this now. if bitcoin call or put options are formatted correctly in the oracle langauge, they show up like this now
07:20
Z
07:21
Zack
This is great
MF
07:21
Mr Flintstone
once you hit see odds, it tells you the odds, then you can accept in one click and it shows up in your unconfirmed balance by querying the node for the mempool
07:22
we still have some work to do on having the page automatically refresh the trades, and make sure you dont see trades that have already been taken
07:22
but it's geting there
07:23
also need to code some channel management stuff in localstorage but that isnt too hard
07:26
once that stuff is done, we can add in a "your current positions" section, then throw some css on it
mx
07:41
mr x
awesome
mx
08:22
mr x
might as well make it a wallet :P
Z
08:27
Zack
It's in his fork of the light node wallet
MF
08:29
Mr Flintstone
he means like add spends to it
Z
08:29
Zack
Oh right.
MF
10:03
Mr Flintstone
20 veo put option at strike of $8930 that matures in ~ 2 days is on the explorer
T
11:26
Topab
Very short and interesting. At the end, at all ends in Amoveo https://tonysheng.substack.com/p/unblocking-creative-output-with-technology
MF
11:56
Mr Flintstone
someone mentioned if there was a way to be notified of new trades
11:57
so maybe we can make a twitter bot
11:57
then if you want, you can turn notifications on
12:03
one interesting thing about this design is that since the offers are off chain, you aren't really capital constrained. you could for example take 50 veo and make 500 veo worth of offers in different bets. or more
Deleted invited Deleted Account
Z
18:41
Zack
In reply to this message
Good point
Adept Proposal invited Adept Proposal
10 July 2020
CD
00:14
Crypt Dweller
Mr Flintstone is a god
00:26
This is like watching the birth of a new universe.. You guys are gonna make history
Deleted invited Deleted Account
K
04:48
K
Realistically speaking, a soft fork bribery attack could never work on a pos network as coin are distributed as stated in the Power Law theory
04:49
There will always be whales on the platform who will be extremely hard to bribe. It wont be cheaper than a centralized entity
04:50
Especially hard if people who are large holders are involved in dapps on the network
Z
04:50
Zack
In reply to this message
It is cheaper to bribe the validators who have the least stake.
So a power law distribution is less secure than if the validators each had the same amount of stake.
04:50
You don't have to bribe the whales. Bribe all the guppies.
K
04:51
K
In reply to this message
But you wont reach majority stake doing that
Z
04:51
Zack
Bribe the 51%who own less.
K
04:54
K
When pos networks grow, does the stake become more decentralized? Or is it always the same
Z
04:55
Zack
In reply to this message
I guess it depends on the network. I think some are hard coded to have a fixed number of validators, and others let anyone with more than some minimum balance participate as a validator
04:55
Also, not clear what "decentralized" means in this context.
K
04:56
K
In reply to this message
In general whales will have less power over the network
Z
04:56
Zack
Better to talk about the relative level of trust.
K
04:56
K
So it will be easier to bribe relative to its size
Z
04:57
Zack
In reply to this message
That sounds reasonable. If more people are involved, then the typical person probably has less total control.
mx
05:54
mr x
system is centralized to the extent it is ruled by "voting" xD??
Z
06:10
Zack
It is not useful to think in terms of centralized/decentralized. Everyone has a different definition for what that means, and none of the definitions are useful for evaluating whether a cryptocurrency is likely to succeed.

It is much better to think in terms of trustful/secure, which has a formal definition based in mathematics, and is useful for assessing how likely a cryptocurrency is to be attacked. https://github.com/zack-bitcoin/amoveo-docs/blob/master/basics/trust_theory.md
Deleted joined group by link from Group
MF
22:38
Mr Flintstone
22:38
so there is a filter section now, so we can manage a high volume of Events very easily
22:39
next steps are to modify the backend logic so it can support options on any cryptocurrency
22:40
then ill have my bot basically create the entire vol surface for these coins (maybe top 100 on cmc?) i.e. all the strikes and maturities you can think of for the options, since we can easily filter
22:41
and then when thats ready, ill make the section that displays Odds and lets you accept trades more user friendly (sort, filter etc)
22:41
then build out the My positions section, to show you what you've already bet on
22:45
In reply to this message
though maybe will need to be more targeted cuz of bandwidth considerations. we will find out
mx
23:32
mr x
woah... when ui for bet operators :P
11 July 2020
MF
00:26
Mr Flintstone
In reply to this message
im trying to think what a good way to implement this is
00:27
the subcurrency update will make getting your winnings much simpler, since anyone can do it for you instead of just the person you signed a channel with currently
00:29
In reply to this message
probably at first some bet offer presets, and a way to aggregate your positions, and a way to manually report the outcome in the UI and it will settle any positions you have open
00:31
In reply to this message
once we are able to do this, we can also make it really easy to offer bets in the UI, and you dont need to worry about managing the settlement of positions if you dont want to
00:32
since you are also signing a trade offer for 99% of your stake in the bet, when you offer a bet. and whoever accepts, they are doing the same thing when they accept. and anyone can take these trade offers
00:36
shareable contracts are nice
00:37
i think itll be rly easy to update this UI as well once we have them
00:42
we could also have it be betting in USD instead of betting in VEO which is 10x better imo
Z
00:44
Zack
it might make more sense to swap USD for a contract who's resolution is priced in USD.
That way if the 2 USD's have different expirations, it still works.
MF
01:20
Mr Flintstone
what kind of scheme could we use to pay the tx fees in usd
01:20
so an account doesnt need veo
01:20
i assume you would need to sell some in the same block to someone else for veo
01:20
economic abstraction would work except there are small amounts of veo burned per tx
Z
01:21
Zack
You can set the fee to zero, and have some agreement with the mining pool
01:22
Like, you pay the pool in stable USD for credits, and they reduce your credits when they include a tx.
MF
01:23
Mr Flintstone
i think maybe you can do it trust free, like a contract to pay the coinbase address of your block some usd?
Z
01:30
Zack
If you have a channel with the mining pool, it is possible.
MF
13:27
Mr Flintstone
i pushed some updates to github.
https://github.com/mr-pookenstein/light-node-amoveo-2

now we have a My positions section which shows you what positions you have on-chain. it also doubles as a channel management feature, since you can download all the channel data associated with these positions.
13:27
13:27
it looks like this^^
13:29
next, a way to filter positions the same way as Events, and then a filter toggle on Odds to show only the best odds/minimum veo offered etc. as well as improving the presentation of the odds. and also add some expiration info for non-whitelisted oracles
Z
18:40
Zack
In reply to this message
Very cool. This is a big improvement.
12 July 2020
MF
00:54
Mr Flintstone
i think it makes sense to add a button to My positions that shows all the channel close offers that have been addressed to you, with a button to accept next to each individual close offer. so it is easy for the bet operator to settle trades they have lost, and make a small amount of money back
01:01
probably, we can just add a button to the existing list of positions only if there is a channel close in the database addressed to your pubkey. it would let you settle the trade early if you lost, and in exchange pay you some veo. and then there can be a button to send another channel close offer as well
Z
01:02
Zack
that sounds good
Z
01:23
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/basics/trust_theory.md
This is the mathematical definition of security we are using to assess the oracle.
MF
01:23
Mr Flintstone
In reply to this message
the amount of money riding on an oracle decision doesnt impact the accuracy of the oracle in amoveo. in many other oracle systems if enough money is at stake, incentives to provide accurate data by the oracle start falling apart
Z
01:24
Zack
if you use this method, you can calculate a number for how secure a tool is.
It gives a better number for the Amoveo oracle than any other I have reviewed.
MF
01:24
Mr Flintstone
In reply to this message
an example is what happened with makerdao, when they froze their oracle to protect whales from being liquidated for pennies on the march 12 -50% day
01:25
but these kinds of oracle failures could lead to much more loss of money in the future
01:29
im not sure how much money is riding on link oracles at the moment
01:29
but yeah, there is a lot of money in maker
Z
01:31
Zack
Security and cost are different perspectives on one number.
If an Oracle is less secure, it is also more expensive to use.

https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/consensus_efficiency.md
MF
02:09
Mr Flintstone
lol someone took a 5 veo trade
Z
02:10
Zack
great
MF
02:11
Mr Flintstone
whoever that is plz tell me if the UI is bugging
02:13
it matures in ~30 hours
JS
04:23
Jon Snow
@Jbreezy0 is becoming the first systematic market maker of Amoveo!
Z
04:34
Zack
wasn't there a site, veomarkets?
They were trying this with an older version of channels.
MF
04:35
Mr Flintstone
JS
04:45
Jon Snow
Were they also making the market? Or just created the order book to display others order?
04:45
I don’t remember now
Z
04:46
Zack
I think they wanted to do both.
but with the old channels we ran into serious liquidity issues. you had to lock up a ton of money to make the market work correctly.
04:46
maybe once the subcurrency update happens, then their website will be able to work
JS
04:47
Jon Snow
I see
Z
04:51
Zack
the channel offers stuff Mr Flinstone is working with is a partial solution.
but it is on-chain, so it has front running issues.

once the subcurrency update happens, we can have channels priced in shares of a smart contract, so we don't need to lock up anything extra in our contracts.
JS
04:54
Jon Snow
When should we expect this update happens?
Z
04:55
Zack
its hard to know
K
05:17
K
Hypothetically, what happens if by chance blocks go a little too fast and a bet expires before anyone knows the true outcome?
MF
05:18
Mr Flintstone
we did this math earlier today haha
Z
05:18
Zack
I think for a length of time greater than like 30 blocks, it starts to look like a bell curve. and the standard deviation of that bell curve is sqrt(expected number of blocks).
MF
05:21
Mr Flintstone
so like, if there is an event in a week
05:22
making some assumptions (if a normal week is 1000 blocks, and hash rate is constant, etc) there is a 99.85% chance there will be fewer than ~1100 blocks
05:22
1000 + 3*sqrt(1000)
05:22
3 being # of st dev
05:23
i want to build this kind of oracle start time safety tolerance into the UI, so it tells you the 99.9% confidence for oracle start time
K
05:25
K
In reply to this message
hypothetically though if in the small chance it did happen
05:25
is there a way to extend the bet?
MF
05:26
Mr Flintstone
i suppose in the smart contract language you could say if oracle 1 returned bad question then use oracle 2 which is at a later date, and then in oracle 1's language you can be like "if some crazy shit happens with the blocks then return bad question"
05:27
but i think we can just add like 2 standard deviations and make it >99.99% or w/e instead
05:29
i wouldnt expect the oracle to be needed very frequently
05:29
anyhow
05:29
most trades should settle without the need for the oracle enforcement
Z
05:41
Zack
The Oracle process takes at least a week.
For only a small bet, you can extend this to two weeks.

The Oracle mechanism is a kind of betting mechanism.
mx
05:50
mr x
stupid question: oracles must reference block height not real time?
Z
05:50
Zack
it is hard for the blockchain to enforce things about real time.
05:51
we can't trust the timestamps to be exactly right
mx
05:51
mr x
difficulty adjustment though?
MF
05:51
Mr Flintstone
currently you have to put a block height for the oracle start time
05:51
you can use the difficulty adjustment to have some level of certainty about the time x blocks in the future
mx
07:10
mr x
Isn't the settle early option only for cases where you lost?
MF
07:21
Mr Flintstone
yeah, its more like offer to settle early
07:21
if you didnt already sign a ctc
07:23
im not sure you should need that button tbh
mx
07:31
mr x
right
MF
13:55
Mr Flintstone
i think in order to build the settle early stuff into the UI, we should first have something to create new bets. so we could ensure there is always a channel close for either side, so they could both settle early.
MF
15:03
Mr Flintstone
i think it would be easier to have whitelisted oracle language across all kinds of assets with an oracle language scheme like this. "W = coinmarketcap.com; X = $10,000; Y = Bitcoin; Z = Jul 13 2020; return (price of Y is less than X as of Z as reported by W)"
15:04
so then, the language inside of the return statement could uniquely define a put
15:04
so we can have 1 standard per instrument type
15:09
"W = coinmarketcap.com; X1 = $10,000; X2 = $9000; Y = Bitcoin; Z = Jul 13 2020; return (price of Y is less than X1 and greater than X2 of Z as reported by W)"
15:09
this would be a strangle
15:10
it isnt really 1:1 since they arent technically options in the vanilla sense but you can get similar kinds of exposures using these "binary options"
15:12
"team X defeated team Y on date Z" is even easier
15:21
it would mean for the UX of creating bets, that you just select the instrument type, (coin option, sports bet etc), then fields to put in the the variables XYZ etc show up, and you hit go and the backend handles the rest
13 July 2020
mx
10:48
mr x
settle early not working?
MF
10:48
Mr Flintstone
i didnt put the code in yet
10:48
on github
10:48
like the backend
mx
10:49
mr x
ok
MF
10:49
Mr Flintstone
i built a Create tab already and then am now doing the ctc stuff on my positions, will push to github when thats ready. also changed the formatting of the coin options so you can do any coin you want
mx
10:51
mr x
ok cool
MF
11:50
Mr Flintstone
k
11:54
its in there
11:56
since we generalized the crypto options i also need to make it show what direction youre buying lol (true or false)
12:04
In reply to this message
fixed that
12:08
keep in mind, if you create a bet, you won't be able to automatically broadcast a 99% close until it's in a block, until we have the subcurrency update at least. since now you need the other person's pubkey in the ctc transaction. so i will put a button to send another 99% close if there isnt one on the server(s) youre connected to
MF
14:12
Mr Flintstone
added competitions to the trade creator
CD
15:13
Crypt Dweller
This is exciting. Don't forget to do your pullups and pushups today, Zack.
14 July 2020
mx
00:22
mr x
Lol I didn't realize i won xD
00:22
but yeah...
MF
00:22
Mr Flintstone
in amoveo everyone wins
mx
00:23
mr x
😅👍
00:24
your address?
MF
01:00
Mr Flintstone
dw
01:00
i think we should have a spend tab
01:00
like create, explore, send
01:01
then its basically a wallet
mx
01:06
mr x
yes
01:06
thats the mvp
01:07
and the whole publish oracle onchain and get your money out manually :P
MF
01:08
Mr Flintstone
yeah, in the worst case
01:08
at least for this iteration
mx
01:08
mr x
right
MF
01:09
Mr Flintstone
once we can share the contracts, it only takes one person to specialize in settling trades and the entire ecosystem can be supported
mx
01:09
mr x
really??
MF
01:09
Mr Flintstone
yeah
01:10
i basically buy the contract from you for 99%. and it gets transferred to me
mx
01:10
mr x
ohh
MF
01:10
Mr Flintstone
relatively risk free profit provided that you dont get hustled by a bad oracle question. but we can have tools to recognize the question is in a certain format i.e. you are safe
01:11
i still wouldnt expect many on chain oracles to be needed since the specialists can settle amongst each other as well. it would only be in the case where some risk owner truly disappeared
01:11
or there is an oracle dispute
mx
01:12
mr x
yea court system
01:13
like lightning except also oracles
01:13
or something
Z
01:23
Zack
I added Mr Flinstone's work to the master branch of the light node.
MF
01:23
Mr Flintstone
you should use a fresh account, since this wont be able to read localstorage for your positions or key
01:23
soon we will have an import/export account button
MF
01:46
Mr Flintstone
i think there are some issues with this website version we still need to work out, so hang tight lol
04:00
It happened to Abra
MF
04:00
Mr Flintstone
it is important to comply with regulations in your local jurisdiction or shit like that will happen
04:00
i couldnt believe it when the news first came out they were trying to do this tbh
mx
04:00
mr x
yeah...
04:02
ethereum multisig oracles and admin keys totally different i guess...
04:04
or they are just not secure
MF
04:04
Mr Flintstone
US regulators have been super light touch with blockchain native finance apps so im not sure they would be compelled to stop operating from a securities law / commodities law perspective. but they will be compelled to serve judicial orders etc if sufficient money gets stolen
04:05
like how a USDC address with 100k was compelled to be frozen by a judge
04:06
next logical step is like, makerdao gets accused of some kind of negligence and is compelled to drain the collateral to another contract and have a new dai contract that is permissioned via kyc
mx
04:07
mr x
hah
MF
04:07
Mr Flintstone
or LINK nodes are not allowed to serve messages that enforce securities transactions that are not being conducted on a licensed exchange
04:08
if someone gets burned really bad
04:09
also lol that their penalty was $150k for this
04:09
brazenly defying securities law
mx
04:12
mr x
guess nobody really used it or something
04:13
lubin will protect ethereum
04:15
" The order further finds that Abra’s U.S.-based employees effected thousands of stock and ETF purchases in the U.S. to hedge the contracts."
04:15
guess it was used
Z
04:29
Zack
As the law gets more strict, the demand for completely trustless technology gets stronger.
MF
04:30
Mr Flintstone
its also cheaper for businesses to conduct legal business on this kind of substrate
Z
04:31
Zack
Like, in a relative sense?
Seems like compliance gets more expensive if the law is more complicated or restrictive.
MF
04:31
Mr Flintstone
i mean from the perspective of the entire settlement backend is cheap and correct
04:32
if you cant steal from your customers, compliance might be lighter touch as well
Z
04:33
Zack
In reply to this message
Oh, it is cheaper to use trustless tech yes.
CD
06:31
Crypt Dweller
SEC and CFPB priorities are so wrong. Hertz offers what basically amount to a new IPO after going bankrupt to masses of euphoric retail investors? No problem. Some enterprising Wall Street guys create a prediction market platform? Scary! Can't trust normal people to make non-investment financial decisions on their own! But casinos and margin trading and options? No problem. Blockchains are the escape hatch for capitalism to route around ossifying U.S. bureaucracy that seeks to control risks and limit opportunities to those already at the top.
06:32
Zack is completely right
06:36
The Fed juicing overextended bull market psychology with lies about endless flood of Central Bank "dollars" and driving stock prices to ATH with wide participation from unsavvy retail buyers.. it's beyond the pale
06:37
They will pay for their recklessness in the longterm via a complete discrediting of CBs and the myth of QE monetary wizardy
C
16:42
Callum Wright
@zack_amoveo do we use anything from LazyLedger for sortion chain? Can't remember.
Z
18:54
Zack
In reply to this message
No. It doesn't involve lazy ledger.
Also, we abandoned the sortition chains plan.
B
21:32
Ben
in a nutshell was sortition chain technicaly not possible? or why did you drop it?
Z
22:46
Zack
Part of it related to scalability were not possible.
The parts we kept are the subcurrency update being developed.

Since it no longer involves the sortition element, it doesn't make sense to call it "sortition".
15 July 2020
B
13:49
Ben
ok, understood
C
16:30
Callum Wright
In reply to this message
so the implication of it is it's not possible to be scalable?
16:30
just want to understand
Z
18:37
Zack
In reply to this message
No.
The sortition strategy for scalability didn't work.
Scalability could still be possible.
Deleted invited Deleted Account
SergN invited SergN
16 July 2020
K
02:25
K
You Avalanche critique seems to be talking about PoS and not the actual innovation they made which is Avalanche consensus
02:26
You could make Avalanche consensus happen on a pow chain. Could that be your solution to scalability
Z
03:03
Zack
Avalanche consensus is strictly worse than other PoS protocols, which I have already shown do not work. https://github.com/zack-bitcoin/amoveo-docs/blob/master//other_blockchains/avalanche.md
MF
03:50
Mr Flintstone
i am thinking that it may be important to reduce variance in the block time for both trade expiration purposes to reduce free option exposure as well as precision in terms of starting oracle height. so maybe it makes sense to make the blocks much faster & change reward in tandem. we can do a futarchy market to see. this would not change the amount of time required for similar levels of security. the math is that each time you quadruple the frequency of blocks, you cut the volatility and cost of free option in half
03:54
my guess is the market will tell us to push this pretty far but who knows
Z
03:55
Zack
Faster blocks makes it hard on smaller mining pools.
MF
03:55
Mr Flintstone
we dont want a very high uncle rate
03:59
strategy for this market: start offering 1:1 odds that VEO is over $150 in a month. i assume this bet will be taken
03:59
then we start decreasing the dollar amount, to $100, then $80, etc
03:59
once the trades stopped getting taken, this is kind of a good forward estimation for the veo price in a month
Z
04:00
Zack
Can't you go the other way, and wait till a trade gets taken?
04:00
So you don't have to make bad trades?
MF
04:00
Mr Flintstone
yeah
04:00
it would be nice to get people to start using the tools though
04:00
so then once we come up with this price estimation, we can use it as an input, call it X
Z
04:01
Zack
A binary search of the price balances both, and is faster
MF
04:02
Mr Flintstone
so then we create two new offers. the first one says: if the block time is decreased, then return (veo price > X). if not, return bad question. the second one says: if the block time is NOT decreased, then return (veo price < X). if not, return bad question.
04:02
bad question means that both people in the bet get their money back
04:04
then we can start to offer crazy odds on these, to do the process of finding the true price once offers stop getting matched
04:04
if the price of the first is higher than the second, then we should do the update
04:16
In reply to this message
yeah, it is faster
04:17
In reply to this message
we can actually just offer all of these at once
04:17
and see what isnt taken
mx
04:31
mr x
futarchy -> rule by people offering free option
04:32
hmm
04:36
constantly ongoing futarchies taking small steps to direction implied by open orders
mx
05:47
mr x
yeah shorter block times would be convenient
MF
05:47
Mr Flintstone
maybe a futarchy button would be useful on the create page
mx
05:48
mr x
yes
05:51
the futarchy flow currently is just to do some betting to get a feel?
MF
05:52
Mr Flintstone
yeah
Deleted invited Deleted Account
J invited J
MZ
23:23
Mathiu Zatch 4 años en cripto 🇦🇷
Whats is price amov3o
23:23
Mr Crypto invited Mr Crypto
17 July 2020
JS
00:00
Jon Snow
In reply to this message
You can check qtrade.io
Z
02:04
Zack
I got the shareable contracts working. they can resolve into a single type of share winning.
They can resolve into the different shares splitting the reward.
They can resolve by pointing to some other contract, and converting the shares into shares of that other contract.

we can have them priced in veo. we can have them priced in other subcurrencies.
Now im writing the tx for doing matrix multiplication, so we can withdraw resolved subcurrency back to VEO directly.
02:04
Next up will be the new kind of channel. that can be priced in subcurrency, and they become a shareable contract as the first step of the dispute process.
02:10
im thinking instead of a swapping transaction type, we can just use channels?
Z
04:21
Zack
I guess we need a swapping transaction type
MF
04:21
Mr Flintstone
yeah
Z
04:21
Zack
I wrote a first draft of the tx type that does the matrix multiplication for simplifying shareable contract settlement.
MF
04:21
Mr Flintstone
nice
04:22
we are getting closer
MF
04:24
Mr Flintstone
when we are transferring these contracts, is there an easy way for us to package them with an evergreen offer to sell for 99% of the source veo / VUSD / whatever?
04:25
or i guess have an evergreen offer that someone can at any time swap for 99+%
Z
04:26
Zack
currently you need to convince your one partner to buy it for 99%. they have a monopoly on providing this service.
After the subcurrency update, anyone will be able to provide this service.
MF
04:26
Mr Flintstone
yeah i mean after the update
04:27
like i want to transfer a contract around, and a settlement specialist can at any time swap for 99% regardless of who is holding the contract
Z
04:27
Zack
yes, as long as the settlment specialist exists, you can do it
MF
04:28
Mr Flintstone
can it be anyone can spend, so they don't need to be named?
04:28
In reply to this message
you can spend the subcurrency to anyone
04:29
channel contracts get converted to shareable contracts with spendable subcurrency.
and you can use the subcurrency to build more channels.
04:29
it is a nice balance between off-chain and on-chain contracts
MF
04:30
Mr Flintstone
In reply to this message
i mean the evergreen offer to sell this shareable contract for 99% regardless of who is holding it. anyone can accept this?
Z
04:30
Zack
are you talking about early resolution after the contract has expired, or like, a kind of market maker?
MF
04:30
Mr Flintstone
for early resolution
Z
04:31
Zack
if your side is worth nothing, then there is nothing to do. you are done.
if your side is worth 100%, then you can convert the channel to valuable subcurrency, and swap that subcurrency for 99% of it's value in veo.
MF
04:32
Mr Flintstone
i get sent a shareable contract representing a title to all the vUSD source currency if i win. i am offline the entire time. when the event resolves itself and i win, any specialist can give me 99% of vUSD for title to 100% of the vUSD that has been locked up
04:32
i want to be offline the entire time
04:33
this just makes things easier, we can still code it to do all the signing for the 99% offers upon creating the trade even if you cant do what i described
Z
04:36
Zack
when a shareable contract gets created on-chain, it becomes possible to own the two or more types of subcurrency defined by that contract.

You can get sent subcurrency while you are offline, yes. you don't need to generate any account or own any veo in order to receive subcurrency.

oh, I get it.
So when you first buy a bet in a binary event, you also make an offer to sell it for 99% of it's maximum possible value, and this offer has a very long expiration.
So when the event ends, you are left holding your preferred kind of currency, without having to come back online to switch.

So you could have a contract priced in veo, and if you win the veo, it automatically switches out to USD, without you having to come online.

That sounds like a good way to do it.
04:37
ill make swap offers work like channel offers, and this should work.
MF
04:39
Mr Flintstone
In reply to this message
yeah. i am wondering though, is it possible to make this offer to sell for 99% still applicable even if this contract is transferred to a different pubkey?
Z
04:40
Zack
In reply to this message
I don't understand
MF
04:42
Mr Flintstone
step 1. person A buys binary outcome. step 2. person A offers to sell outcome for 99% of preferred currency. step 3. transfer binary outcome to person B. when the event ends, will person B hold the preferred kind of currency?
04:42
assuming they won
Z
04:44
Zack
one option is that person A is able to sell unencumbered ownership in the binary contract to B, and then B is free to make another offer to sell for 99% of the preferred currency.
04:45
Once A already sold ownership in the contract, the old offer for 99% is no longer valid, because there is nothing left to sell.
Deleted joined group by link from Group
Deleted invited Deleted Account
MCL invited MCL
H
19:28
Hoshi
Hi Zack, could you help this guy out?
H
19:59
Hoshi
Thanks 👍
Z
21:30
Zack
I am running into some more difficulties with calculating the checksum of the total inputs of veo into and out of a block.
When we use shareable contracts to split veo into types, it gets complicated.

Before the plan was that if contractA settles by transforming into contractB, that we would set contractA's value to 0, and add all that value to contract B.
So that when people with draw from A to B, we record that as a movement of 0 value.
and when they withdraw from B to the main chain, that is when the veo moves into accounts and disappears from a contract.

But now we have this matrix simplification tx type.
So we can simplify A, and allow people who are holding subcurrency in A to withdraw directly to Veo, without having to own anything in B.

So when that happens, there is a mix of subcurrencies in contract A and contract B, and it is not clear if I can know the value of veo in each.
21:33
Maybe each contract needs to keep a record of the outstanding balance of each of the subcurrency types it can have.
21:35
This checksum verification that the value of veo into and out of each block, it is very convenient.
It makes me feel more comfortable writing updates, because it prevents me from breaking it in the worst ways.
It would be really nice if we could find a way to make the smart contract system compatible with the checksum system.
21:36
maybe the checksum system should be aware of subcurrencies, and make sure that the amount of each subcurrency into and out of each block is balanced?
21:51
I think ive never taken a class on linear algebra.
I looked at a couple books, and we used some linear algebra tools in some physics classes I took.

The security of this smart contract system based on how stochastic matrices work when you multiply them. It seems pretty risky to shut off the checksum system for smart contracts and depend on this linear algebra security instead.
James James invited James James
23:47
Will you still be building VEO 5 years from now if it's marketcap doesn't increase much?
Z
23:52
Zack
The market cap doesn't matter.
I will keep working on whatever I think is most productive to achieve futarchy.
23:57
In reply to this message
Anyone have any ideas yet?
18 July 2020
CD
00:00
Crypt Dweller
Maybe ask the Bismuth or Nyzo devs. They seem to know a lot about blockchains and they share their knowledge.
Z
00:23
Zack
So, we need to find some set of transformations that preserve the quantity of veo.

1)
we can have the same amount of veo on each side.
N*veo = N*veo

2)
we can have veo transform into a complete set for a contract, and the reverse
N*veo = N(complete set for market)

3)
each shareable contract can finalize with a payout vector once. The vector can't change. The vector must sum to 1.

4)
any subcurrency can be converted to veo according to the payout vector.

5)
each shareable contract can finalize with a payout matrix + child contract. the matrix must be left-stochastic. meaning that every row sums to 1.

6)
A subcurrency can be converted to other subcurrencies, according to that contract's matrix and child contract.

7)
A shareable contract that was finalized with a matrix and child contract, it can be updated to finalize to the grandchild contract. The new_matrix = parent_matrix X child_matrix.

8)
a shareable contract that was finalized with a matrix, and the child is currently finalized to a payout vector. This contract can be updated to use a payout vector = matrix X child_payout_vector.



This list of rules, if obeyed, is sufficient to verify that the total number of veo doesn't change.
But it is a lot more complicated than the old rules.
00:24
So I guess ill add these rules into the checksum system.
Z
00:49
Zack
Procedurally, I think it will look something like this:

First I'll focus on the sub-accounts.
I will group them up to convert to veo on each side where I can.
next ill remove sub-currency that exists in equal amounts on both sides.
then ill do any sub-currency to veo transformations, according to a payout vector.
then ill make sure the remaining veo on both sides are balanced.
then ill check that any matrix transformations were computed correctly.
MF
00:52
Mr Flintstone
can’t we only care about source veo? there can be bugs creating subcurrency inflation, but they still cant take more veo out than what is in the source bucket
00:53
so we just need to make sure source veo transactions are OK, instead of the others
Z
00:53
Zack
In reply to this message
it gets complicated because a contract can resolve by pointing to another existing contract.
If I withdraw one of the 3 types of subcurrency from the first into the second, it isn't clear how much veo each contract has.
00:54
when a contract is first created, we don't know which child contract it could end up pointing to at expiration.
MF
00:54
Mr Flintstone
we still know how much veo is in sources
00:55
so we know veo taken out needs to be < that
00:55
even if it is only one additional guardrail
00:55
i.e there could be a bug to steal all the source veo even if it doesnt create new veo
Z
00:56
Zack
In reply to this message
if we do it that way, then each shareable contract would need to be aware of all other contracts in the system that resolve to it.
A tx for the one contract would require merkle proofs for them all.
MF
00:56
Mr Flintstone
Isnt this just for nodes checking to see if blocks are valid
00:56
for inflation checks
Z
00:56
Zack
yes, it is a secondary check to verify that we didn't accidentally create veo from nothing
MF
00:56
Mr Flintstone
so im not sure why the contract needs to know about all the veo sources
Z
00:57
Zack
it is an important security feature that lets us feel more confident in developing Amoveo, because it prevents bad failures.
MF
00:57
Mr Flintstone
Yeah i agree it is important
Z
01:02
Zack
In reply to this message
like, imagine if there is a stablecoin contract.
we keep using veo to make bets on sporting events.
The sporting event bets, they resolve to stablecoins as defined by that first contract.
So when a sporting event contract ends, you get paid in tokens from the stablecoin contract.

There could be thousands of sporting event contracts like this.

So imagine I am holding some winning tokens from a sportting bet, they allow me to withdraw a mix of stablecoins and long-veo from the stablecoin contract.

I decide to withdraw my long-veo, but not my stablecoins.

So now I am holding shares for both sides of the sporting contract, and I am holding long-veo, but I don't have stablecoins.

Now the stablecoin contract expires.
So we simplify the sporting contract, allowing us to withdraw the sport bets directly to VEO, without having to touch the stablecoin contract.

So I convert my expired long-veo subcurrency to veo using the stablecoin contract, and I convert my sports bets to veo using the sports bet contract.

When I convert the long-veo to veo, how can the stablecoin contract know that it isn't counterfeiting veo?
Do we need to include merkle proofs of every sport contract that could expire into it?
01:04
Maybe a simpler way to think of it is that we end up in a situation where the total number of each kind of subcurrency for a contract are not equal.
A stablecoin contract could have lots of outstanding stablecoins, and zero long-veo, because something equivalent to long-veo is locked up in some other contracts.
01:07
the point of the checksum system is to do the least work possible to verify that the total number of veo is not being changed.
Now this involves a little matrix multiplication as well.
Z
01:26
Zack
I think I have got a simpler strategy.

If we are using a payout vector to withdraw source currency from a contract, that means this contract has some descendent that resolved to veo.
We should record a pointer to that one down-steam contract, and include a merkel proof of it along with txs that withdraw to veo.

That one down-steam contract should lose value when we withdraw from one of it's ancestors.
01:26
Whenever a contract resolves, we move all it's value to the descendent.
so the down-steam contract has enough value for everyone to withdraw and ends at 0.
Deleted invited Deleted Account
T
07:15
Topab
In reply to this message
Like Josh suggested, you can ask at the Statebox telegram channel. It's full of mathematicians
07:23
They will be happy to help I think
Z
11:47
Zack
In reply to this message
this seems to work, the tests are passing now.
MF
11:47
Mr Flintstone
nice
Rajesh Kumar invited Rajesh Kumar
Dan 🇦🇺 invited Dan 🇦🇺
RK
19:06
Rajesh Kumar
Hello Zack
19:07
Any update about veo
Z
19:08
Zack
https://github.com/zack-bitcoin/amoveo/commits/subcurrency you can see progress on the subcurrency hard update here.
Z
19:24
Zack
How many flavors of subcurrency could we want our shareable contracts to have?
The computational cost grows by O((# flavors)^2)
So we need some limit.

I guess ill start the governance variable at 32. that is probably enough, right?
19:26
actually, looks like matrix multiplication is O((# flavors)^2.373) at best.
And our current algorithm is O((# flavors)^3)
19:29
I can imagine a lot of shareable contracts with 2 outcomes, like for subcurrency.
3 outcomes, like if you are betting on the 2 possible outcomes of an oracle along with the "bad_question" possibility.
4 outcomes, like if we are betting on the correlation of 2 different events without "bad_question".
9 outcomes, if we are betting on the correlation of 2 oracles and including all the "bad_question" outcomes as different flavors.

Are there situations where we want more than 9?
J
21:03
Josh
Since we can do so much with 9, I think it's safe to start with that.
Z
21:07
Zack
I think if we offer some small fixed number, like 9, that it might be possible to build contracts off the subcurrencies of that market, to create something identical to a contract with more than 9 outcomes.
J
21:09
Josh
Like building a basket of subcurrencies? Or combining different bets into new synthetic bets.
Z
21:11
Zack
for example, if you wanted a lottery with 81 different lottery tickets.

Put the entire prize into a market with 9 outcomes, each equally likely to win it all.
Take those 9 new subcurrencies, and for each one create a market with 9 outcomes, each of which is equally likely to win it all.

Now you have 81 subcurrencies, each with 1/81st probability to be worth the same as VEO, and 80/81sts probability to be worth nothing.
21:12
im going to make it a governance variable anyway, because it isn't clear to me right now how to optimize the size of the matrices, and I think the optimal size might change over time depending on what kind of contracts we are using, and how hardware works in the future.
19 July 2020
J
00:39
Josh
sounds good
Z
01:56
Zack
This matrix-multiplication style smart contract is very different from the other existing smart contract systems.
Z
02:38
Zack
I wonder if there is a reason they don't do it this way.
Z
19:51
Zack
ok, I think I have a solid example for why we need this matrix multiplication stuff.

A very common feature of derivatives is the margin call.
The ability to quickly sell your asset at the moment it crosses a margin.

Another feature we need is the ability to support long lasting markets.

Another feature we need is short-term stablecoin contracts. A shorter lasting stablecoin contract can have smaller margins, because there is less time for the price to move.

If we have a long-lasting market, with margin calls, and the margin calls are paid in a stablecoins with an expiration much shorter than how long the market lasts, that means there are multiple different stable-coins we could end up getting paid in, depending on when the margin call gets executed.

That means our margin-call market contract, it would need to be able to be converted into different possible stablecoin contracts, depending on when the margin is crossed.

We want the stablecoins produced from the margin-call contract to be fungible with equivalently defined stablecoins in the same system, so you don't need a separate slot in the consensus state to own both (stablecoins from the margin-call contract) and (stablecoins directly from the stablecoin contract).
19:55
we want to be able to settle these equivalent stablecoins all at once, and not have to run the resolve_contract process twice.
20:00
Maybe it isn't a good example.
With a margin call, one person ends up owning everything in the contract, right?
So I guess it would need to convert back to the source currency, not forward to new stablecoin?
20:10
Another example:
Lets say there are 2 sporting events coming up, EA and EB.
you are confident in your ability to predict the outcome of both. So you make a bet where you win only if you are correct about both.

There are existing markets for EA and EB alone, but your market for EA && EB has almost no traders.

So, if oracle EA expired first, it would be nice if you could convert your shares to shares of EB, and if oracle EB expired, it would be nice if you could convert your shares to shares in EA.

Once you have shares that are fungible with everyone else, you can participate in the bigger markets.
ŽM
21:59
Živojin Mirić
Hello everyone, I've been on a hiatus, contemplating about futarchy. Are there any important news that I missed during past couple of months? Is development of Amoveo progressing as expected?
20 July 2020
Z
04:54
Zack
In reply to this message
We gave up on the scaling aspects of the sortition plan. Now we are developing a system of smart contracts to solve limitations in our current state channels.
So we can have markets without liquidity issues.
MF
04:56
Mr Flintstone
im thinking about betting "No" on events like, "there will be a pull request on the amoveo light node github doing xyz" where xyz is some simple task and pushing it to the trade explorer
04:57
even $5 can be a significant amount value in certain parts of the world.
04:57
so perhaps people with programming skills in emerging economies would be willing to do this
04:58
but the problem is, how much does it cost to convert the veo to their local currency
04:58
they can use the exantech telegram bot to convert it to btc, but I think on chain btc cost is a few dollars right now for a transfer, so that buffer would need to be built in
05:00
maybe if we start with some amount of money we know is enough, like $30-50, and go down from there we can see what the right amount is. and the other person would only need to put up some small amount, like $0.50 of VEO
05:01
one problem is how do they get $0.50 of veo cheaply but the answer to that is we just send it to them
Z
05:28
Zack
Sounds great.
Paying people using smart contracts would be a good use case.
MF
21:26
Mr Flintstone
getting this started with a really simple task:
Z
22:46
Zack
the shareable contracts have a lot of tests now
21 July 2020
Z
02:08
Zack
Next we need to do the swap tx type.
We want it to work similarly to how channels and channel offers currently work.

But what if there is an offer to swap A->B, and an offer for B->C, and I want to swap C->A.

Can I make a swap tx type that has 2 offers inside it, to complete a circle?
Or do we only want to swap between pairs of people?
02:12
I guess circles don't make sense, because it is improbable that both trades are for the correct quantities to be fully matched.
So we only want to swap between pairs.
EA
05:54
Eric Arsenault
In reply to this message
Do you have anything written up that elaborates on this?
05:54
"have markets without liquidity issues" that bit
MF
06:28
Mr Flintstone
this doesnt really talk about liquidity
06:28
or make the connection intuitive imo
Ivan T invited Ivan T
EA
12:58
Eric Arsenault
Any chance you can write up something on that @zack_amoveo just to document it / make it more clear? Would be useful for those who aren't keeping up with the day to day
Z
18:58
Zack
yeah, ok
19:04
ill add a "motivations" section to the smart contract document.
Z
21:20
Zack
https://github.com/zack-bitcoin/amoveo-docs/blob/master/design/shareable_contracts_implementation.md
I rewrote this one as well. It had fallen way behind on changes made to the implementation.
Z
21:53
Zack
I am thinking that for the swap tx, ill make it so the fee needs to be in veo, but either participant can pay the fee. Does that sound ok?
21:53
or do we really want fees in subcurrencies now?
MF
23:10
Mr Flintstone
it would be nice if the miners wanted to accept them to have that option
Z
23:12
Zack
I made the swap tx with a passing test.
23:13
well, I set it up to accept 0 fees, and in that case you don't need a veo denominated account.
So you could pay the miners in a channel.
23:15
https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/swap_tx.erl
It is very similar to the channel-offer channel-accept relationship
23:16
oh, the person who makes the offer, it is looking at their account nonce in a bad way
23:16
I think I can connect it to the sub-account nonce maybe
23:26
In reply to this message
yeah, this worked.
23:28
we just need to remember that to cancel an offer to sell subcurrency, you need to make a payment with that same kind of subcurrency, to update that nonce for the same kind.
23:29
Next up is the new kinds of channels.
They can be denominated in subcurrency, and when they settle on-chain, they get transformed into shareable contracts and subcurrencies.
EA
23:35
Eric Arsenault
In reply to this message
looks a lot better, thanks!
22 July 2020
EA
00:59
Eric Arsenault
Another one to review Zack: https://tellor.io/
Z
01:55
Zack
im thinking that when the new channels are ready, we should get rid of the old channel txs.
So there is less code to maintain.
EA
03:44
Eric Arsenault
In reply to this message
the new features reminds me of the conditional tokens framework Gnosis implemented. I'm sure its very different, but the way people would use it seems similar
Z
03:45
Zack
Gnosis conditional tokens are basically the same as shares in augur markets, and shares in drivechain markets.
Z
04:26
Zack
im thinking that with the swap_tx, we do want to increase the account nonce.
Even though with channels we do not increase it.

Because with swapping there is no channel id getting incremented, so the same tx could get included more than once.
Z
04:47
Zack
we want these new channels to have more than 2 participants.
But we also want to support the channel_offer/channel_accept relationship, which only really makes sense for channels that have pairs of participants.

maybe we need a new channel_accept tx type, and also a channel_new tx type that can have more than 2 participants.
MF
04:56
Mr Flintstone
In reply to this message
we want a bunch of swap offers out at once for all the existing positions though, so automatically having your position settled wouldnt work if you have multiple positions, if the account nonce were incremented
04:58
i dont think it would be a valid transaction to include the second swap if you just rebroadcast it
04:59
maybe we need a swap ID to increment
04:59
that seems better
Z
05:00
Zack
In reply to this message
yeah, exactly
05:00
In reply to this message
right.
So another alternative is to record an id for that swap in the proof of existence tree. that prevents the swap being reused without incrementing the account nonce
MF
05:01
Mr Flintstone
Probably is similar # of bytes to do it either way?
05:02
is it cheaper to read poe tree proofs
Z
05:03
Zack
storing an element in the proof of existence tree is 32 bytes * 16 for the proof. Around 512 bytes.

incrementing an account nonce doesn't take any additional space.
MF
05:04
Mr Flintstone
ok
Z
05:05
Zack
512 bytes of consensus space.
512 * log16 (# elements in the existence tree) bytes of block space.
05:09
Oh yes, it is less than a channel.
BJ K invited BJ K
Z
19:42
Zack
I think reusing the proof-of-existence tree for this doesn't work.
Because the person who is made the swap offer, they need to have exclusive access to this swap-id. The swap id needs to be salted with their pubkey.
So I guess we need another merkle tree.
Just for storing swap-ids of matched swaps.
19:43
they need exclusive access to the swap id, otherwise someone else could use that id for some other swap to make the offer invalid.
19:55
Maybe we are using nonces wrong.
Currently, if your account has nonce 5 for example, and a tx with nonce 8 written that you signed gets included in a bock, then your account nonce jumps up to 8. So any txs for nonce 6 or 7 are now being censored.

example of a different way:
Lets say you are currently nonce 5, and you want to publish 3 txs and don't care about the order.
you could publish 3 txs, all with nonce=8.
Each tx causes your account nonce to increment by 1.
19:57
so im thinking, for the old tx types we should keep the old behaviour. so you can make your nonce jump a lot if you want to cancel your existing trades.

And for only the swap tx, we should make it only increment the nonce for each tx. that way you can have multiple swap txs, and it doesn't matter what order they get matched in.
19:58
I think this provides the same behaviour, without adding all that extra merkel proof data to the txs.
19:59
an account nonce can be anything from 0 to around 16.8 million, and it is cheap to move your money to a new account if the nonce fills up.
Z
20:16
Zack
In reply to this message
I pushed an update to subcurrency branch for this. the tests are still passing.
20:22
this time im setting it up so that if one participant isn't putting money into the channel, their account doesn't need to exist yet.
idk if that will be useful.
23 July 2020
Z
00:54
Zack
in the new version of channels the accounts that control the channel are a vector [Acc1, Acc2, Acc3]

the channel's contract can either output a stochastic vector, which shows how to split up the money between the list of accounts.
or the channel's contract can output a left stochastic matrix and the ID of a contract. This matrix is used to show how the subcurrencies of the contract are distributed to the different accounts that control this channel.
00:55
this makes the mutable contracts totally symmetric with the shareable contracts.
00:56
it is like Acc1 of the channel owns 100% of subcurrency type 1, if that were a shareable contract.
01:01
If your channel was pointing at a smart contract that had closed, and had a payout vector pointing to veo.
Then maybe there should be a way to do matrix multiplication during the process of settling the channel, so you can get paid directly to VEO, instead of needing to temporarily hold some subcurrencies in a closed smart contract.
01:03
I think maybe we aren't exploiting this symmetry as fully as we can
01:04
instead of having all these different channel txs, maybe we just need 3
* for groups of people to make a channel together.
* to post an open offer for a channel than anyone can accept
* to immediately convert the channel into a contract, distributing subcurrency to the owners.
01:05
then we can use the contract resolution process instead of the channel resolution process for the rest.
01:05
since they are identical
MF
01:17
Mr Flintstone
In reply to this message
i imagine some ppl would prefer to still be denominated in USD or some other currency after contracts settle
Z
01:28
Zack
the entire channel could be denominated in usd
01:30
this means the on-chain sub-channel object can be really small
-record(sub_channel, {cid, accounts_hash, amount, closed_flag, source_contract, source_type})
Z
02:41
Zack
This strategy makes it a little more complicated in that updates to the channel state that are signed by the channel participants, these signatures are all verified inside of the smart contract.
02:42
but this gives us a lot of flexibility.
It is best to do the least by default, and let them use the smart contract for whatever custom rules they want.
محمد القحطاني ✨ invited محمد القحطاني ✨
Z
03:49
Zack
The N of N multisig to update the channel, it will happen inside the chalang contract.
Z
04:30
Zack
If we do it this way, creating a n-party channel is the same thing as having a list of N accounts atomically buy different flavors in a new shareable contract.
04:30
So we don't need any channel specific txs at all.
Just one more tx for buying shares in a shareable contract.

And we can get rid of the sub-channel Merkel tree.
04:31
It is one of those magical times where the code gets simpler and more powerful simultaneously
04:33
But it brings into question the entire concept of a "channel".

Yes, all the channel specific things will be possible. But there is no thing to point at and say "this is the channel"

It's just lots of people making evidence to cause shareable contracts to expire in various ways.
Johns invited Johns
Mia invited Mia
ŽM
17:10
Živojin Mirić
In reply to this message
Well hello there @CryptoMia
Z
19:16
Zack
we already have swapping.
I think we need pair-buying.
2 people provide veo, or some other source currency to a contract, and they receive an agreed upon mixture of the subcurrencies produced by the contract.
19:17
maybe we need pair-selling too.
19:27
or maybe swapping is enough?
I can make the contract I am interested in, buy both kinds of shares, and offer to swap the one I don't like for veo.

I guess the pure swapping solution requires locking a little more money up, so we can't do that.
19:28
and we need a group-buy tx, for when more than 2 people are investing in a contract.
19:29
I think the pair-buying tx needs a pair-buy-offer object, like how swapping currently works.
19:31
also, if you are unable to find someone to buy into a contract at the price you want, then paying to put a tx on-chain to make the subcurrency was a waste.

Ideally you should be able to make offers to get into a contract without paying any tx fees.
J
19:32
JOHNwick3's dog
thoughts on UMA Zack?
https://umaproject.org/
J
19:39
JOHNwick3's dog
Thank you, I enjoy reading these and I didn't realize you had something on it yet. thx
Z
19:41
Zack
I think uma were the ones who helped us realize that we don't need to create the oracle unless we need it for enforcement. And that became a really central design point for us.
19:41
oh, maybe not. I can't remember.
Z
21:05
Zack
I made a first draft of the pair-buy tx. it can also be used for a pair of people selling a full set of subcurrencies in one shareable contract to get veo out.
21:07
I guess the only one left after this is for a group of more than 2 making a purchase into a shareable contract atomically together.
William invited William
Z
21:48
Zack
I made a test for the pair-buy tx.
Z
22:21
Zack
I wrote a rough draft of the team-buy tx. the last tx.
MF
23:57
Mr Flintstone
so if tests pass for the team-buy is there anything left for the hard update? besides updating js tools to use the new transaction types
24 July 2020
Z
00:00
Zack
we can technically do the hard update first, and then set up js tools second.
But I think we should hold off on the hard update until we have the light node working well with the testnet for the subcurrency branch.

There is no reason to add tools that no one has access to.
MF
00:32
Mr Flintstone
yeah
EA
00:35
Eric Arsenault
It would be cool if you could have this is such in a way so that many people can pool offers together, and someone can accept any combination of those offers
Z
00:38
Zack
In reply to this message
Yes. That makes sense. It could reduce the number of signatures in the block too.
00:39
I feel like an offer for a swap should also work as an offer for a pair-buy.
00:40
The second person is the one who should decide what needs to be done to match that trade.
00:41
In reply to this message
We have something like this already, but it only supports create account and spend.
We could teach it about these new txs.
Multi-tx I think it is called.
00:43
In reply to this message
I think this only works when you are swapping for the source currency of the same contract.
00:45
I wonder if we are losing the spirit of layer 2 by trying to enforce all these things in layer one.
I guess we need a good launchpad to get into the channels safely.
00:47
In reply to this message
it is probably going to be common to swap between the subcurrency and the source currency for that contract.
So maybe it is worth it.
Z
01:38
Zack
Why do we need swapping instead of atomically linking 2 channels?

It is because we don't want to require both traders to be online at the same time.
But is that really impossible to achieve with channels?

Maybe it is a limitation of a thin market.
And once enough p2p swapping builds up that there is a market with a measurable price, then people will switch to hooking channels together and having single price batches.
MF
01:44
Mr Flintstone
there are similar situations for existing channels, where you dont need both people online. like signing a channel close offer giving you 99% of the channel value when you accept a trade
01:45
which is not even marginally more interactive than doing everything on chain despite using channels
Z
01:56
Zack
"Not even marginally more"?
I don't understand.

You can provide evidence that would work in a shareable contract to do the same thing as the channel close offer.
01:56
The contract could say "either determined by this oracle, or consensual agreement of this list of publeys"
GE
04:55
Gatis Eglitis
Is there a link for working usefull application of veo ?
04:55
What need it covers?
Deleted invited Deleted Account
MF
05:34
Mr Flintstone
here is an mvp for trading binary options
http://159.89.87.58:8080/trading.html
mx
17:02
mr x
how long are the offers valid?
Z
18:59
Zack
In reply to this message
You choose the expiration when you make them.
You can cancel existing unmatched orders by making an unrelated tx to increment your nonce.
mx
19:00
mr x
yeah i was asking about the the trade explorer
19:01
you can also constantly keep creating new order with expiration one block further?
Z
19:01
Zack
I think he has a bot that publishes new offers every block. The expiration is 1 block.
19:01
In reply to this message
Yes
19:02
Offers don't go on chain until matched, so this is free.
mx
19:02
mr x
yup
19:03
nice
Z
21:14
Zack
I made a test for the team buy tx. that is the last one.
Next ill make some more tests, mostly to act as examples for how to use these new tools.
micropayments, 2 of 3 channels, binary and scalar betting using oracles that haven't yet been created, hashlocking.

After that ill probably be working on updating the light node for the new way of doing channels.
MF
21:16
Mr Flintstone
In reply to this message
i think i set it to like 4 or 5 blocks right now
21:16
probably makes sense to be able to customize it, we can add that once we do the subcurrency overhaul for it
mx
21:26
mr x
maybe always make 1 block and renew :P
21:27
if bot goes offline so does all bets
21:29
make free option as small as possible
J
22:00
Josh
In reply to this message
Awesome progress!
MF
22:01
Mr Flintstone
In reply to this message
there are also other options to mitigate free options
22:03
faster blocks reduce variance and also make it much harder to exercise a free option because it becomes a coordination game to reorg the blockchain to take the free option if a trade expires every 10 seconds
22:04
you can also do forward starting in the offer. So if someone put a bet out that did the price change from 1 hour from now until 25 hours from now
Z
22:42
Zack
It is very convenient that Chalang already supports a merkelized abstract syntax tree.
The ID of a chalang function is that hash of that code.
The hash of the code is what you write onto a smart contract for how it expires.
the hash of the code is what a contract returns, if it is being converted into a different contract.
22:43
I made a test of micropayments.
22:43
I had to write the 2 of 2 multisig contract in chalang to make it work.
22:43
the 2 of 2 is over a function ID
22:48
the alternative way of defining function is convenient for embedding bits of chalang into tests.

def dup * ; Square !

like this. def leaves the function id on the stack after defining the function.
22:55
https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/test_txs.erl#L2129
I guess this is the state channel. 27 bytes of contract code with a couple addresses embedded in it.
22:57
Chalang doesn't support list syntax, so I am always including macros for that. haha
23:03
oh right, we still want a tx to batch accept multiple open offers.
Z
23:51
Zack
@Jbreezy0 suggested a feature for automatically swapping your winnings from a market if you win.
I made a test to show how this works with the new way of doing smart contracts. https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/test_txs.erl#L2208
25 July 2020
Z
00:02
Zack
this is lots of tests.
I think next up is integrating the new channels system into the light node.
00:07
previously we only had new channel offers.
Now we need to deal with both pair_buy_offers and swap_offers.
Z
00:27
Zack
the light node tools for p2p derivatives seem to be getting pretty big.
I am thinking I should take this opportunity to identify the major data structures being used, and create some modules for dealing with them specifically.
So I can try and write the website from a more appropriate kind of language.
00:28
we should really use some files to organize all this js. haha
Yok Yak invited Yok Yak
Ak invited Ak
T
10:28
Topab
Interesting. I think it is expected that building fair staff and leave it to participants can work. Could some Dapp like this been built in Amoveo? https://insights.deribit.com/market-research/yfi-a-tale-of-fair-launch-governance-and-value/ I know you can't create tokens in Amoveo but perhaps there is a mechanism where dapps are created in Amoveo with the principles of fairness that could drag users into it
10:40
From 0 to 3000 in weeks
mx
11:28
mr x
separating html and javascript sound pretty good xD... currently the api calls and ui updates are mixed pretty crazily??
T
11:42
Topab
Seeing similar game theory plays in Amoveo would be nice https://twitter.com/LongShortFundin/status/1286860129246179331?s=19 Do you have any opinion on this Zack?
EA
12:22
Eric Arsenault
@pgonza are you thinking something like: place bets and receive VEO?
T
17:02
Topab
Not sure because for me all this defi stuff is something I can't fully understand. I was thinking of the possibility of building a Dapp or a platform on top of Amoveo that could have similar properties as in the article describing the explosive success of yearn.finance. If that could be built I think it could attract lots of people to it, hence to Amoveo
T
18:05
Topab
https://tonysheng.substack.com/p/yfi-ponzinomics This explains how the yearn.finance works to increase its price non stop. Don't miss understand me, I don't intend anything like that for Amoveo. Just looking at how it has been done and if from a game theoretical perspective some alignment of incentives could be created in an Amoveo Dapp
T
18:27
Topab
That's true but the case for yearn.finance is very particular
Z
18:41
Zack
In reply to this message
Makes sense.
18:45
In reply to this message
I don't see any technical innovations in this project, or any product at all.
Looks like they are good at marketing.
Basically, it is an advertising firm with a ponzi scheme.
18:47
A basic concept to remember with finance is that it is zero sum.

Some people are willing to take a small expected loss, if it means that they can get rid of a risk.
Others can take a small expected profit because they are able to handle more risk.

If you don't know who is taking the expected loss, then it is probably you.
18:48
A ponzi scheme like this is tricking users to take more risk and an expected loss at the same time.
T
18:55
Topab
Isn't it a game theoretical way of providing liquidity? I see it that way
Z
18:59
Zack
In reply to this message
If there was someone gaining liquidity, why don't they mention that in any docs you shared?

Ponzi schemes aren't new hype on ethereum. They are continuous.
19:06
looks like ampleforth is yet another central-bank style stablecoin. A one-size-fits-all system which forces some users to have smaller security margins than they would prefer, and forces other users to buy bigger security margins than they would prefer.

Their core innovation is that they regularly change the number of satoshi's per coin, so your account balance changes even when you don't make payments.
Hard to call this an "innovation", since it is a misfeature, it only serves to make the product worse.

I feel like most of the defi projects today are like a magician.
They put on a show and try to redirect your attention so you don't notice them taking your wallet.
19:10
In reply to this message
What does "gaining liquidity" even mean anyway?

One of the ways a person can participate in financial markets is as a market maker.
The market maker locks up a bunch of money into open trade offers on both the buy and sell sides of the market.
Market makers profit if the price moves up and down a lot, but always returns back to where it started.
Market makers lose a lot of money if the price moves far in either direction and does not return.

If a financial product is being used to power a market maker, they need to be very specific about which market it is making. They should provide you with numbers for how much profit you expect to gain/lose depending on various market conditions.
19:11
In reply to this message
read my next sentence.
By "central bank", I mean it is on-size-fits-all.
Customers are forced to have security margins which are not customized for their needs.
19:12
central banks fail because they have a one-size-fits-all monetary policy for an entire country.
Even though every individual in that country has unique financial needs.
Z
19:51
Zack
I think we are getting rid of almost the entire spk.erl library.
we only use spk:prove_facts for the new channels, and it is a small pure function.
Z
21:04
Zack
There were a couple places where the test version of the light node had stopped working.
the format of channel ids had changed for example.
I updated it so it is working again.

I identified a bunch of javascript code that we are no longer using, and will stop working because of how channels are changing.
So I will be removing that, and rewriting the parts we do use for the new channels.
Z
21:43
Zack
https://github.com/zack-bitcoin/light-node-amoveo/pull/12
Here is the pull request that removed around 2000 lines of dead code.
21:44
This code was channel intensive and would have been difficult to translate for our new channels.
Now we can focus on translating the parts that we actually use.
Z
23:59
Zack
im working on a test in the full node.
It is for a binary derivative contract.
26 July 2020
Z
00:33
Zack
If a smart contract has a clause like "if both these accounts sign, then we can run an arbitrary function", that makes the smart contract work like a channel. Users are afraid to own subcurrency in this contract unless they are in the list of pubkeys that can sign to run an arbitrary function.

If the smart contract doesn't verify any signatures, then it works like a shareable contract. Users all know how it will run, so anyone can own subcurrency in it.
00:40
I wonder about the in-between cases.
Like if the owners of the channel can sign away their ability to make further updates.
Z
02:20
Zack
As long as the channel type contracts are on shorter time scales than the shareable type contracts they resolve to, it makes sense.
Peter invited Peter
P
12:37
Peter
It's been a while since I've been in here. I glanced at GitHub, but are there any medium article or ways a non tech guy can get caught up on the direction here? Hope everyone is well.
P
21:01
Peter
In reply to this message
Thanks Zack
27 July 2020
P
03:13
Peter
Is qtrade still trustworthy? Or is there a better exchange? A1 still around?
Jully Jones invited Jully Jones
Z
04:12
Zack
In reply to this message
Qtrade has been working reliably as far as I know
P
04:17
Peter
In reply to this message
Great, glad to hear that
Deleted invited Deleted Account
14:29
Deleted Account
Hello administrator, suggestions on project listing cooperation. Who should I talk to?
S
16:31
S
Check this out
Not really familiar with Solana, but interesting narrative for the coin

https://t.co/wqYyF8Ba05
Z
19:12
Zack
In reply to this message
processing txs in the gpu is interesting.
I think there have been other projects that offload signature verification to the gpu before this one.

Im not seeing any innovations we can copy from this project. It seems like a Cosmos rewrite in Rust.
S
19:13
S
Their partnership with FTX and communication approach is what's most interesting IMO
Z
19:14
Zack
In reply to this message
this looks like a scam to me.
They are talking about cross chain atomic swap tech, which is important and will be more important in the future.
But then they want to sell a token, which doesn't make sense for a swapping tool.
They have a big roadmap full of stages that don't make any sense for the goal of cross chain atomic swaps.
Z
19:33
Zack
In reply to this message
this is a very long document.
searching for "cell architecture" isn't helping.
What is the innovation that you think we can copy from them?
19:35
Amoveo supports state channels.
19:37
UTXO vs accounts vs cells.
I don't think there is any difference from the user's perspective. they are different formats to store the same information.
19:37
I don't see how cells are different from contracts on ethereum.
19:40
In reply to this message
I don't understand why you are bringing this up.
If there is some actually useful tech we can copy, then it is ok.
But I am concerned you are doing this to spam this channel.

Same with the post about solana above.

You guys should only reference other projects if it can help Amoveo somehow. This channel is about building Amoveo. it is not a place to spam advertisements.
S
19:42
S
Well, I was pointing out that a crypto project has partnered with a major derivatives exchange.

Pretty relevant to amoveo if u ask me, but ok..
If you prefer to keep this channel mostly tech talk, that's perfectly fine!
Z
19:45
Zack
If a project is using their funds to pay for press releases and partnerships, instead of paying to build the product, I take that as a bad sign.

Ponzi schemes use their funds to advertise.
Legitimate projects use their funds to build.
S
19:46
S
You're certainly right Zack

But good tech alone doesn't make a project succeed
Z
19:48
Zack
Tech doesn't matter.
Partnerships don't matter.

The product matters. User experience matters.
S
19:48
S
Couldn't agree more
Product above all
Ankit invited Ankit
feri khaidir invited feri khaidir
Z
22:43
Zack
https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/test_txs.erl#L2272
Here is a passing test of making a state channel, putting a binary derivative contract into it, moving that derivative on-chain into a subcurrency, using the oracle to enforce the outcome, and converting the winning subcurrency into veo.
22:47
https://github.com/zack-bitcoin/amoveo/blob/subcurrency/apps/amoveo_core/src/consensus/txs/test_txs.erl#L2359
This part is kind of tricky.
I had to make a smart contract that does nothing besides defining a function that is the other smart contract.
Z
23:46
Zack
So what processes exactly do we want to support for trading in the light node? We have a lot of flexibility now.

One idea is to make a pair-buy offer, to create more subcurrency in a contract, and simultaneously make an offer to sell your winnings, if you win, and publish this all somewhere, and then you can go offline.
If someone accepts your trade, and you win, then you end up just holding veo, or your prefered subcurrency at the end. you don't have to come back online at any step.

So we need:
* an interface for making and publishing these offers.
* an interface for accepting these offers.
* an interface for swapping veo for winning subcurrencies to let people withdraw early.
* an interface for trading in winning subcurrencies for veo, once the oracle has expired.
23:47
I think this will allow us to re-write the p2p derivatives tool for the subcurrencies.

Once that is working, we can do the hard update, and then start making a single-price batched market.
23:55
The early-close system doesn't need to exist, because swapping out with your original partner is the same as swapping out with anyone else.
23:55
A tool to combine subtypes in a single contract to get the Veo out is probably important too.
28 July 2020
MF
01:02
Mr Flintstone
maybe we can spin up a testnet to go through the life cycle as well
Z
01:36
Zack
You could also do the life cycle on a test node
MF
01:41
Mr Flintstone
probably need to test storing trade offers & swap offers on the server / pulling as well?
01:41
so maybe test node is less straightforward
EA
02:17
Eric Arsenault
In reply to this message
What if you received subcurency automatically when you placed a bet?

Also, how will you see your subcurrency balances?
MF
02:18
Mr Flintstone
In reply to this message
what do you mean by this
Z
02:18
Zack
In reply to this message
There needs to be someone on the other side of the bet
ŽM
02:24
Živojin Mirić
When I get dividend?
Z
03:02
Zack
In reply to this message
yeah, we need some way to see subcurrency balances in the light node.
EA
03:04
Eric Arsenault
Maybe I have this wrong
03:05
Can you get the subcurrencies before the oracle has resolved?
Z
03:05
Zack
Yes
S
03:06
Sebsebzen
Will you review Augur 2 when it comes out this week? @zack_amoveo
EA
03:08
Eric Arsenault
Do you get a subcurrency automatically when you accept a bet? Or do you need to do something to trigger that?
Z
03:09
Zack
In reply to this message
It can work either way.
You can make a state channel first and have rules for how to update it to the bet.
Or you can make the bet directly.
03:10
You can get subcurrency immediately when you make a bet, yes
EA
03:12
Eric Arsenault
Ok nice. Will these subcurrencies be displayed in the wallet? Would you be able to sell you subcurrencies in the same interface you mentions "an interface for making and publishing these offers."?
Z
03:14
Zack
Yes, we will add some tool to show your balance in subcurrencies.
Yes there is a tx type for swaps between arbitrary pairs
03:14
It works the same way as contract offers currently work
MF
03:15
Mr Flintstone
is it cheap computationally to be able to show all the subcurrencies in your account? versus needing to input some data. im thinking of how with some ethereum wallets, you have to input the contract address of the token you care about to see that subcurrency’s balance. would be nice to avoid that issue
Z
03:16
Zack
We probably need something like a contract address.
EA
03:18
Eric Arsenault
In reply to this message
I agree, it's a pain
03:19
Maybe you can "add subcurrency to your wallet" within the UI?
03:19
probably want to make keeping track of all that easy
Z
03:19
Zack
How about if you could save contracts in your watch list.
03:20
And it automatically checks those listed ones
EA
03:23
Eric Arsenault
What if it just automatically saves any contracts that you have used to your watch list?
MF
03:25
Mr Flintstone
isnt your sub-currency balance on chain though? like in a sub account tree
Z
03:36
Zack
In reply to this message
That could work
03:37
In reply to this message
Yes. One option is the light node downloading the entire list of contracts, and checking if you have a balance for each one.
Or downloading the entire list of sub accounts, and looking up all the ones you own.
MF
03:42
Mr Flintstone
maybe we could do something with how channel offers are already being stored on the server
03:43
since i think, even if you know you have some sub-account balance, you may not know exactly what it is without the hash preimage?
03:43
unless the light node knows about it
Deleted invited Deleted Account
Z
08:28
Zack
In reply to this message
You just need the contract ID and your pubkey to check.
Yeah, we probably could store something on the server to make this simpler
Z
19:28
Zack
so we aren't going to use any of this sub_channel stuff. I am deleting it all.
Z
21:31
Zack
https://github.com/zack-bitcoin/light-node-amoveo/blob/master/src/js/contracts.js
This time I am starting off by making good data structures for our smart contract offers.
29 July 2020
Z
00:29
Zack
I found a bug that was making headers sync slowly in the light node.
It was logging something to the console for every header.
I fixed that, so if you update your light node, it should sync faster now.
Z
01:49
Zack
I made some sample html interfaces for creating and displaying the new kind of contract offers.
01:49
on the contracts.html page.
B
14:26
Ben
In reply to this message
What didn't work? What was the takeaway?
C
15:49
Callum Wright
looks like Augur v2 is quite unusable due to ETX high fee atm
S
15:52
Sebsebzen
In reply to this message
UI is nice tho, just copy and use with Amoveo as backend
Z
16:58
Zack
In reply to this message
It works fine.
But the shareable contract system we also built turned out more powerful than we had expected.
It also works for state channels.
So we have no need for a separate state channel system.
Z
20:10
Zack
I am going to make a bunch of mini tools in js on the new contracts.js page to show that all the new features work, and to act as examples on how to use them from javascript.
Z
20:30
Zack
looks like our matrix format isn't compatible with the json encoding we are using.
20:31
I think we just need to change the bits of binary into integers and it will work
EA
22:11
Eric Arsenault
I was thinking about how other projects whitelist trading pairs that people can trade in. Would it make sense to do something similar with Amoveo, instead of giving people complete freedom to do anything they want on the front end?
22:11
Main benefit being usability I think
MF
22:53
Mr Flintstone
the trading MVP does this
22:54
In reply to this message
Like this
22:54
and then the UI recognizes it is in this format, and translates it to simple english
EA
23:07
Eric Arsenault
Yeah, that works. I guess I mean only having certain trades available, and adding them one at a time. For example: LONG VEO, BUY STABLECOIN
23:08
Then within these, you could set up your offers
23:08
Then, we could add LONG BTC or something
23:12
Then you would only need to pick your date, and price
30 July 2020
MF
00:44
Mr Flintstone
check out the create tab of the trading.html
00:44
is that kind of what you are describing?
EA
00:56
Eric Arsenault
I'm not sure, below by wallet I just see http://prntscr.com/tqo9xa
MF
00:57
Mr Flintstone
at the top, there is a create link
00:58
maybe could make it less busy up there
EA
01:00
Eric Arsenault
:/ yeah
Deleted invited Deleted Account
EA
01:04
Eric Arsenault
Yeah I guess this is OK for now, we can always change the UI once there are too many trades and we need a better way to view them
CD
04:15
Crypt Dweller
I like what Eric is thinking.. Make it so simple that apes could figure out how to use it and press the 100x-leverage-long-VEO button
J
05:04
Josh
All the js tools will be available so it will be easy for anybody to create their dream UI.
EA
08:52
Eric Arsenault
🤦‍♂️
MF
09:10
Mr Flintstone
it is unfortunate that they keep running into roadblocks. interest in this type of thing is good in general i think. especially with how information & rhetoric has been weaponized these days
EA
10:04
Eric Arsenault
Yeah, I would agree
C
10:57
Callum Wright
I think Flux approach to use Near + Ethereum bridge is good
11:00
In reply to this message
as long as it's opensource somebody can always takeover the UI part
MF
11:39
Mr Flintstone
maybe we can use the existing low budget UI to bet that a better UI wont be built
mx
11:44
mr x
I like the idea of rewarding people who do good things for the network after the fact.
11:45
they dont need to announce anything
11:46
they are not constrained by some initial specification what to do
11:50
rokos basilisk style
11:53
In reply to this message
this is good too i would participate
11:53
as betting it wont happen lol
CD
12:07
Crypt Dweller
That's actually brilliant Mr Flintstone. I would totally bet on it too, and with enough collateral tied up, some enterprising dev will take advantage of our casual pessimissim
12:09
How do we define what qualifies as better UI? What if they make it look different but not necessarily better?
12:10
Speaking of Roko Basilik, I could see Amoveo picking up interest from the Less Wrong/Star Slate Codex/Gwern crowd once it the MVP comes out
12:11
It's simply an inherently compelling idea that will appeal to people looking for elegant technological solutions to social problems
12:14
I am so curious what Amoveo will be like in 2 years. It took 2 years to get to where it is now, and it seems like many of the hardest initial problems are solved
MF
13:08
Mr Flintstone
In reply to this message
i think maybe the way to do this would be to bet the price goes down
mx
13:13
mr x
hmm yea good idea
13:16
price given SOMETHING gets done?