I've been talking about the value of escrow smart-contracts for quite some time now so I figured it was FINALLY time to start testing them out. I think using these smart contracts I can set up a pseudo-DEX that allows us to easily trade Hive and Steem back and forth, and even connect Graphene-based coins to other networks like Bitcoin without the need of a regulated centralized authority.
Instead of using a regulated centralized authority like Binance, Coinbase, or Bittrex we can simply use any "agent" account. An agent is simply an account that approves the escrow operation to move forward. It could be a friend you know personally on Hive/Steem. It could be someone that has a reputation for being trustworthy. It could be anyone.
I want to use these same contracts to not only implement this pseudo-DEX for under-the-table trades, but also for all of my gambling dapp ideas. The most basic one will simply be flipping a coin and seeing who wins. The next idea would be my rock/paper/scissors clone called @Pentaskill. There really is no limit to the kinds of speculative transactions one can make with these contracts, and no one seems to be using them, which I find quite odd, as there is a built in mechanic to monetize the trust using escrow agent fees.
In any case, I tried to get this started by doing the first transaction of an escrow contract, which is the EscrowTransferOperation. The problem? It doesn't work with the API that I've been practicing this whole time (dsteem). It kept telling me I didn't have the proper "active key Authority" which means it said my private active key was wrong. It wasn't. I was using the same credentials to move money around, thus the dozens of 0.001 Steem transactions from @edicted to @dexturd with the memo "this is bullshit".
My Witness team (@rishi556 & @sn0n) tried to help me out a bit, but in the end we realized that dsteem simply does not work and had to use HiveJS. This is really annoying and very telling about just how bad the documentation and backend api are for this network. Devs can run into stupid problems like this and literally spend hours trying to solve them when it should only take a few minutes (or in this case should have never happened to begin with).
Now I'm in a position where I probably have to switch APIs and try to relearn a few things. It's not that big of a deal, as a lot of the code will look quite familiar, but it is quite annoying and frustrating to be told in the documentation that something is going to work and it just doesn't and that information is nowhere to be found.
So I've got it working with HiveJS with a lot of help from @rishi556
<script src="https://cdn.jsdelivr.net/npm/@hiveio/hive-js/dist/hive.min.js"></script>
Figured out a few things about escrow.
To start, the second you broadcast the operation your account loses the money and it gets sent to a temporary account in no-man's-land. No worries, the witnesses won't lose your money.
- Both the
toaccount and theescrowaccount mustEscrowApproveOperationbefore theratification_deadline. Should that deadline pass everything gets canceled and you get the money back. escrow_idmust be a unique number and can not be used twice, but once your active escrow completes or otherwise becomes inactive, you can use the same escrow_id again.- If the escrow expires without a dispute either party can send the money to either party.
Conclusion
Again, it's really hard to believe that no one is really using these things. For example, we could make a dapp that allows us to trade Hive for Bitcoin under-the-table. Simply tell someone to send Bitcoin to X address, and when they do they will receive Hive to X account, guaranteed by the escrow system. The fee for this transaction is whatever the agent charges, so if we allow anyone to be an agent some people will surely provide this service for a very small fee (lots of competition) or even for free. It also avoids all the KYC rules because literally any account can be an escrow account and it would impossible to regulate such an operation.
It's very disappointing that I'll probably need to start learning a new API (HiveJS) but I was never under the illusion that I could use dsteem forever; it's been abandon-ware for quite a while now. It's just annoying that such an old feature that should work, clearly doesn't and it wasted a bunch of my time. Whatever, live and learn I guess.
I read about this escrow function on Steem (now Hive) before and I thought it is very useful. But as you mentioned, I am not sure why I don't see projects using it. It can be use for DEXs and DeFi, basically anything that requires a 3rd party custodian can potentially make use of this feature.
Just DAO it and boom you can make a MakerDAO ;)
Very interesting. You are a lot more technical than I am so it was refreshing to read your explanation of all this.
It is very intriguing and does appear you tapped into something that holds great potential yet is overlooked. Naturally, anything that avoids the powers that are and "sticks it to them" by avoiding KYC/AML strings a nice chord with me.
I look forward to your continued experimentation with this. Hopefully some of the more technical people see this is start to help out.
It does hold possibilities it seems.
Posted Using LeoFinance
I can imagine these micro transactions work on a one to one basis where the parties know each other. If I knew someone who would want to buy Steem from me and sell some Hive then we could set this up.
But what if buyer and seller don't know each other? How do they discover each other? How does a pseudo-dex scale?
Thanks for asking
You set up a Web/Hive frontend that shows people who post their intention to trade Hive for BTC and BTC for Hive. We have embedded custom JSON for this. The two parties do not have to know each other, they simply have to trust the same middle man (escrow agent account).
There are various ways to build up a history and a reputation for this. The frontend can even recommend escrow accounts they feel are trusted entities for new users who have no idea who they can trust. In fact, I would probably have my own escrow account (or at least our witness team would) so they would also be on the list of trusted accounts as well.
I think the Biggest problem would be onboarding users that don't have a Hive account yet. We do have various ways to do this but it isn't super streamlined yet and the way we do things is a bit different and might confuse users from other chains who haven't heard about us yet.
Someone still has to setup the front end, and that's a bit like a 'real' dex. So isn't this still a bit centralised? (not meant as criticism, just me, thinking along your lines).
No, because the frontend doesn't have to be run on a server. The code could be open source and be run directly from your own machine or there could be multiple servers and multiple frontends hosting the service because all the relevant information in on the Hive blockchain; accessible to all.
Basically anyone who has the block information can host a frontend.
I see. And the code for the front end could contain the code for discovering all buy bids and sell offers entered on the chain as well. So anyone running that code on his or her local machine or server would present the same list of bids. Or could perhaps apply a filter and show only all bids for buying Hive or whatever.
Nice!
It's good to ask questions. These things are complicated and the devil is the details for sure.
Damn that’s some solid work man. I’m intrigued by this, glad you talked about it again it’s been a bit. Would be really cool to do this over encrypted memo’s so that fuckers can’t keep tabs on some of the transactions details. Create dummy accounts to get the transactions done and keep it off the exchanges.
A thing I wonder though, if we start doing this how long before pressure gets put on the witnesses to stop allowing it? The beauty of crypto is the ability to innovate but exchanges are the monopolies of all the transactions, they will hate the new exchange free process. I would love it!
Also on that other note I'd be very curious to see how much flak the witnesses get for allowing this behavior. We absolutely must test the boundaries of this network to see how decentralized we really are. It may turn out to be an excellent opportunity to get witnesses from other countries that have much more lax financial laws.
The witnesses also have a great excuse. They are not the ones broadcasting these operations. If the operations being broadcast were somehow deemed illegal, it's hard to go after a witness just for being a small part of the network. Even if escrow services for Hive were eliminated we could simply make a new permissionless token and remake them stronger than ever.
I want to highlight this to @apshamilton. He's long said to me that transactions on a blockchain network should be considered exactly as any other speech and in this respect, platform owners, Witnesses in our case here, should be fully insulated from whatever speech occurs at least under the US's 1st Amendment. The only people responsible would be those carrying it out.
Indeed I feel like the first amendment should protect us from a lot of the legacy regulation. There's a big difference between a server running code and simply storing the information from a decentralized ledger validated by a worldwide network.
Yes, a properly decentralised network is just a digital printing press, printing new pages of transactions people send to it. The transactions only have the value that people ascribe to them.
The First Amendment protects freedom of the press so any attempt to impose licensing or other restrictions on this would breach the First Amendment.
I am surprised that neither Telegram nor Kik ran this argument in their disputes with the SEC, but I suppose they weren't properly decentralised.
Corporations don't know how to decentralize ownership because they are too greedy.
Correct. This has been @apshamilton's contention and there are definitely grounds to mount law suits in the US over the constitutionality over much of the crypto regulation... but we're busy on the other side of the world!
Hm that's actually a really good idea to set up all the details using memo encryption... then only the 3 accounts involved would know which Bitcoin address was getting funded. The only drawback to this is if the escrow agent turns out to be a bad actor and there is no proof that they colluded with one party to steal funds. Still, I'm guessing the value of privacy and the trust that people acquire around here would be worth it to have that optional feature.
Yeah I mean the escrow account will have to be trusted to perform these encrypted transactions I think but once they are, it opens the door to even more privacy than we currently have. Intriguing thought! Go make it happen lol
I have a potential Hive use case that you might be able to address.
I should start off by saying I do not even know if this is possible or even desirable. It is more of a question I have had but do not have enough technical knowledge to answer. The other way to say it is ... this is likely a stupid question.
Can dApps, etc that are built and run on other blockchains utilize Hive to get around the “gas fees“ that they are paying? Your article reminded me of this question.
Basically, could Hive be used as a backdoor to lower people’s cost to operate? Hive would win because these people would need RCs. I guess this is what splinterlands is basically doing, right?
Or would this essentially be the equivalent of a dApps moving to Hive?
I know so little, I do not even truly know how to phrase the question.
That kind of just sounds like a dapp porting it's functionality to Hive. There's nothing to stop a frontend from connecting to multiple blockchains. We usually call something like that interoperability.
There is no way to get around an Ethereum gas fee if you want the security of the Ethereum blockchain. However, if parts of your dapp required less security you could probably migrate those parts to other DPOS chains with free trx costs. It's an interesting thought.
Thanks. Yea, I know nothing about other blockchains (or very little) so it is hard for me to know where someone could cut corners but maintain the security of say an Ethereum blockchain. I do not exactly know when the gas fees occur.
Thanks.
Basically if you want to put any info on a blockchain you have to pay the fee, be it actual money or Resource Credits. This is the only way to secure that information with that particular network solution.
Essentially the fee is a feature that stops the blockchain from getting attacked and creates a system of free market capitalism based on real-time supply and demand to secure information on an inefficient decentralized database.
100%