09:14
Zack
=============
so, this "potential winners" database we want to add in the consensus state, it seems really complicated.
Like, way worse than the order book's linked list for the open orders, and we had a lot of trouble with that.
09:16
for every potential winner there can be multiple layers of sortition chains in their proof that they won.
for every layer of sortition chain, we need to remember a priority height as well as a list of pubkeys of accounts assigned to collect evidence for when users give up ownership of parts of that layer.
09:18
and hopefully we can build this using only our current merkel tree database library, even though it is only for fixed-sized datastructures.
09:19
the way the order book in the oracle works, it is like a linked list. every order is it's own entry in the merkel tree, and it points to the next entry in the ordered list.
09:28
so maybe the merkel trees will be:
potential_winner_root
potential_winner_layer
potential_winner_spent_proofs
so, every pw-root will point to the next pw-root in the linked list. it is ordered based on priority.
and the pw-root also points to a pw_layer.
the pw_layers are a linked list, each pointing to the next. they are ordered based on the order of the sortitoin chains inside of each other. and the pw_layer also points to a pw_spent_proof.
the pw_spent_proofs are a linked list, each pointing to the next.
each pw_root contains a pubkey of who could win.
each pw_layer contains a priority height for that layer.
each pw_spent_proof contains the pubkey of the account assigned to collect spent proofs into a merkel tree.
09:29
The merkel tree library feels so much like programming with C structs and pointers. Maybe I can build stuff on top to make it friendlier.
09:38
so, before we make a final decision about how to organize this consensus state data, I think we should look at which parts of it the different tx types will access.
We want the amount of data you need to include with a tx to be minimized.
09:47
So, one tx type is to prove that an account owned the winning part of the probability space at a particular moment in the sortition chain's history.
this would create a new pw_root, multiple new pw_layers, and multiple new pw_spent_proof_operators.
The other tx type is to give evidence that one of the potential winners gave up ownership of the winning part of the sortition chain.
You need to prove one pw_root, one pw_layer, and one pw_spend_proof_operator.
09:53
I am thinking we don't technically need to make these all be linked lists. in order to process txs.
But I also want to make them all linked lists, because I am imagining this situation.
If I am supposed to win a sortition chain, but someone else made a proof ahead of me.
I have all the evidence I need to show that they didn't win, but it can be challenging to know which part of the evidence I am supposed to provide to prevent you from taking my prize.
if the consensus state is a linked list, then it is easy for me to verify that I have downloaded all of it, because it is all connected together and I can see if there are any empty links.
if I don't link stuff up, then you need to like look up the historical block and try and figure out what evidence you could need.
09:53
having it as a linked list means that even a light node can keep up. because it is cheap to download the merkel proofs and verify that they link together.
09:54
you don't need to download an entire block.
Deleted invited Deleted Account
12:21
Zack
The other day we were talking about how we can have turing complete contracts to divide up the probabilistic value space, and we can have turing complete smart contracts for when people give up control of part of the probability space.
And we realized that it is better to do it at the step where users are giving up control, because less data gets posted on chain.
Now I have realized that any contract done at the probabilistic division step, it can also be done at the step where users are giving up control.
Lets say I have a arbitrary contract at the probabilistic division step. it divides up some of the value space into 2 mutually exclusive outcomes.
I can make the same division by owning all that probabistic value space, and signing a tx that says I am giving up control of this part of the probabilistic value space, but only in the condition that the contract returns true.
And we can set it up so that if I do give up control, next in line is the person on the other side of the contract.
So this greatly simplifies the sortition chain design. now we only have turing complete contracts in 2 cases instead of 3.
1) for when users want to give up control of part of the probability space.
2) for state channels embedded inside the sortition chain.
It would be really nice if we could find a way to show that case (1) can solve everything for (2), because embedding state channels is going to be a lot of work to build and maintain.
12:34
so, the full power of a state channel can be modeled like this:
Alice and Bob have a turing complete contract C1 that will decide how to divide up their money.
They can work together to instantly swap out contract C1 for any other turing complete contract C2 at zero cost.
12:43
ok, how about we do it like this.
Alice owns part of the sortition chain probabilistic value space.
Bob has an account that is second in the priority queue to own it.
Alice has an account that is 3rd in the queue.
Bob has an account that is 4th.
Alice signs a tx to give up her ownership, but only if contract C1 is true.
Now Alice generates a secret S and hashes it to make the commitment h(S).
Alice signs a tx to give up all of her ownership of the probabilistic value space for her first pubkey, but only if S is revealed.
Alice offers to give up all the value in her second pubkey, but only if the contract C2 is true.
Bob signs a tx to give up all of his ownership of the probabilistic value space for his first pubkey, but only if S is revealed.
Alice reveals the secret S.
This solution has the draw-back that Alice and Bob need to pre-compute a different pubkey for every time that they want to be able to update their channel during a single block.
So if a block is 10 minutes long, and Alice and Bob want to update their contract once per second, then that means they will consume 600 pubkeys each, on average, before they have a chance to set up more pubkeys to be able to update the state channel more times.
12:52
If we want to transfer value in the same part of the probability space more than once per block, then that means the database for the probabilistic value space would need to be able to commit multiple pubkeys for the same part of the value space, but with different priorities, all in the same block.
Which is contradictory with some design goals for this database.
We had wanted a key for the merkel proof to uniquely reference part of the probabilistic value space.
That way we can prove that part of the merkel tree is empty.
12:57
so I guess we need state channels for the use-cases that involve updating contracts more than once per block
13:07
oh, they can do many spends per block, as long as they only spend each part of the probability space only once per block.
13:11
ok, so what is the minimum amount of tooling we need to add to make state channel stuff possible?
13:13
I guess the winning proof is always a chain of sortition chain layers, followed by 0 or 1 state channel proofs.
13:14
maybe the sortition chain being settled should sometiems transform into a state channel. A state channel as they already exist in Amoveo.
15:56
K
it looks like XRP would be around level 2.1 as you would have to spend a large amount of money (some would say in theory inifinite) in order to destroy an amount of someone else's, but you'd get caught.
17:52
Zack
I explained here.
Tim Abcd invited Tim Abcd
19:03
P
did you have a chance to show it to their community?
19:04
Zack
ill post it on twitter soon. im making edits still.
This is your chance to make suggestions before I post it.
19:19
Zack
I made a second draft of this review.
19:38
Zack
I posted to twitter.
21:13
Jon Snow
XRPArmy coming in 3,2,1...
21:13
Zack
Good idea asking about ripple
@K0o0h this is a lot more popular than I had expected.
21:14
about 2% of people who view it do a profile click and are lead to learn about amoveo
Deleted invited Deleted Account
00:42
If u publicly prove them wrong itll prob gain a lot of traction
00:44
A K
wtf XRP still has a following? which year we're in, 2011?
00:46
K
What year are you in? They have one of the biggest
00:46
A K
I'm from 2029, they have none
00:47
Tromp
You could review the cryptoeconomics of hex, richard heart likes to debate anyone. So it would get a lot of exposure
00:48
It is allegedly “programmed to pump” hahaha
05:10
replies to your XRP review
05:12
Zack
It is just people commenting angrily without reading what I wrote.
It is not really possible to have a discussion with someone like that.
05:52
Zack
haha, that guy blocked me
06:05
K
Consider it a good thing you didn’t get to read anything on his website
07:15
Zack
70 profile clicks, zero new followers. haha
I guess it is just XRP people clicking my profile pic so they can block/mute me.
07:17
around 300 people clicked links leading to Amoveo's github.
07:58
Zack
I am looking at people discussing how Mimble Wimble isn't useful for privacy, and I am getting the feeling that we are modeling privacy all wrong.
I think Paul Sztorc is modeling it more correctly
http://www.truthcoin.info/blog/expensive-privacy/Sometimes instead of trying to do a single atomic operation to instantly get 100% privacy, it is more affordable to do tons of small operations that each improve your privacy marginally.
A good model of privacy would give us a formula to calculate the cost in terms of computation, money, and time, in order to achieve a particular sized anonymity set with other transactions.
08:06
In this paper we made a big connection to show that higher security = lower trust = lower fees.
https://github.com/zack-bitcoin/amoveo/blob/master/docs/basics/trust_theory.mdIt is known that if we increase scalability, fees will go down proportionally.
So we have a unified theory connecting scalability, fee size, trust, and security.
Based on Paul's paper, it seems like the level of privacy is proportional to how many txs you can make if you are willing to spend a given amount of value.
So maybe we can roll privacy into our unified theory as well.
If we were able to unify privacy and scalability, then that would mean that sortition chains are the most affordable way to achieve privacy, because they scale logarithmically with the rate of txs.
08:53
Zack
or maybe it could let us reuse some privacy tech for scaling purposes.
09:33
Zack
I am looking at the pedersen commitment database used in Grin.
I am wondering if something like this could be a better way to divide up probabilistic value space instead of the pure merkel proof plan we are currently using.
10:22
Zack
https://github.com/mimblewimble/grin/blob/master/doc/intro.mdThe cut-through part, and especially the cut-through all the way part make it seem like if we used a mimble wimble database, it would be a more natural fit for sortition chains.
With merkel trees we need the one tree to divide up probability space, and a different tree to keep track of spends, and we need operators and servers for all that.
it seems like with a MW type database, it all collapses together into the minimum amount of data we each need to keep track of.
10:23
I think this strategy might prevent us from embedding state channels or smart contracts though.
10:27
oh, we still would need a probability-space operator, to prevent double spending.
10:40
So, for MW, the only way I can imagine doing the RNG is with the uncertainty strategy.
So someone realizes that they won, and then they prove it to the rest of us.
Because the only information each user has is their secret that they can use to verify their balance.
so MW isn't compatible with putting the sortition chain inside of itself.
10:40
so I think merkel trees are going to be the better solution.
Deleted invited Deleted Account
Deleted invited Deleted Account
16:38
P
financial scam ban please
21:15
MKUltra
Is an FPGA still the best miner for Amoveo?
21:18
Zack
as far as I know, yes FPGA is best.
21:22
MKUltra
Do You think there is any rationale for fighting FPGAs in favor of more General Purpose equipment (CPUs and GPUs) ?
21:23
Zack
that would be counter-productive.
21:23
ASIC > FPGA > GPU > CPU
21:23
CPU is the very worst.
21:24
The problem is that the market for CPU power is too liquid. An attacker could rent >50% too easily. Or even use a botnet.
21:24
ASIC is the least liquid, so it is best for our purposes.
21:26
MKUltra
Ok let me ask a different question, do you think switching to an algo like SHA256 makes any sense?
Then acquiring ASICs to support Amoveo mining is easier than needing to buy very expensive FPGAs
21:27
Zack
re-using the same hardware as bitcoin is no good.
Our hashrate is a lot lower than bitcoin.
So an attacker could rent a small subset of bitcoin miners to attack us.
21:28
Every kind of PoW currency needs its own custom hardware.
21:29
MKUltra
So what’s the risk of a Private asic manufacturer making an ASIC for Amoveo and thereby controlling the network
21:29
Zack
our goal is that someone will make ASICS for amoveo eventually
21:30
MKUltra
I think this is currently happening on the Zen Protocol network
21:30
FPGAs can no longer compete and 3-5 Machines control the entirety of the network hashrate
21:31
I assume they are ASICs
21:32
Zack
doesn't Zen Protocol use SHA3. I think some other blockchains use SHA3 as well.
21:32
Why would someone manufacture ASICS for a tiny project like Zen Protocol?
21:33
But still, there’s only one miner that controls the entire network hashrate
21:36
if blockchains share the same mining algorithm, it is not secure.
22:04
MKUltra
That’s a valid point, unless you are the largest network by hashrate
And by largest I mean like Bitcoins hashrate vs all other SHA 256 coins
23:28
Ben
in term of Double Spending, did you ever looked into Veriblock and their Approach to eliminate Double Spendinding by Notarozation?
23:28
in termin of Double Spending, did you ever looked into Veriblock and their Approach to eliminate Double Spendinding by Notarization?
00:49
any questions or suggestions? should I publish the veriblock review now?
00:49
Deleted Account
We can add your coin to buy / sell on our website
Deleted invited Deleted Account
01:43
Deleted Account
Guys in veriblock discord have already commented. Go to main chat there
05:35
J Bluebs
Why do you guys think that prediction markets like auger and amoveo aren’t being used
05:57
Ben
interesting Finding @zack i'm very interested how they respond, post it or maybe try to discuss it in their Discord, usually very good people around there.
07:00
ALGO
I believe you can make a good case for barriers to entry being the two highest factors in the use of decentralized prediction markets that projects like Amoveo and Augur offer. More centralized betting markets may offer better accessibility, such as
predictit.org which has been mentioned here a few times.
09:16
Jon Snow
Satoshi Style
09:19
Zack
Does anyone have suggestions?
Maybe it will be easier to understand if I do it in terms of txs per second instead of txs per lottery.
10:14
Zack
I published a new version of this doc.
I fixed a bug in the formula, and I added an example of using the formula to calculate something useful.
10:18
(blockchain power) = (blockchain security) * (lottery frequency) * log2((size of the privacy anonymity set) * (txs per second) / (lottery frequency)) / (transaction fees per second)
10:31
im having trouble knowing the difference between tx fees vs block rewards.
11:11
Zack
So this means security against attackers who want to modify the consensus rules is the same thing as scalability is the same thing as privacy.
11:21
"blockchain power" is a terrible name. what should I call it?
11:22
It is a number that we can calculate for any consensus protocol, and it tells us how expensive it is to use this protocol vs others, if we configure both of them to have the same security parameters.
11:22
"blockchain efficiency" ?
11:23
with heat engines they talk about "thermal efficiency"
11:23
oh, how about "consensus efficiency"
12:08
I renamed the document to "consensus efficiency"
Deleted invited Deleted Account
Deleted invited Deleted Account
23:47
Deleted Account
Hello
01:17
maybe it is a mistake to tag @VeriBlock when I make posts like this.
I think people from the veriblock community see my post and they don't like it because it is anti-veriblock. So then twitter's algorithm assumes it is uninteresting content and shows it to fewer people.
01:19
I guess I should do the same post a second time without the tag and see if it is more popular.
01:34
I tried posting without the tag, and it doesn't seem to make any difference.
01:36
sanket
writing style comes later after people click on the review
01:36
Zack
Could be.
Maybe I need a better hook at the beginning to draw the reader in.
01:39
9 link clicks out of 300 impressions is not bad.
But 1 like for 9 clicks is terrible.
01:53
oh, I think the data withholding attack works against veriblock even if they embed full headers
01:56
this doesn't happen in drivechain because every bitcoin block can only commit for one side of any sidechain fork. So in drivechain if you withold block data, then the rest of the network will not build on your block.
But in veriblock you can build both sides of a sidechain fork using a single bitcoin block.
02:05
Živojin Mirić
FUTARCHY IS GOD
02:06
This chat is HOLY SPIRIT
02:06
LOUBOUTIN == LUCIFER
02:06
You will come home Lou
02:07
You are the son who left home
02:08
Zack
Louboutin does have a lot of negative comments.
But he also suggested for me to talk to Augur discord that one time, and then the augur team explained about limitations in RNG technology, and this lead to a bunch of great discoveries in how to design sortition chains.
02:22
K
But you still like it
03:00
ALGO
Voicing your concerns in such a negative manner does not lead to any positive developments for the community. If you would like the project to progress in a more positive light, a different approach may be more fruitful. It seems like your main concern is to seek some sort of personal fulfillment from mocking the project and Zack. Not cool Lou :/
03:04
I prefer a slap on the butt and a point in the right direction :)
03:07
Zack
I am not sure if you are right about this.
If people are afraid to talk about the project because they are worried to hurt our feelings, this can prevent us from communicating important information.
He is right that I am writing software more slowly than before, and I think it is helpful to bring this up.
He is also right that publishing open source research is not a direct way to help Amoveo succeed, this is probably a concern that more people than just him have.
Amoveo is a global project. There are people in this forum from many parts of the world. I think we should be tolerant of different cultures, that way everyone feels comfortable getting involved.
03:10
ALGO
It is your perogative to treat his comments as you please and I think you are taking the criticism and using it constructively. Maybe I am wrong and your wonderful attitude has indeed fostered benefits for Amoveo based off of Lou's comments. However, some of the recentcomments were coming off a as quite crude and disrespectful and I wanted to provide a quick interjection
03:10
Zack
============
I do think that the research we have been doing is important for Amoveo's success in indirect ways.
Writing code is cheap and easy.
Knowing what code needs to be written is hard. There is so much propaganda and cultural baggage preventing us from understanding money.
03:17
I think when people use sex as an advertising strategy, it isn't just about having sexy pictures.
You need to cause your audience to think that buying your product will increase how sexually desirable they are.
03:17
it is a great strategy, but I am not sure how to make it work for advertising Amoveo.
03:22
Živojin Mirić
Lucifer is a good character in it's core
03:22
Deleted Account
We can add your coin to buy / sell on our website
03:22
Živojin Mirić
LOUBOUTIN is needed here just as Zack is
03:31
ALGO
To me it seems the fundmentals of Bitcoin spawned the entire cryptocurrency market
03:32
Now, since there are a multitude of projects I can agree with your previous point that new exchanges and an influx of new liquidity will drive the community to expand because it signals value
03:36
Živojin Mirić
I WANT CASH
03:40
we are all like characters in a mythological story, we are all needed in the story so it goes it's way
03:40
this is a great story abtou futarchy
03:41
our grand grand grandchildren will sing songs about the basement
03:41
phoenix from the ashes
03:41
SYMBOLS ARE EVERYWHERE
03:42
that's a good start for every hero story
03:42
kids don't need to know all about the details, Disney will make a movie
03:42
that's 50th time you said that?
03:42
are you a big holder or just dwelling a different basement?
03:46
ALGO
Can we use Futarchy to decide if Louboutin is an asset to this group?
03:56
If you see the price of VEO accelerating with more liquidity would you return with full fledged support and an allegiance to Zack's vision in return for your exponential gains? With your sharp critiques you seem to me as someone who is more into cryptocurrency for the technology.
04:25
Zack
I make mistakes a lot.
Critics are more valuable to Amoveo in comparison to people who give full allegiance to the current version of my ideas.
11:00
Deleted Account
Have you seen the markets? Hardly anything makes 10x anymore. No new money coming in. No retail. No institutional. Just existing players playing musical chairs to try to recover losses.
15:56
but I think if we just let people split the sortition chain up into smaller ones where they own 100%, this can reduce how much we need randomness to the point where the block hash is sufficient.
15:58
well, im glad I waited to build this part.
Deleted invited Deleted Account
Deleted joined group by link from Group
01:39
Zack
So I guess it was a good thing that I wrote this review about Veriblock. Since the conversation with them helped us realize these important facts about RNG.
Thanks to
@jadefalkebtc for suggesting I review them.
01:53
Jon Snow
Maybe we can rebrand Amoveo to be Zack Review Coin (ZRC) and the token utility is that if people want Zack yo review their project, they have to pay the fee in ZRC.
02:17
Zack
When I review big projects, it brings more attention to Amoveo.
When I review small projects, we often learn something useful for building Amoveo.
02:28
I think big projects tend to see my reviews as a threat, and smaller projects tend to see them as an opportunity.
Deleted invited Deleted Account
09:06
Deleted Account
Hi ,
Can I please ask one of the staff a private question regarding requirements and a quote?
09:07
Zack this guys as send me an chat on private it's one from the team ?
11:10
Jon Snow
He is not one from the team. He is the team.
12:12
Zack
I was thinking about a certain line of questioning from the veriblock dev.
And I realized that sortition chains are more secure than we had thought.
To make the baby sortition chain, you don't need anyone from the old list of commiters to cooperate.
The data can be committed in by someone on your new list of commiters.
Because it needs your signature to be valid.
So even if everyone in the current list wants to censor you, they cannot.
Any one of them could freeze all the money currently in their sortition chain. But they cannot selectively freeze some without freezing everyone.
12:33
Zack
Oh, never mind.
You do need one of them from the old list to cooperate.
Otherwise people from the parent sortition chain can't know if money is unspendable because it has been put into a baby sortition chain.
07:40
Živojin Mirić
Yes no maybe I don't care
07:42
they aren't lying about the capabilities of their product, so it is not a scam.
12:54
Zack
So there is this attack against sortition chains that Fernando suggested:
There are a large number of users for a sortiton chain, and all N of the committers refuse to let money get spent, it is all frozen.
An attacker owns a large amount of the sortition value, and is planning to do RNG manipulation.
There is not enough space on-chain for all of us to split off and make our own sortition chains.
12:58
---------------------------
13:10
so lets say the block reward is B, a tx fee is T, and the amount of value owned per user is U, and the total value in the sortitoin chain is S. where U << T << B << S.
if we split the sortition chain into sqrt(S/B) pieces each worth sqrt(S*B), then it is not profitable to attack, and the total cost of fees is sqrt((S/B))*T.
The number of users is (S/U).
so the fee per user is T*U*sqrt(1/S*B).
If the sortition chain is worth 10k block rewards, and the average user has 0.1 block rewards on it, and the tx fee is 0.01 block rewards, then the bandwidth would be:
sqrt(S/B) = ~100 txs of bandwidth.
the fees per user would be T*U(sqrt(1/S/B)) = 0.01 * 0.1 * sqrt(1/(10k * 1)) = 0.00001
which is only 0.1% of how much value that user had.
13:10
I guess this means the bandwidth only scales as sqrt(number of txs), not log(number of txs).
13:13
Since splitting a sortition chain is something that needs to happen on-chain, does that mean we can change the list of accounts assigned as committers?
13:44
Zack
no. because we want it to be impossible to switch out someone else's committers without their permission.
mirza huzaifa invited mirza huzaifa
21:13
mirza huzaifa
What is the total supply of amoveo?
21:14
Is this stable coin, if not I want to invest in!
23:28
Jon Snow
Not a stable coin
23:34
Deleted Account
Unstable coin
23:38
This might be one of his best yet
23:39
His essays were a big part of the reason I first got involved with software.
07:16
Jon Snow
#16 is about oracle
07:20
Živojin Mirić
I have hard time dealing with reality because futarchy exists and amoveo exists but still our government and economy are using inferior systems
07:20
How can I live in this world
07:20
Can someone freeze me
07:21
It's really frustrating when everything moves so slow..
07:22
Tech is years beyond real world acceptance and application
15:54
Instinct
“The idea is that it doesn't matter whether a staker pool is minority or minority, they just need a way to prove that all the other pools are participating in censorship.”
One should be majority ^
21:34
Zack
got it. thanks Instinct
21:39
Lately my strategy for proving the insecurity of mechanisms has followed this pattern.
I describe two different attacks, and I explain how if the security mechanism is able to solve one of the attacks, it will necessarily fail to solve the other.
21:42
This format is nice because it allows me to explain the minimal slice of a project necessary to show its vulnerability.
I wonder if we can come up with a general proof that any time a blockchain has a vulnerability, that it is necessarily possible to prove the existence of the vulnerability using a proof that follows this format.
00:25
Zack
If we can come up with some limits for how complicated an insecurity proof can possibly be, that would allow us to more easily verify the correctness of insecurity proofs.
01:24
Zack
I think the reason my proofs have this format is because blockchain mechanism authors are all making similar logical fallacy mistakes in their design.
They plan on serving a variety of customers, so they set up configuration options to be able to handle all the different cases.
Then when they do security proofs, they only prove each kind of security for a single set of configuration options, not for the entire range of possible configuration options.
So the simplest way for me to show a vulnerability is to choose 2 of the necessary security guarantees of the protocol, and for me to prove that there is no configuration option that simultaneously gives both security guarantees.
Eventually people will learn that all security proofs needs to work for the entire range of configuration options they are proposing, not just a single case. And then my technique for proving the existence of vulnerabilities will stop being effective.
Mr. Wagecuck A.K.A Full Shitcoin Alchemist invited Mr. Wagecuck A.K.A Full Shitcoin Alchemist
Deleted invited Deleted Account
12:38
Deleted Account
Hi friends😁👍👩🦰
13:55
Zack
What if every user who owned value in a sortition chain was one of the committers for that sortition chain.
15:09
it looks like it potentially allows for the blockchain to scale as O(log(number of txs)).
Now that we know sortition chains is only sqrt(number of txs), that means a solution that scales as the log() would be even better than sortition chains.
16:05
Zack
Being aware of the current context increases linearly with the rate that txs are processed.
The CMT database security model requires at least one person to verify each tx. So they can make a fraud proof, if it is invalid. That person needs to keep track of the context. The Merkel root of the current consensus state, in order to know if each tx is valid.
So the CMT database is only a linear upgrade.
It's still super interesting though. I feel like it must have more potential somewhere else.
Deleted invited Deleted Account
17:12
ALGO
Hello :) Welcome to the community 😊
00:19
Zack
So how about if the committers for each sortition chain, if instead of using merkel trees, they used CMTs.
00:22
if you can't find proofs for a random sample of the CMT, then the block containing that CMT root, it is invalid.
00:31
I think this could only work if the CMT root commiter for a block was the same as the person who controls the mining pool that found that block.
That way providing evidence to prove that the block is valid and providing data of any part of the CMT are both actually the same thing. doing one is doing both.
00:41
The advantage of using a CMT this way is that it prevents the attack where one of the committers would commit junk data or refuse to provide evidence.
Previously, any 1 of the N committers could make the sortition chain freeze, but if we use CMT this way, I think that it is not possible to make it freeze.
05:18
check out Vitalik and John's discussion in the comments
08:28
Zack
I think we can do an on-chain challenge response protocol, so you don't have to provide the entire history of ownership of your lottery ticket to show that you won.
Which means we could do lots and lots of vertical payments, without worrying about the on-chain cost. settling is split over multiple blocks.
Maybe we can get rid of horizontal payments entirely, and make it even more like plasma cash.
09:50
Zack
oh, this strategy isn't so good. because the on-chain cost scales linearly with the number of addresses that act as committers.
So we would still need to hire someone to act as a committer for our sortition chains.
10:32
Zack
someone asks:
> how can a committer cause a sortition chain to get frozen?
the committers keep committing the root hash of their merkel tree on-chain.
If they commit 256 bytes of randomness, then it is not the root hash of anything.
So it is impossible to create any merkel proofs.
So no one can know what money was spent in that block.
So no one can know if money being sent to them is valid or not.
11:39
Zack
oops. I was modeling it wrong.
the committers can't freeze it.
If I am going to receive some probabilistic value space, all that I care about is if I have the highest priority of ownership.
If there is someone else who gave up ownership of some part of the probabilistic value space, and I don't know the fact that they gave up control, that doesn't matter to me at all. It could not prevent me from having the highest priority of ownership.
11:40
the only way to make it freeze is if the sortition chain operator and all N of the commiters all decided to work together to make it freeze.
11:41
if the sortition chain operator doesn't cooperate, it prevents horizontal payments.
If all N of the committers don't cooperate, it prevents vertical and horizontal payments.
11:43
that means we are probably ready to start attempting to implement it again soon.
11:50
I guess ill rewrite the sortition documentation again first, to update based on the new stuff we have learned.
12:27
Zack
oh right. committers aren't just committing for when you give up control. they also commit for when you want to make a baby sortition chain.
And it is important to know the time-order if you spent first or made a baby sortition chain first. because whichever was second needs to be invalid.
12:30
that is why just one of them could make it freeze
12:37
maybe I am not dividing up the jobs between the different merkel trees correctly.
shouldn't the sortition chain creator be more symmetric with the other users once he spends most of the money?
12:43
so the sortition chain operator, they are a temporary centralized leader. we are giving them a chance to rule the off-chain state, so we can spend money without needing to pay anything.
If they mess up, then we just need the help of any one of the committers to get the operator replaced with someone we like better.
We can divide up and each go with the operator we like best.
So maybe the committers should only be used for making sub-sortition chains. not for commiting the fact that someone wants to give up ownership of part of the probability space.
13:01
Zack
If we make the sortition chain creator more symmetric with the other users, and stop trying to embed state channels, and we don't change the set of commiters as you go deeper, it gets a lot simpler.
The only operation available is spending.
Maybe it is good to think about this simple model first.
13:05
This model does still offer turing complete smart contracts. Just updating them is slower.
19:09
Deleted Account
Hello, I want to buy token large volume, kindly message me through DM or PM if you’re interested in selling to me (there’s room for negotiations)
19:24
Deleted Account
lol silly kid
20:59
liveness faults are actually really bad in the case of lotteries.
It means if you have $1000 of lottery tickets in a lottery with a prize of $100k, that now you have a 1% chance to win the entire thing, and there is no way to hedge this risk.
21:00
oh right.
Our RNG solution helps here too.
You can split up the sortition chain so you have a 100% chance to win $1000.
21:04
the only people who can't fully hedge their risk are the ones who own less than a tx fee worth of value in a sortition chain.
21:13
If many sortition chains all had liveness issues at the same time, then the price of a tx fee could increase.
21:23
If there is a 1 week delay for people to provide evidence to sortition chains, then if all the sortition chains had liveness attacks at the same time, there is only 1 week worth of blocks to provide evidence for all the sortition chains.
If we have D blocks per day, and can provide evidence for N sortition contracts per block, then only the N*D*7 richest sortition contracts would be fully hedged.
Approximately 50 000 contracts based off of how scalable Amoveo currently is.
21:31
If we wanted to support $1 trillion worth of derivative contracts, and only the 50k most valuable contracts were enforceable without lottery risk, then it seems like anyone with a contract worth less than around $1 million will need to deal with lottery risk.
21:55
Zack
A problem with normal merkel trees is that liveness attacks can happen on parts without happening against the entire thing.
If we use a coded merkel tree instead, then a liveness attack is all or nothing.
If a liveness attack is happening, then we can all verify it is happening, even though we can't have anything on-chain to detect it deterministically.
If a liveness attack is happening, then all of the money is frozen for a period of time.
If all the money is frozen for long enough, then that means we can use the no-chain model of consensus. like how they recovered from the DAO hack.
We could do a hard update to swap out the malicious committers for a different set of committers.
22:15
Zack
but that might leave us open to chain splits where they do a liveness attack, and then turn off the liveness attack at the right moment
22:21
Šea
Hi Amoveo community member, if you are reading this and you are member of this community, I just wanted to let you know that you are special, beautiful and worth it!
22:22
You can continue now Zack
22:25
Zack
We could ask the oracle if a liveness attack is occurring at a particular block height for a particular sortition commitment, and then we can do a hard update based on the oracle's result. This way it isn't possible to cause a split.
22:35
Ben
first the oracle need an audience and need to be usable
23:53
Zack
Sortition chains can only work if we have liveness.
I will try to make a mechanism so that even if the committers try to make the sortition chain freeze, everyone gets at least one last chance to sell their value in the sortition chain.
We could have a period of time between when it ends being possible to commit any new information to update the sortition chain, and before we start generating the entropy to decide who won.
So if the sortition chain was frozen, then during this time you are able to prove to anyone exactly what portion of the sortition chain that you own.
So during this time we should allow people to sign an agreement off-chain that says "If I win the sortition chain, I want 100% of the value to go to X".
we can use hashlocking to connect the creation of this agreement to a payment in a different sortition chain, and we can combine it with a safety deposit that you pay.
We can set it up so that if you make multiple of these agreements that contradict with each other, that you will not receive the payment, and you lose your safety deposit.
23:55
This is re-using a trick from probabilistic payment research.
00:01
Zack
> then during this time you are able to prove to anyone exactly what portion of the sortition chain that you own.
That isn't true.
You may have signed something that says you gave up ownership, and that thing might be part of the unavailable data.
00:28
Zack
How about if the sortition chain operator was one of the 2 participants of every payment in the sortition chain.
That way the operator is only able to freeze their own txs, they can't freeze someone else's.
00:35
I guess that falls apart if the operator sells all the value.
Then they could hold customers funds hostage for excessive fees.
00:35
Deleted Account
Futarchy is not mathematically proven. Is it in danger of being hacked?
00:50
Živojin Mirić
Wat is? No blasphemy here
00:51
Zack
Maybe when we commit the Merkel roots, we can do some sort of checksum of the data in the tree to allow users to prove that their money didn't move in a particular checksum, even if they don't have the Merkel proof
00:53
Živojin Mirić
Interesting, I will think about the use of it
01:03
Zack
I'm pretty sure if we make a filter that fails on average for 1/2 of addresses, but succeeds for every address on a list, that the filter only needs to be as long as sqrt (number of addresses in the list).
Oh, this doesn't work because we can't enforce the filter if they keep the data unavailable.
01:08
Part of the problem is that when the lottery finally settles, the protocol to figure out who won is a multi step protocol with different people providing evidence.
This means it is not generally possible for me to prove how the sortition chain would resolve, if it were to end right now with a particular random value.
01:31
Zack
Since any one of the commiters can freeze it anyway, we might as well make each commitment require all of the committers to sign.
That way instead of getting frozen at the data availability step, it gets frozen before unavailable data is ever committed.
So all existing commitments have available data.
Which means the trick we were talking about earlier could work.
Where we give everyone one last chance to sell their stake before the lottery winner is selected.
01:52
Zack
Maybe like a 7 out of 9 multisig. So if a couple of them go offline, it doesn't get frozen.
02:20
Zack
If 9 are signing 1 commit.
Does that mean the bandwidth cost needs to be O ((total number of commiters for all sortition chains)^2) ?
Or can we keep it linear?
05:52
Jon Snow
Are you coming back for thanksgiving?
Zack
05:53
Zack
October 14 was a long time ago
06:31
Jon Snow
Whats oct 14?
Deleted invited Deleted Account
13:33
Zack
The way to make sure data is available is if there are N committers who need to sign it, each one is incentivized to only sign once they have a local copy of the data.
Which is not so different from how the main chain works. All the full nodes download and verify all the txs as a part of block verification
13:36
There is a kind of failure mode where N-1 of the committers have all signed a block, for height H, and the final committer refuses to sign because they want an alternative version of the same block.
To prevent these kinds of failures, maybe we should use something like Tendermint consensus to help the committers agree on what they should be signing next.
04:58
Šea
Zack did you review Kadena?
05:44
Živojin Mirić
Interesting concept
09:36
Zack
I think I found a flaw in optimistic rollups that actually makes it less scalable than bitcoin
11:46
Zack
oh, looks like I was wrong.
23:55
Zack
don't share this review more widely until it is ready.
04:26
Zack
I talked to John Adler, he can't immediately find anything wrong with my reasoning.
What a relief.
04:47
Živojin Mirić
I think you are
Deleted invited Deleted Account
06:25
Deleted Account
I want invest 50btc in veo
06:41
Živojin Mirić
Buy from me fren
06:41
I legit ask community
06:42
Gatis Eglitis
how much veo you give for 50btc?
06:43
Živojin Mirić
I gib ok
06:43
Gatis Eglitis
50btc block = ? VEO
06:44
Živojin Mirić
I appoint my lawyer
06:44
No time for that but my people will handle
10:14
Zack
I think that we can do optimistic rollup inside the sortition chain to better solve data availability.
11:26
After reading all those other sidechain projects, I think I have better language for explaining things.
11:36
Callum Wright
Zack is there anywhere that we can see the current progress of sortion chain? or right now we are still on design phase
11:38
Zack
I programmed some of it in the sortition branch of Amoveo on github, but then the design changed, so I will have to undo some of the software progress.
11:58
Zack
So, there is this idea that posting things online is more efficient at certain times of day, based on who is awake.
But it seems to me, according to the efficient market hypothesis, if this was true, then lots of people would choose to share new info at that time of day, so you would be competing with more advertisers for a smaller slice of people's attention.
So any time of day should be as good as any other.
21:31
Zack
Ethereum 2.0 is planning to have a RNG to assign validators to which shard they are securing.
I bet the financial-security requirements for this RNG are extremely high, like the RNG requirements for sortition chains.
21:37
well, I guess doing a reroll attack on every block only increases the odds of an attack as much as waiting around for twice as many blocks to see if a random opportunity happens. So maybe it doesn't need much financial security after all.
07:59
Jon Snow
What are other features on your Amoveo to-be-developed/researched list besides sortition chain?
Zack
12:30
Zack
The goal of Amoveo is to be the best platform for financial derivative type contracts.
For that we need these things:
* a smart contract system to program the derivatives.
* an oracle system to bring in the data we are betting on.
* the ability to scale for a global audience.
Amoveo's oracle is as good as possible given the available technology today.
Amoveo's smart contract system is as good as we need.
All that is left is to make it scale. That is what sortition chains are for.
13:29
Zack
I think I found another mistake in our RNG plan.
13:37
If we want to have N-fold more security on a sortitoin chain result, and we are dividing it up into tiny sortition chains that all get their entropy from the same block, then we would need to split it up into N^2 different parts.
Our current solution gets 4x as expensive if you double the volume of txs per second, not scalable at all.
14:22
Zack
The next plan I want to explore, I call the "sudoku plan".
The sortition chain probabilistic value space is divided up by each bit of entropy.
So an attacker who owned 1/4 of the total value, they could carefully decide which parts of the probabilistic value space to own to make sure that exactly 2 bits of the entropy completely determine if they win or not. Then they can focus on attacking just those 2 bits.
So to prevent the attacker from being able to focus their attack on any particular bits, we want people who own value in the sortition chain to purposefully choose to own collections of parts of the probabilistic value space such that they are evenly 50-50 hedged for all of the entropy bits that will get generated.
That way, if an attacker attacks one particular bit, they will have no influence on whether you win or not. The attacker would have to attack all of the bits simultaneously to earn any profit, which is computationally impossible, because each additional bit being attacked costs twice as much as the previous.
For this defence to work, we need to show that the contracts to specify how to divide up the probabilistic value space, that these contracts are not excessively long to program.
We also need to show that these additional requirements are not overly onerous for the operators who need to maintain the database of who owns which parts of the probabilistic value space.
These contracts for owning value that is fully hedged, such a contract has a logic to it that is similar to solving a sudoku puzzle, which is why I call this the "sudoku strategy".
14:26
I suspect that these contracts will grow in complexity as (txs per second)^2
but since we can make each individual sortition chain very small, this exponential doesn't matter.
It would be like O(log((# txs)^2))
which is the same as O(log())
15:21
Zack
looks like the new strategy for randomness works!
15:33
Seems like even if the block reward was reduced to a fraction of a penny, it would still be sufficient to provide enough randomness for sortition chains.
15:33
which means PoS blockchains can afford to use the sortition chain strategy as well, by having some insignificant amount of PoW dedicated to generating randomness.
15:34
I guess this means sortition chains now scale as log(
#txs) instead of sqrt(# txs). a massive improvement.
15:35
I wish I had looked into this sooner, it was a lot less work than I had expected and works so well.
15:37
im going to have to redo a lot of calculations involved with consensus efficiency, because this new RNG is breaking limitations of what we thought was possible.
15:43
Instinct
So it prevents the bribery attack in PoS?
15:43
Zack
oh, I think using ranges of pairs of points is no good.
Attacking a range of pairs is only 2 bits, vs attacking a normal range is 1 bit.
I think we need to combine opposite pairs into hedged quads. and maybe combining opposite quads into hedged octals.
15:44
no. this is a RNG protocol. for cheaply generating random numbers.
16:08
Zack
oops. I think it does not work. since we are generating multiple bits of entropy from the same block, interpreting those bits in different ways doesn't make a difference.
16:10
it does prevent the attacker from setting up their lottery ownership so that the first bit is the one that matters most. Solving that part might be a useful step in making a working RNG.
16:20
how about if we generate one bit per block.
16:27
so for example, if everyone is owning octals and if the attacker owns all the state that starts with:
1111 0000
1010 0101
1100 0011
1001 0110
That means that the attacker owns 50% of the probability state.
It seems like in this situation, the attacker would not care what the first 3 bits are.
But once the first 3 bits are known, the attacker has a big interest in the 4th bit, so they would just concentrate their attack on that point.
So I guess that this strategy does not work.
17:29
Zack
so if we use a binary merkel tree to specify the probabilistic value space.
We could paste the top level of that tree on-chain, and draw random numbers, and only walk one step down the binary merkel tree per block.
17:44
Zack
Reroll ing only works if you haven't shared the block.
If you haven't shared the block, people have no reason to participate in the tournament with you. People won't do the tournament for a block until that block has some confirmations.
We can do it like uncertain expiration rng. So one in 50 blocks or whatever has a winner of the tournament who also wins the lottery.
But they need to find out if they won the tournament first before they can find out if they won the lottery.
17:48
Oh, the attacker will just with hold info, so you never find out if you won
23:05
Zack
how about we use time-delay crypto to find out whether you won the lottery at a given block, and we use a true-bit type interface to prove the long time-delay operation on-chain.
23:07
if it takes more than 1 block of time to find out if you won, then you wont know whether to do a reroll or not until it is too late
23:09
if everyone had to run time-delay crypto on every block, that would be a lot of computer power running constantly.
23:10
oh, we only need to do this on one block per sortition chain, so it's not that bad.
23:12
I think we need to do it for a few blocks at least.
If there is a 1/10 chance of exactly 1 winner, then there is a 1/100 chance of 2 winners, and it takes on average 9 blocks to find a winner.
23:12
I guess if we had 1 winner 1/2 the time, 2 1/4 of the time, 3 1/8th of the time, that would be alright
23:13
so each person's odds of winning a particular round would be (1/2)*(portion of the stake that they own).
23:16
looks like some people embed a time-delay element into decryption. that way an attacker can't test as many passwords per second.
So maybe we can reuse some of that math
23:20
the world record processor speed is only like 8.5 gigahertz. Which is only like 5x faster than typical commercial hardware.
So if the average user needed 10 blocks to check if they had won, the best software available would still need 2 blocks.
I wonder how fast an ASIC would be, if it was built for time-delay sha256 crypto.
23:37
I think the average user doesn't need to run the time-delay crypto operation.
We can set it up so anyone can run the time-delay operation, and win a reward for proving who won.
23:40
Since whoever can prove the winner first gets a prize, we will have a good estimate of how long it took to find the winner. So if hardware improves, we will know when it is time to make the time-delay more expensive.
00:37
Zack
If the fastest computer needs 30 blocks of time to know who won the lottery, then an attacker would need to bribe ~30 miners to not publish their blocks. That way the attacker has enough time to calculate what the next block should be to make them win.
So lets estimate the cost of those 30 bribes.
The first one is as expensive as a block reward. Because the miner is forgoing a block reward by deciding to not publish.
The second one would again cost the miner 1 block reward to not publish. But the 2nd miner knows that you already paid 1 bribe. So they know that if they publish the block immediately, the cost to the attacker is 1 block reward. So that means the 2nd miner, they can demand a bribe of 2 block rewards.
The Nth miner would need a bribe worth (1 block reward) + (sum of all the bribes so far)
Which works out to (2^N)*(block reward)
So if we increase the time-delay linearly, the cost to attack the system increases exponentially.
If the fastest RNG computation takes 30 blocks, then the total bribes to attack one sortition chain would be ~1 billion block rewards.
00:39
ok, I think we have finally solved it
00:48
oh, I think it is even more secure than that.
Every time an additional miner finds a solution, you would need to go back and increase the bribes of everyone you had already bribed, and it is impossible for all the bribes to be high enough.
Out of B bribes, the only way for the Nth bribe to be big enough is if it is bigger than the other B-1 bribes put together, which is impossible.
00:52
===========
you can combine each bribe with a safety deposit.
So you only need to pay (block reward)*(2^N).
But the total value of the safety deposits would be N*(block reward)*(2^N), which is far bigger than the total money in the system.
Deleted invited Deleted Account
01:36
Zack
It works if we use a mining pool too. Even if the miners don't know the blocks they found.
The attacker would have to keep paying bigger and bigger rewards from their pool exponentially. Otherwise a miner will mine a block in a different pool to punish the attacker.
03:46
Zack
if we do 10million hashes per second for the time delay function, and we set it up to take 30 blocks, and each block is 10 minutes = 600 seconds, then the on-chain proof to show that you won is log2(10 million * 30 * 600) = 37.5
so the proof has about 38 rounds.
If you have 20 blocks of time to provide evidence for each round, and the person trying to show that you cheated also has 20 blocks, (20+20)*37 = 1480.
So at most, it could take up to 1480 blocks to prove that you won and get your winnings out of the sortition chain.
That is about 10 days, if we have 10 minutes per block.
03:48
if we reduce the block time down to 2 minutes, I guess you would only need 2 days at most to get your money out.
03:54
if a sortition chain is worth N block rewards, we only need log2(N) many blocks of time delay to get the money out.
currently, the market cap is less than 1 million block rewards. So we only need 20 blocks of time of verified delay at most, not 30.
given that a typical CPU can do over 1 million serialized hashes per second, and that we can safely spend 30 seconds verifying each block, it seems like we could safely group up the VFD into bunches of 1 million hashes. Which would reduce the number of on-chain steps by log2(1 million) =~ 20 fold.
combining both of these improvements, instead of needing 10 days with 10 minute blocks, you would only need 8 hours.
03:55
Also, if different people are doing VDF proofs on-chain in the same block, we can verify each in parallel.
So if each one takes at least 1 second, and we have 8 cores, then we can do 8 in 1 second.
Deleted invited Deleted Account
06:26
K
Zack What do you think of creating bets in favor of the users using a small amount of the block reward you get
06:27
If we advertise it as free money it could get a lot more people discovering amoveo
06:40
Deleted Account
Airdrop?
08:09
I guess we need to save like 1 hash per second, that way we can easily re-calculate any intermediate values that we may need when doing the on-chain true-bit protocol to prove that the RNG was calculated correctly.
08:10
1 hash per second, 32 bytes per hash, for 8 hours, works out to 1 megabyte of data.
08:19
oh, 11 minutes * 20 blocks is nearer to 4 hours than 8.
10:23
Maybe instead of doing SHA256 we should do modular square roots. like how RSA works.
10:24
that way it is cheap to verify that the result of the VDF was calculated correctly
10:39
Deleted Account
So? Amoveo is SHA256?
10:40
Zack
the pow is a flavor of sha256. not compatible with bitcoin ASICS.
10:47
Deleted Account
Awww
11:02
Zack
I don't feel confident enough in my modular arithmetic skills to do the modular square root method. I am looking at some papers, and it seems like there are a lot of ways to go wrong.
11:02
using just sha256 is a cleaner model anyway. less dependencies.
20:14
Zack
im thinking we will spend like 4 hours of CPU time to generate the random number for a block, since it is totally serialized. This is a slight modification of the amoveo C miner library.
Then we can use a GPU to verify each second of those 4 hours in parallel. This is a slight modification of amoveo GPU mining software.
20:15
this way verification is significantly cheaper than whoever generates the RNG first
21:00
Zack
I think 1% of my twitter followers unfollowed me this month. I wonder why?
21:03
Instinct
I think a lot of your tweets look the same - a link to your github. On mobile you can’t see that it’s different links every time. Could be reason for lack of engagement
21:04
Zack
so, I should include a picture with each post?
21:04
Instinct
Not sure, maybe or more of an excerpt written along with the link
21:06
Živojin Mirić
most people want quick "hot" info on twitter, not links for dry text on github, you should put pics of furry porn stars
21:06
I am marketing expert
21:07
99.98% of twitter is not tech savvy ok
21:25
Zack
proposed Eth 2.0 tech stack:
PoS, optimistic rollup, stake based shards, smart contracts, DEX, stablecoins, channels
proposed Amoveo 2.0 tech stack:
PoW, lottery based shards, optimistic rollup, channels, smart contracts, DEX, stablecoins
A lot of the tech is similar, but we are layering them in a very different order.
21:27
the big differences are that the sharding and optimistic rollup layers are switched, and how amoveo has channels very deep in the stack and Ethereum has it on the edge.
21:28
Živojin Mirić
you lost me at tech stack
21:36
Instinct
Tweet this
21:37
Jon Snow
Maybe try to tweet the content of your writing in a twitter thread instead of a link to github
21:38
Zack
When people send me comments, I usually want to make changes.
Twitter doesn't allow for editing tweets, but github lets me edit the text.
So there is a trade-off here.
21:39
Jon Snow
You can always add to the thread with correction if needed
21:41
Zack
ok, I will. but not now.
I am pretty sure Twitter punishes me if I make tweets too rapidly.
I tweeted my review of Casper and of Avalanche at the same time a week ago, and twitter only showed each to 1300 people.
My tweet about optimistic rollup 4 days ago was the only tweet during that 24 hour period, and it has been shown to 3000 people.
21:43
I made a tweet less than an hour ago, and it was already shown to 1600 people. but it was my first tweet in like 4 days.
23:28
Zack
Maybe we should keep the rng process 100% off-chain, and use the Oracle to import the result on-chain.
23:31
Živojin Mirić
I don't like that, sounds less robust
23:36
Zack
The advantages would be that there is less on-chain code that could break. Less code to write and maintain.
The disadvantage is that the Oracle takes at least a week to resolve.
Compared to around 3 hours if we don't use the Oracle for this.
01:13
Zack
Does anyone know how fast a typical GPU can mine Amoveo?
I want to know this number to estimate how long VDF verification would take.
01:14
my CPU is doing about 2 megahashes per second. So I am hoping that GPU are at least 100 megahashes.
01:15
that way verification is 50x faster than the original computation
01:27
Beer
1.5 GHs with a geforce 1060 3gb
01:29
Zack
Thanks Beer.
still almost a 1000x speedup. so 30 second verification.
We only needed like 5x speedup for it to be secure.
02:05
Deleted Account
Can someone help me setup the Amoveo C miner
02:05
I opened up the miner.erl file
02:05
Zack
why would you want to do that?
02:05
the readme has install instructions.
02:06
the C miner is like 2000x slower than GPU, and GPU is like hundreds of times slower than FPGA
02:06
are you going to help me make the VDF?
02:06
Deleted Account
Wait where's the GPU miner?
02:06
Zack
yes, and FPGA.
02:07
Deleted Account
I don't see no where
02:07
Deleted Account
Bet
02:11
Sorry to bother yall but I don't see the download for the GPU miner. Sorry im dumb as a carrot 😂
03:01
Deleted Account
Thank you
06:22
Zack
I just kicked out a "Will Draw" for spam, and now another one joins.
08:59
Zack
I think you guys are right. on twitter people don't like links to long precise papers. They want quick TL;DRs
10:54
Callum Wright
I think your last post is good
10:54
the post about Amoveo and ETH 2.0 tech stack
12:27
Jon Snow
quick TL;DRs will lead more people to click the GitHub link
Deleted invited Deleted Account
00:56
Deleted Account
I'll just wait to get miner on my windows pc idk how to build and compile on Ubuntu 18.04
02:48
MKUltra
Hey
Zack I have a brand new CVP-13 w/ RAM here if anyone wants it. I think I saw 38GH using the Amoveo miner on github.
I cannot post pictures but let me know if anyone wants it, we bought it for $6,125.
I have offers on EBay for $5,000 but I’m willing to sell here to this group at $5,000 or even a little cheaper just because I know it will be put to good use.
02:59
Ben
dream on, that card is worth 1.5k max 2K
09:36
Callum Wright
doesn't matter tbh. I can pump the price to 100k sat plus but what's the point. Let the tech progresses/matures.
09:37
Zack
I am so curious. I want to know what privacy is really about.
09:37
maybe there are 2 kinds of privacy, and they are both important? or maybe only one of the two matters?
09:38
Zack
statisticians and cryptographers explain so differently, maybe they can't communicate.
09:38
I mean in a mathematical sense, so we can assess a blockchain's level of it.
09:43
so, about the "proof of space idea"
where they store stuff on massive hard drives to mine.
It seems like if the main cost of mining is in hardware instead of in electricity, then that would mean we would be paying to strip-mine literal mountains, to mass-produce hard drives.
I guess it would be nice if it was cheaper to remember stuff.
Deleted invited Deleted Account
23:15
Mr Flintstone
this will draw fellow sure is persistent
16:12
Crypt Dweller
This guy's recommendations for overcoming the lack of progress in the field of AI reminded me oddly of Zack's philosohical approach to coding Amoveo: "I do not highlight all these philosophical issues because I fear that AGIs will be invented before we have developed the philosophical sophistication to understand them and to integrate them into civilisation. It is for almost the opposite reason: I am convinced that the whole problem of developing AGIs is a matter of philosophy, not computer science or neurophysiology, and that the philosophical progress that is essential to their future integration is also a prerequisite for developing them in the first place. The lack of progress in AGI is due to a severe logjam of misconceptions..."
https://aeon.co/essays/how-close-are-we-to-creating-artificial-intelligence found from Paul Sztorc's twitter feed
19:18
Zack
People have really weird conceptions of "intelligence".
Humans are too dumb to write a programming language like C.
When humans try to write a programming language directly, it ends up being massively inefficient. No individual understands what thinking is well enough to write a good language to do it.
So we write a simple slow language, and then we write that simple language in itself.
Once the computer knows how to read the slow language, and it has an implementation of the slow language written in the slow language, then it can self-optimize and create a massively fast version of that language. A version far more efficient than any human could have written.
We end up with a language written in a way that no human could have written. A language written in a way that no human can understand.
And computer languages have been like this since 1962.
https://www.youtube.com/watch?v=lJf2i87jgFAModern computers are the ones with general intelligence. Humans are so dumb in comparison.
If there is anything a human can do, and that human is also a programmer, then they could teach a computer to do it.
The opposite is not true. Computers can do many things that humans cannot.
The AGI problem was solved in the 1960's, we are just too self-centred to realize.
19:58
Most people who use computers aren't interested in working with a AGI.
They just want a dumb slave that unthinkingly obeys its instructions.
So most programmers never learn how to use the compiling compilers technique.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
21:51
Zack
I think it was important that we made this sortition chain plans, because it proves that we can scale, if we needed to.
Now that we know how to do it, we could even hire programmers to get it done fast when needed.
So let's stop working on sortition chains, and return our focus to product market fit.
21:51
We need to find the first users, they will tell us what needs to be made next.
22:06
mr x
Challenge peoples bullshit or just make bets on twitter with p2p bets.
22:07
use twitter cause everyone can see something is happening :)
22:07
Deleted Account
Tbh I lost touch with the direction of Amoveo a long time ago. It was prediction markets in the beginning, right?
22:09
mr x
every veo user should have comfortability with making/accepting/closing p2p bets
22:11
Its more like proof of review coin at the moment
22:11
mr x
how many of you can even make p2p bet?
22:11
you can make oracle wihtout posting onchain!!
22:12
Deleted Account
No clue 😁
22:13
with couple of clicks you can make bet about any topic without censorship!
22:16
Deleted Account
Also, it would be great if I could use Tether or BTC to make bets. I know that's a whole different story, but honestly, I don't really want to bother with running exotic wallets. So I'm thinking what if I could send Tether to be locked in some smart contract and get back Tether if I win a bet?
22:17
mr x
just use veo and gamble while u gamble
22:17
this is how we bring in people first
22:17
forget venezuelan oil farmer insurance for now
22:20
Deleted Account
That's the problem. Veo is so illiquid that it's not even possible to make big bets or to cash out big winnings. But as I understand, it's quite advanced in the logic. So make a gateway for ERC20 tokens and BTC and lock funds for the duration of the bets. Veo can run in the background taking care of the logistics and even take fees in the coins used for the bets
22:21
Zack
maybe we want sortition chains first so that we can have single price batches without needing the market operator to lock up capital.
22:22
I think we can get lot done just focusing on 1-1 p2p betting
22:22
Deleted Account
Ok, I don't understand the science behind this, but the market operator shouldn't really be forced to lock up capital.
22:22
mr x
p2p betting + twitter
22:23
Zack
that is the most private way to bet too
22:23
mr x
veo user make bets with each other on twitter to fake it till we make it
22:23
challenge bullshit with p2p bet on twitter
22:23
Zack
currently we are using state-channels. so everyone makes a channel with the operator. everyone needs the ability to win money in their channel. so the operator needs to lock up money in all the channels.
22:25
we want to make the next world reserve currency. The biggest prize.
Derivatives are the most popular use-case for currency, so we think that if we are the best at derivatives, then we could have a good chance to win.
In order to have a good system of derivatives, it needs:
the ability to atomically update many things, for single price batches, to prevent front running.
and oracle
to be very scalable.
22:25
we use state-channels to connect contracts to prevent front running
22:25
we have a great oracle
22:26
and now we have a plan to efficiently scale.
22:26
I think we are headed in the correct direction.
22:31
I did a lot of reviews, and it helped us come up with a bunch of ways to improve Amoveo.
A big example being the ability to bet in an oracle that does not yet exist.
This makes bets significantly cheaper, because the oracle was the most expensive part.
22:31
another important thing we discovered. It helped us come up with a plan for scalability
22:32
We are too small of a community to have enough creativity to solve everything on our own. We need to take in other people's ideas.
22:34
Deleted Account
I'm quite sure that you have advanced tech. How about considering a theory, that for adoption's sake, it would be orders of magnitude easier if the average Joe could make bets in currencies that are the most widely adopted and available. Because having to buy an illiquid coin to make a bet and then also having to sell it on the way back would almost definitely end with losses on spreads.
22:35
Zack
yeah, a tool to automatically keep you hedged against BTC or USD would be cool.
22:35
Deleted Account
Yes
22:36
mr x
what would be cool is amoveo user familiarising themselves with making p2p bet
22:36
Zack
I wonder what is the cleanest interface for people to explain what risk profile they want
22:36
Deleted Account
Are time locks like the ones used in atomic swaps any possibility?
22:36
Zack
yes, amoveo state channels support that.
22:37
they are turing complete contracts that can calculate hashes, and know the current block height.
22:38
mr x
I was trying to make twitter bot that people can use to advertise their p2p bets
22:38
Zack
just link them to the explorer for p2p bets
22:38
Deleted Account
So let's say I'm an average Twitter Joe with ERC20 Tether and some BTC in my wallets and I see a stupid bet on Twitter that I want to take. I click on a link and
the.best way for me would be if there was an address where I would have to send my coins if I wanted to take the bet.
22:39
there should be standard way to challenge someone
22:39
Deleted Account
You have to approach this from the stupid user's perspective. That's the only way to do UX
22:41
mr x
if you just sent the link to the bet the bot would verify and display info in standard format
22:41
Deleted Account
For example we have a perfect bet scenario with the upcoming Ethereum fork. There could be so many outrageous bets
22:42
Can Amoveo do wrapped coins, for accepting "alien" currencies for bets?
22:44
mr x
and the bet should have the oracle included in it
22:44
no seperate checking that oracle matches id
22:52
Deleted Account
Are there videos on how to make bets, accept bets and how to do different things with Amoveo?
22:53
What defi app is actually uncensorable in Ethereum?
22:55
mr x
eth is just multisig oracle shitshow
23:00
Deleted Account
If someone puts up .1 BTC for a bet saying BTC will close above 7700 USD today, can I accept that with only a partial bet for proportional winnings? So I only put up .05 for example
23:01
Zack
only if they post 2 small ones
23:01
and then you need to pay for 2 channels, if you take both
23:01
Deleted Account
So it has to be 1:1 for the contract to come into effect?
23:01
Zack
no, you can bet at whatever price you want
23:02
as long as both parties consent
23:02
Deleted Account
Sorry if my wording is incorrect, I'm not familiar with the adequate vocab
23:02
Zack
like, if we are betting on something unlikely, you might need to put up only 1/20th as much money as me for it to be fair.
23:03
mr x
you make the bet and then it is accepted as specified or not at all
23:05
Deleted Account
Also, can I sell my bet if i changed my mind?
23:05
Zack
if you spend some coins, it will make your account nonce increase, I think that invalidates them, but let me double-check right now to be sure
23:10
looks like spending to yourself doesn't invalidate it. but I think I can add that feature.
23:12
I will look into this more.
23:13
but it seems like it should be fairly easy
23:13
mr x
but then other bet proposals would be invalidated by making one bet too?
23:14
Zack
no, having your bet accepted wont increase your nonce
23:33
Deleted Account
First of all we need lots of short screencap videos showing the features
23:33
Zack
videos or GIFs?
23:34
oh narration. so a video
23:34
I can try making something like that to see how it goes
23:34
Deleted Account
No GIFs, videos with someone explaining what goes on. And preferably with 2 narrators. One noob and one expert. The noob has to be well versed in online betting
23:35
Zack
what should I cover first? making a new account and receiving your first veo?
23:37
Deleted Account
Yeah that too, but let's approach this from the gambler's perspective. How can I make bets, accept bets, what crazy features does the system offer, then always some commentary on how it is different and maybe better than other competing systems like Augur and others.
23:39
Zack
makes sense. we could try something like that.
23:40
Deleted Account
Lots of big CT personalities also gamble on sports and politics. The next step in the video series could be inviting those guys one by one and showing them how it works and they could provide with input that maybe you didn't think of.
23:40
And it's also great marketing
23:41
Stuff will come up like how operators are also market makers, how you can make money as an operator, etc.
23:44
Most important thing about the video is to have a good mic. 😁 It really is.
08:18
Deleted Account
I liked this one. Thanks for sharing. It's cool that PG is writing again.
08:19
Have any of his other essays influenced you, or your work on Amoveo?
12:21
Zack
How about I bet that no one can make a VDF calculator that is more than twice as fast as this one, within the next month.
17:11
Zack
I only wrote the CPU calculator. I did not write the GPU verifier
17:12
but the code is rather short, I think the gpu verifier will not be too complicated.
Deleted invited Deleted Account
04:13
Crypt Dweller
really great stuff from coinspeed and mr. x. Maybe make a DAC for them to create the how-to videos after they've versed themselves in the technology more?
04:34
Deleted Account
I think I'll put together one (or more) scenario(s) on how I imagine ideal functionality regarding features that I'm interested in. The purpose of this is to approach some ideas purely from the user's perspective. If it makes sense to a few of us, then Zack can evaluate what is possible, how it could be implemented. And if my approach proves to be useful, we could make more of these.
04:39
First question: do you guys want this at all? 😁
04:43
Zack
It is worth a try at least
04:44
Deleted Account
Ok, I'll give it a shot then.
05:55
Zack
One limitation with videos is that they can be difficult to update when the user interface changes
Deleted invited Deleted Account
13:13
Deleted Account
Management in?
Deleted invited Deleted Account
22:23
ALGO
Feel free to DM me or
Zack
05:55
Deleted Account
100 is minimum buy order, we are sorry
05:55
Beer
and even then, there is a waiting list
05:57
[Riki]
and even then, you have to pay the 7btc fee to join the lottery ticket qualifications for the waiting list
06:01
Jurko | Bermuda capital 📈
Zločest si sad
07:06
cool makerdao vulnerability
Deleted invited Deleted Account
19:16
Instinct
Yes don’t do tech research & development
21:39
Deleted Account
Guys what's the purpose of doing a semi KYC competition? What do you need name, date of birth and country for?
22:59
K
'A: Lets suppose that the (the cost to bribe a user) = (the value in Ada they own).'
23:01
If the accounts holding coins are public then you also need to pay extra for the reputation that joining a 51% attack might have on that person or business
23:02
If there are many businesses involved in securing a network then bribing all those businesses to ruin themselves will cost more than a centralized solution
01:07
ALGO
Are you referring to the
gleam.io competition?
01:32
Deleted Account
Yes
15:07
ALGO
Ah, just to shed some light we semi KYC to differentiate between university students and general cryptocurrency community members as prize pools will be seperate for both parties.
Deleted invited Deleted Account
02:49
Zack
A potential bribery attack against pow.
Script puzzle attacks.
The attacker publishes a puzzle that can be solved with bitcoin Asics. They offer a prize that is more profitable vs mining bitcoin normally.
So lots of miners stop mining on bitcoin, so an attacker needs less total hashpower to succeed in gaining 51% control.
Can this break a pow blockchain?
03:12
Mr Flintstone
as soon as the attacker has the hardware the block reward can go up
03:51
Zack
Oh yeah. If people stop mining, the block reward increases, which makes the cost of the attack higher
Lord Mazo invited Lord Mazo
07:07
Zack
So if I control 10% of the hashpower, and I bribe the other miners by paying them >90% of the block reward, then I could attack.
But the block reward would increase 10x per unit of hashpower. So I am really paying out 9x the normal block reward.
Is there something we are missing?
It would be a tragedy if pow is vulnerable to bribery.
07:11
Živojin Mirić
Everything controlled by humans is vulnerable to bribery. Good luck with successfully bribing the other miners. I can't believe you are still stuck on bribery theories. Humans are not machines and you don't take that fact into account.
08:46
O K
The basement is not controlled by humans
08:52
Zack
With pow, if an attacker is willing to pay more than all the tx fees and block rewards, they can censor all txs for that period of time.
This isn't considered a vulnerability.
The puzzle bribe attack is 9x more expensive, so it isn't a valid attack on bitcoin.
Now consider if someone used this attack to censor the result of an Oracle or sortition chain.
In that case, we could use the on-chain model of pow security to prevent the attack. Like how ethereum recovered from the dao hack.
Since the money is locked in one place for a long time, and we can see that the attack is occuring, we have time to do a hard update to prevent the attacker from stealing anything.
We can keep bumping back the delay to settle the sortition chain, so the attacker has to keep paying 9x all the block rewards as bribes until he runs out of funds and the attack ends.
So I think this attack is not an issue for Amoveo, or for sortition chains.
08:58
O K
Precisely my point
10:34
haven't listened but looks like DAC was mentioned on this podcast
14:08
Sebsebzen
Beep beep 🤖
Deleted invited Deleted Account
15:55
Ben
i only have to bribe sy, then veo is done.
20:23
K
If humans aren’t machine then tell me why bitcoin miners have secured bitcoin for 10 years based on an incentive for profit
20:36
Živojin Mirić
Logical fallacy
20:38
Šea
not sure if im following the discussion but tell me how did it happen that miners haven't been bribed for 10 years?
05:02
Deleted Account
that, are you opposed to new listings or is it ok?
Zack
05:32
Zack
I just don't want to pay for more listings
05:34
Deleted Account
that is super fair
05:34
Zack
There isn't much progress these recent days. I am sick. I'm resting a lot to recover. Soon I will be getting goals accomplished once again.
05:34
Deleted Account
ideally get free listing w exchanges that want to support project
05:35
Zack
That would be nice. I can help if they will list for free
05:35
Deleted Account
instead of trying to grab money.. ive experienced this myself w project i work with
Deleted invited Deleted Account
14:28
Sebsebzen
What did you catch?
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
21:35
Zack
I'm not sure. My tonsils hurt and I have a fever.
I'll be better soon, don't worry.
Negoro 1101 invited Negoro 1101
05:15
Zack
How come both new_channel_tx and new_channel_tx2 exist?
Shouldn't we get rid of one of them?
07:22
Živojin Mirić
Ok thx
09:25
Zack
I'm pretty sure this update does what we want. But I'll write some tests for it before we merge it.
09:59
Zack
https://ncase.me/learning/Here is a talk about how to make good tutorials.
I guess learning about amoveo is a barrier to entry of using amoveo. We need a video or a game or something to on board new users.
10:45
Sebsebzen
Go see a doc, maybe you need antibiotics
10:46
The Decentralized Oracle for DeFi
10:57
Zack
They use voting for disputes.
It is cheap to bribe voters and manipulate the result of a vote.
So that means it is cheap to punish honest oracle reporters and steal their stake.
11:07
So, not only is it cheap to make the Oracle lie, but you get to steal stake from the honest reporters as a side effect.
11:28
Živojin Mirić
Are you sure you are not under the influence of the medication?
11:31
Živojin Mirić
Ok thx
21:40
Zack
Someone suggests a bribe attack on pow.
Let's say we are trying to settle a sortition chain.
Someone who previously owned the winning ticket, and then spent it, they want to claim the winnings anyway.
They offer a small bribe, of like $1 to any miner who finds a block and excludes evidence that would allow the true winner to claim the prize.
The idea is that the miners will prefer to take the bribe and censor the correct winner from claiming his prize.
21:45
The reason that this attack would fail.
If you have the potential to win a bunch of money in a sortition chain, then surely it wouldn't be an issue to pay a fee of 0.1% of the winnings, as a tx fee to get your tx included and claim the winnings.
So a $1 bribe isn't enough. The attacker would need to pay >0.1% bribe on every block to convince the miner to not include the tx.
If the sortition chain has 1000 blocks of time to be settled, and the attacker is spending >0.1% of the sortition chain value on every block in bribes, then the cost of this attack is greater than how much the attacker can steal. It is not a profitable attack.
22:59
Zack
Another potential bribery attack.
What if the attacker pays bribes bigger than the block reward for miners to redo history from a point like 6 blocks in the past?
Could this enable double spends?
23:21
Zack
Any ideas guys?
00:16
Zack
I guess you couldn't use this attack against a sortition chain.
Because sortition chains are so slow, we can do a hard update to prevent the attack.
It is only against on-chain spending.
So maybe this means you need to wait like 14 days of confirmations for an on-chain spend to be secure?
01:04
Zack
It would be cool if we could set up sortition chains to make amoveo secure against this attack, then we could start executing this attack against pow blockchains.
01:27
O K
What is the first document you would suggest someone read about sortition chains?
02:40
K
Do I need to run a full node to use payment channels in amoveo?
02:40
and interact with smart contracts in them?
02:44
Zack
No, you can use the light node.
03:05
That is why I rewrote the smart contract virtual machine in Javascript
04:49
Zack
Fernando Nieto was able to explain why this isn't an issue.
If we see that bitcoin had a reorg, we should temporarily stop accepting payments, until we can use a market mechanism to determine the relative value of bitcoin on each side of the fork.
The more valuable side is the real bitcoin.
Deleted invited Deleted Account
12:05
Zack
I am setting up hard update 26 to activate at block 96560
12:06
@Simon3456 @potat_o is that ok for you guys? can you update within the next 2 weeks?
12:07
haha, hitbtc finally updated, and now we are doing another hard update
12:14
O K
Sure, no problem here
12:14
Zack
great, thanks for the quick response OK
13:45
I am getting rid of this server
139.59.144.76it is running an old version of ubuntu, it no longer works.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
21:59
Zack
I'm thinking of adding the ability to sync blocks in reverse order next.
22:01
We care the most about the most recent blocks.
It is far more likely that someone remined a few recent blocks than someone remined the entire history back to genesis.
22:01
We should sync the more relevant stuff first, so we don't waste time.
22:01
It is a cool way to show off the advantages of a stateless full node
22:03
And it would allow people to set up a working full node in less than a minute.
22:04
I guess the complicated part is that we would like to sync a recent checkpoint of the account Merkel tree, and channel Merkel tree, etc
22:07
You need the Merkel tree before you can generate the Merkel proofs to be able to include txs with blocks.
So I guess only the mining pools need to do that.
22:08
Another option is to have users submit the Merkel proofs along with their txs.
22:18
We could have some full nodes specialize in knowing the Merkel proofs. And other full nodes specialize in mining blocks.
22:20
I think we can delete a bunch of legacy code related to syncing.
Since all the full nodes are using the newest syncing strategy.
22:34
O K
Can we try on a new branch first?
22:35
Zack
Yes, good idea.
00:12
Mr Flintstone
any thoughts on faster blocks to minimize the worst case for channel users (needing to wait a long time to get into block)?
@Simon3456 @potat_o
00:13
we can adjust the emission stuff to keep inflation etc the same
00:14
plus diff adj and oracle settlement parameters
00:19
O K
Why not just allow channel play at 0conf? Serious question.
00:19
Mr Flintstone
replace by fee
00:22
Zack
I didn't program replace by fee yet.
00:22
Mr Flintstone
does it need to be programmed? I just sign another tx with a higher fee
00:22
O K
Disable RBF for channels? Faster blocks are worse for a decentralized global network (latency/51%). 5 x 1 minute blocks are as easy to overwrite as one 5 minute block. Etc etc bitcoiner arguments that don't apply here. I'm just along for the ride.
00:22
Mr Flintstone
before it’s in a block
00:22
O K
This is different than RBF
00:23
Mr Flintstone
oh sorry
00:23
O K
that's more like a double spend tbh
00:23
Mr Flintstone
but 0conf still has the vuln I am describing
00:23
O K
(Why 0conf is insecure)
00:23
Zack
The mining pool code currently rejects any contradictory tx, regardless of fee.
00:23
Mr Flintstone
they have an incentive to update it to make more money
00:24
O K
Fast blocks are more easily orphaned, so all their channel play can be undone anyway
00:27
I say go for it, I don't think decentralization is a priority at this stage
00:34
Could there be some way to allow a user to place their bets and leave the tab open, get a notification or something once the channel is confirmed and bets are placed?
00:34
The objective if I'm understanding you is just to abstract away the delay right
00:36
Mr Flintstone
yeah, though there is always an incentive to try to save money if the trade moves against you before you’re in a block, for either party (related to free option issue). so not only does delay make UX annoying from time perspective it also means fewer signed trades make it into blocks since someone will just spend the veo out of their account to save money if the trade moves against them
00:40
O K
That's true, I figured you were looking for something temporary while liquidity is generally low.
Unfortunately I don't think there is any secret shortcut to faster secured on-chain tx confirmation. This is one of the oldest problems, satoshi wrote about it. The channel is the breakthrough, but we have to wait for the channel to be secure.
00:41
Zack
Faster blocks does cause miner centralization. It favors big pools, because the amount of time for propagation is bigger relative to the block time.
00:42
These are all governance variables anyway, so the proper way to make these changes is with futarchy markets
00:45
Mr Flintstone
yeah, block time is just one element/cost of UX. large spread in the spot market is a huge cost as well
00:52
O K
Last time I looked at the wallet, my opinion hadn't changed. The UI is overwhelming, like a space ship control panel. That'd be where I would start.
Does the current light wallet automatically check for block confirmation and notify the user? That'd be huge. A friendly message "Hey! Your transaction hasn't confirmed yet. Go boil some water and have some tea. We will let you know when it's done so you can get your gamble on baby!" (Note I am not a copy professional). Then when it's ready the new interface loads.
We probably aren't ready to put that kind of effort into the UI, but some day we need to focus on that.
01:08
Mr Flintstone
I think the wallet that the exantech team has put together is much more straightforward and I would expect interacting with channels to be done with a future version of that wallet anyhow
01:27
Sy
5 minuets should be np tho, propagation is around 10s I think
01:27
Zack
Maybe our first killer app should be to bet on whether scientific experiments are repeatable.
It is such a morally good thing. People love science.
They want to cure cancer.
If we are a force of good, then people will talk about us.
And this type of betting isn't very time sensitive. So it doesn't matter if people don't own Veo from the start.
01:27
Sy
We timed it at some point
01:29
Zack
Look at how fast the ice bucket challenge spread.
People want to be seen spreading good things.
01:29
Politics and gambling isn't universally good the way stopping cancer is.
01:34
I can probably add some kind of notification.
Making a message appear in the browser should be easy. I'm less confident about connecting it to the OS level notifications and making it auditory
01:34
You can kind of do it manually by comparing your light wallet balance to your balance in the Explorer
01:48
Faster blocks does seem like it would make on boarding smoother.
01:48
Especially now that we know creating a channel in a sortition chain would also require waiting for a on-chain confirmation.
01:48
I'm glad we have futarchy to make decisions like this.
04:04
Zack
If I keep adding features, I think it makes it easier for them to clone my features
05:30
Sy
My nodes are updated AND restarted 😝 all done
09:26
Zack
looks like Amoveo has 238 mb of blocks, 23 mb of headers, and 4 mb of consensus state.
So it would only cost us 4 mb of space currently to store a checkpoint of the consensus state.
the 4 mb is about 3.2 mb of proofs, and 800 kb of accounts/channels/governance/oracles
09:28
the checkpoint will have nearly identical data as the current state, so we should be able to do this without having to duplicate the entire 4 mb.
09:29
we need to set up the checkpoint if we want to be able to sync blocks in reverse order.
09:32
@potat_o https://github.com/zack-bitcoin/amoveo/tree/cleanHere, I set up a branch that gets rid of all that legacy syncing code. Like you asked for.
So you can test whatever you need to before we merge this into master.
It shouldn't change anything about how the full nodes are currently operating.
09:56
O K
Great. I'll give it a shot.
11:49
Zack
http://159.89.87.58:8080/txs.htmlI updated this page so when you look up your balance, it also says if you have some 0th confirmation tx that will adjust your balance soon.
It is a small step towards what you asked for.
You can check you balance to immediately see if the tx has been included yet.
11:52
O K
I think that's a pretty cool feature, nice work.
12:07
Zack
I am thinking about the process of betting using an oracle that hasn't been created on-chain yet.
Currently you need to copy/paste the channel offer, the question text, and the block height when the oracle expires.
We want to simplify this.
We also want the interface to be simple for oracles that do already exist on-chain.
Maybe the datastructure with channel offers should always include this info, even if the oracle already exists on-chain?
12:10
I guess ill try programming it that way, and see how it goes.
23:54
Zack
Someone suggests this attack on pow.
The attack mines a valid looking header, but doesn't reveal the block.
So the rest of us aren't sure if it is better to build on that header, or to ignore it and build from the highest known block.
The attacker has the freedom to either reveal the block or not, depending on what the rest of the network does.
This has a centralizing effect. Bigger pools can more effectively use this strategy to punish everyone else, so the difficulty goes down and they start winning more rewards.
23:58
One potential solution:
Currently, we take a Merkel root of the txs in a block, and that gets included into the header.
We could also include a Merkel root of the txs from the previous block, but they should all be salted with like a single 0 byte each.
That way, it is impossible to mine a valid block without knowing the txs from the previous block, so this will prevent any miners from building on the attacker's header.
So then this attack becomes the same as the selfish-mining attack, which we already know does not work.
01:20
Zack
Maybe if we have a community norm of not building on headers without blocks, it is a self-reinforcing norm.
01:41
Mr Flintstone
I think this makes sense. it really isn’t much more data
01:55
Zack
It isn't any more data. The Merkel root for the txs, and the Merkel root for the account tree and channel tree etc, they all get combined into a single root.
03:27
Zack
I am not certain if this is a valid solution though.
Maybe there is some way to use zero knowledge proofs to prove what the merkel root should be, without revealing enough info to allow them to re-create the block.
05:38
Deleted Account
hi, just making sure: is the web wallet secure enough to store the VEOs? I'm referring to
myveowallet.com
05:56
Zack
This is the web wallet that I maintain
https://github.com/zack-bitcoin/light-node-amoveoYou can download it and open it in your browser. That is the most secure option.
That other Web wallet is pretty, but I haven't reviewed all of the source code.
06:02
Deleted Account
Thanks Zack, but since the other one is on the official website it would be nice to make sure it is ok
06:03
O K
The only 'official' website is the github, as far as I know.
06:05
Deleted Account
new users won't wonsider github to be "the" website but that is just my input. I will refrain from the web wallet for now and use the github, thank you
11:15
Zack
It would be nice if we could get some confirmation on whether this works before we go through the trouble of doing a hard update to add it.
11:15
I wonder who I could ask.
11:49
Anyway, hitbtc has done a bad job. I think
qtrade.io has done the best job out of the exchanges.
12:01
O K
Hitbtc is so bad.
12:04
Zack
Well, we do hard fork at much higher frequency than any other blockchain I know about.
So it makes sense that they would think that.
12:05
We are fortunate to have qtrade. They are willing to put up with us.
13:08
O K
They are bad regardless of veo.
13:21
Zack
I did an update to the light node and p2p derivatives server.
Now making channel offers is simpler, especially for oracles that do not yet exist.
the oracle question text and oracle expiration date are embedded in the channel offer, and it automatically checks that the oracle ID is calculated correctly from them.
So when you post an offer on the P2P derivatives page, you just copy paste the one channel offer, you aren't also copy pasting the question text and question height.
thanks
@Jbreezy0 for suggesting this upgrade.
13:21
hopefully I didn't break anything.
I did a bunch of tests, but it is hard to be certain.
17:15
Sebsebzen
Is it possible to close DACs now
18:16
Beer
XRP army spamming the Amoveo TG. the desperation is in the air
21:22
Zack
Dac work the same as any other contract in amoveo.
Are you asking about oracles?
21:33
Mr Flintstone
this is the same for accepting a channel offer? you just need to copy paste one string of text?
21:34
Zack
Correct. And the otc_listener page always tells you the Oracle question text now
21:35
Mr Flintstone
awesome
21:40
we can start to abstract away the complicated stuff now
21:40
like users don’t need to know what an OID is. all they need to remember is to save the string of text and not lose it
21:41
Zack
If they want to report in the Oracle, they need some way to find it
21:41
Mr Flintstone
isn’t it in the string of text somewhere
21:41
Zack
The default path can hide a bunch of stuff through, and we can have a different page for extracting it
22:30
Zack
I think I am starting to understand. This is a continuation of the selfish mining debate.
The next way of looking at it, is that if rational miners know selfish mining is happening, it marginally decreases their expected profit, without reducing their costs.
So this can turn many miners non-profit able, causing them to switch off.
22:32
In the case of amoveo, our retargetting is very fast.
So I guess some people would switch off, the difficulty would drop, and the profitability would return to normal levels
05:18
mr x
yay, I suggested it imo!?
05:19
Mr Flintstone
i am sure multiple people did :)
05:19
Mr Flintstone
at any rate, things continue to get better
05:50
Zack
Thanks for the suggestion, I think it was a good one
11:59
Deleted Account
@jsmitth do you know if they will update? their withdrawal don't work for me
12:01
Zack
The system monitor says Veo is online. You should probably complain to them somewhere if a withdraw isn't working.
12:01
The update doesn't activate for 2 weeks.
Deleted invited Deleted Account
15:14
Deleted Account
hello admin
15:15
im from bitfare exchange with whom can i talk about listing
18:31
Zackatron 9000
Whats wrong with his face?
20:38
Mr Flintstone
spammers have come out in force lately
23:33
http://159.89.87.58:8080/peer_scan.htmlIt is a little concerning scanning all the nodes and seeing that only my node has updated for the upcoming hard update. How come no one else has updated?
00:15
Zack
http://159.89.87.58:8090/main.htmlI put a channel offer on this page.
I am risking 0.2 veo to try and win 0.1 veo.
I am betting that block 95500 will have a prev_hash that is even when encoded in hexadecimal.
So you can bet 0.1 veo against me, and you are expected to win 0.15 veo.
I am making a bet with an expected loss to test out the channels smart contracts. The knowledge we gain from testing is worth more to me than how much VEO I am expected to lose in this bet.
04:11
Zack
What is the best price for VEO on December 31/January 1st?
I guess this could be important for taxes for some people.
04:14
oh, is that why the price spiked at new years last year? was a troll trying to make our tax bills worse?
04:25
Mr Flintstone
generally tax liability uses the fiat value at the time of sale
04:25
maybe some places are like that but I’m not familiar
04:31
O K
Is this otherwise up to date Zack? Getting ready to play with it.
04:32
Zack
it doesn't have the hard update, but that wont activate for a week. should be ready for testing now.
04:44
When is keys.db created now?
04:44
Zack
it hasn't been changed
04:44
O K
Should be on build in amoveo/db/keys/keys.db right?
04:44
Zack
a new one gets created on startup, if it doesn't already exist
04:46
I have data and oracle_questions directories after build in amoveo/db but no keys
04:47
Zack
what if you do api:pubkey().?
04:48
did you run it in production mode, or only in test mode?
04:48
O K
I just rebuilt it, it's there this time 🤷♀️
04:48
I ran it in production mode, and ended it immediately after it started syncing with the normal routine (sync:stop(). api:off(). halt().)
04:49
Maybe I was just too quick for it.
05:22
O K
Everything seems kosher here on the
clean branch
Zack. Thanks for the opportunity to test.
05:24
Zack
Sounds good, I'll merge it soon then
Deleted invited Deleted Account
07:55
Zack
There is a trading channel on discord. This is not a place for trading.
07:55
Beer
yeah i was only trolling him
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
09:29
Zack
hello new members. say "something", or get banned.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
14:43
Zack
hello new members. say "something" or get banned.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
15:08
Zack
I removed them all.
16:41
MH
All those guys joined ChainX group as well... 🤔
12:31
Zack
I made some simplifications to the P2P derivatives tool based on
@Jbreezy0 's suggestions.
I removed a bunch of unneeded stuff to make it more obvious which parts you need to use.
We no longer need to save channel state, or load channel state.
Everyone just keeps a copy of the same channel offer.
In this way it is more symmetric between the user who proposes the channel offer, and the user who accepts it.
13:18
Zack
I guess the next step is for the new_oracle.html page to accept a channel offer as instructions on how to make a new oracle.
15:36
Sy
We did update for the fork, your fork display update was afterwards 😁
Deleted invited Deleted Account
19:21
Deleted Account
hello zack how are you ?
17:50
Živojin Mirić
Happy Futarchy to all!
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
20:34
Šea
Wow so much new members here, such a nice Christmas present for Veo community :)
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
22:09
Zack
Hello new members. Greet us, or you will get banned.
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
22:38
Nayan Savla
For sure won't be able to...
Deleted invited Deleted Account
12:20
Tweety
Is this coin worth anything?
22:06
Zack
Would someone benefit if we let them manipulate the price upward for the new year? Does it help someone's taxes?
Why is gozo more than double the price of qtrade?
22:09
Maybe someone sees this manipulation as a kind of advertising?
22:24
sanket
I don't think anyone benefits
22:28
Zack
Then anyone with a gozo account should take the arbitrage opportunity.
22:37
sanket
I think it is about the ability to enter-exit from exchange and liquidity
23:33
Mr Flintstone
we’ve seen the btc market on qtrade take some time to react to Gozo’s higher price before I think
23:34
I can’t imagine there are any tax efficiencies for doing this
23:34
maybe Gozo needs lots of confirms for veo deposits
23:34
does anyone here have an account there?
23:37
Zack
Oh, that makes sense
01:02
Zack
Seems like the kind of guy who likes to make things as complicated as can be. What is he hiding under the complexity? I can't find the paper he claims to have written.
People with something good, use simple words, so they can be understood.
People with nothing good, use complex words, to be misunderstood.
01:30
Instinct
Are Veo withdrawals working on hitbtc right now? Might put some small bids there
01:30
Zack
I'm thinking of writing some posts about the basics of finance, game theory, and cryptography.
Nothing new or controversial. Just really basic principles that we have widely agreed upon for 50+ years.
The really simple stuff that anyone can quickly understand.
I think a handful of simple principles from these fields would be enough so that people could protect themselves from almost every scam in the cryptocurrency space.
01:34
Instinct
I guess they’ll go offline again when the next update goes through, that’s in a couple days right?
01:37
Sounds good, maybe publish to medium or something too. See if it gets more traction then GitHub
01:37
Zack
I don't know. They never tell me if they have updated or not.
05:45
Zack
Hitbtc has been randomly freezing and unfreezing amoveo markets.
Their behaviour is consistent with someone doing market manipulation to scam Veo users.
I am willing to give advice to anyone who wants to use amoveo tech.
But you can see on the amoveo github that hitbtc is not on the list of recommended places to trade Veo.
05:46
Any comments or suggestions?
I am feeling least confident about the game theory section. Maybe I should delete that part.
10:45
Toby Ganger
is there a new page to use for spending from a wallet? i just realized my old bookmarks no longer work
11:24
Toby Ganger
yessir….thank you…i must have forgotten to update the bookmark….appreciate it
17:11
Živojin Mirić
you are spending VEO???
18:43
bitcoinsfacil - pedro
I like it but I would not throw conclusions like "If someone says ..., then they are a scammer"
18:45
Zack another topic for that document could be 'information asymmetry' where one party has more or better information than the other
22:59
Toby Ganger
Haha. No. Just realized i had a broken link.
23:00
Živojin Mirić
👍🏿👍🏿👍🏿
Deleted invited Deleted Account
Deleted invited Deleted Account
Deleted invited Deleted Account
04:07
Zack
I want to use amoveo to finance good science to help save lives.
I've been thinking about heart disease. It seems like oxidation of polyunsaturated fats makes them dangerous. It clogs arteries.
Eggs are one of the most common protein sources, and they contain some polyunsaturated fat which could potentially get oxidized.
I found this research paper where they compare different ways of cooking eggs to see how much oxidation occurs.
https://www.emerginginvestigators.org/articles/the-effect-of-cooking-method-on-the-amount-of-fat-in-an-eggIt seems like the process they use to measure how much fat gets oxidized is fairly cheap and simple.
I was thinking we could do something similar for more ways to cook eggs.
In particular, I am curious about whether putting some baking soda in the water before you hard boil the eggs could prevent oxidation. It seems like baking soda captures oxygen.
So maybe we should try making some derivatives to incentivize someone to do this experiment, and then we can make some derivatives to verify the accuracy of the result of the experiment.
04:09
I'm also curious if the maillard effect can prevent some oxidation, but I am expecting any experiment for that to be a lot more complicated.
04:11
Heart disease is one of the biggest causes of death. It would be great if we could do something to reduce it.
04:21
I think if we even try to do stuff like this, we will get many eager third parties that want to spread news with the headline "using blockchain to fight heart disease"
04:25
Eggs are an especially good subject because there are financial interests from the egg and meat industry that keep doing fake research to try and trick us into eating differently.
Amoveo derivatives can cut through the lies to find the truth.
04:26
Our p2p tool really makes amoveo the ideal platform for this. We don't need to launch a specialized oracle
04:55
Toby Ganger
i highly highly discourage this dietary stuff….
04:57
VEO - first blockchain to cook eggs properly
04:57
Could you guys imagine we'll get here, year and a half ago?
04:58
Toby Ganger
dabbling into dietary advice is akin to dabbling into religion
04:58
Živojin Mirić
Definite proof on what clogs arteries is still unknown, don't go there Zack, you're not an expert on that
04:58
Toby Ganger
in fact most people who “are” experts on it don’t really know
04:59
Živojin Mirić
Human body is still too complicated for out level of technology
04:59
Futarchy will deal with it in a couple of centuries
05:04
Zack
Lots of people avoid oxidized polyunsaturated fats. Regardless of whether it clogs arteries, a lot of people think it is unhealthy, and I think they would be interested to know how to cook eggs to avoid them.
05:11
I like the idea of using finance tools to fix the incentives in science, to prevent all these bad unrepeatible experiments.
The acetone wash process to measure oxidized fats is cheap easy and fast, and it is a controversial subject.
If you guys don't like this experiment, can you suggest some other experiment which would be a good place to start?
05:12
I think it would be nice if we could tackle heart disease or cancer or some kind of disease that is a big problem for a large number of people.
That way people will feel morally good about using the tech.
07:26
Instinct
Agree, I think it’s a good area
Deleted invited Deleted Account
23:34
Zack
So how are we going to make these contracts?
I guess we need one contract to incentivize someone to do the experiment, and then a second to verify the result is accurate.
But it seems like the experiment contract should only pay out if their result is accurate, so it would need to reference the second contracts result somehow?
23:35
I guess learning how to do this well will involve a lot of trial and error
23:36
Do we want the financial contract to be super specific about how the experiment should be done? Or should we let the scientist have more freedom to optimize based on their experiences actually performing it?
23:38
I guess we should start with something very simple, that way we can iterate on experiments more rapidly and learn quicker
01:41
Mr Flintstone
How much veo do you think it would take to incentivize someone to do this experiment
01:43
Zack
A bottle of acetone us probably like $3. 2 dozen eggs is like $5.
Maybe 2 hours of their time, even in a high income country is only like $24 minimum wage.
They need a fairly accurate scale though. That could be like $25. But maybe they can borrow a scale.
I guess $60 should cover everything with a comfortable profit margin.
01:55
Paww Lee
Whatta....
02:13
O K
This interferes with my religion that carbs cause heart disease
02:30
Instinct
That happened before, not sure why & it was added back in a couple days
02:31
Maybe the hard update activated and they weren't ready
Deleted invited Deleted Account
Deleted invited Deleted Account
