FutureMinds 4: Flutter Wallet Upgrade

General
1

This month’s topic comes from @Jack17.

"
I am very interested to see the new Flutter wallet upgrade. I think this could be a game changer for the benefits of Crypto finally being available for the real world. Mainly benefits such as decentralisation and discreet transactions. I actually cant believe that the community arent talking about it everyday. What type of services/transactions would you like to see made possible through the new technology. Is it possible to have specialised oracle swarms such as “lawyer swarms”. Will the Fiat to Crypto (USD to PPC) onramps be a hinderance for people to use the flutter wallet.
"

For reference to the upgrade discussed, see this Peercoin presentation on the ROAST protocol.
ROAST.pdf (74.1 KB)

1 Like
2

Along with the browser implementation, I think we could see some interesting applications here. These are the ones identified by the community, as far as I can tell:

  1. Metamask-eque wrapping of ppc on other chains/protocols using large, efficient multisigs
  2. Oracles for event-aware protocols on-chain
  3. Mint pools, multisig minting, and air-gapped minting
  4. Efficient/obfuscated multisigs in general

Wrapping
By allowing for an asynchronous protocol that drastically reduces the signature data, the multisigs that are used to store large amounts of coin in cross-chain bridges can be much faster and more decentralized. This will allow for e.g. wppc to be created and returned much more smoothly.

Oracles
Formalized consensus of independent actors can provide event detection for world activities that do not involve cryptography. These are usually in combination with a 2-of-3 multisig where one actor can be mechanical that waits for the Oracle’s signal to release coin. This allows for complete separation of the judge and the execution, and allowing for scalability to small private multisigs. These are, in effect, context-aware smart gates.

Minting
This is one the community has talked a lot about over the years. By providing ease-of-use for multisigs, the formation of multisig coinstakes is within reach. A mint custodian would solve many concepts simultaneously, as they could be an organization, a service, or yourself. Organizations like the Peercoin Foundation would be able to regularly participate in minting, increasing on-chain difficulty. Services could appear as middle-men to help provide mechanical support to the minting process. Individuals could segregate their internal wallet structure, providing more complex cold- and luke-warm wallet concepts while maintaining full minting presence on-chain.

Multisigs
Managing unwieldy signatures has stymied progress in multisig organizational structures in the crypto community, resorting to fringe implementations like cointoolkit. Peercoin particularly has shown an interest in truly decentralized multisig approaches, having a history of blazing the way with UTXO-driven decentralized consensus. Putting this technology in the app/browser and at our fingertips will allow for very interesting cross-platform concepts. If a userbase develops in one of the other categories, exploration of advanced multisig applications may become more practical.

Other Curiosities/Musings
Could you create a group of oracles to act as logic gates that are txn-aware on certain burn addresses? Then people could P2TH in order to access a full Turing-complete second-layer protocol.

In some ways, the entire PoS protocol is like one big multisig with all the coins and addresses in it. Could we use ROAST to replace the entire minting protocol somehow? Just, like, hypothetically.

We could rethink concepts like Pay4Commit that we used to have, using multisigs and oracles to pay for freelance development work.

3 Likes
3

I want to try to make a list of definitions that might help communicate about this:

Txns - Cryptocurrency Transactions are the backbone signatured record that must follow the underlying protocol of the blockchain.
Contract - e.g. smart contracts, dapps (decentralized apps), DeFi (decentralized finance). Connecting contracts with txns often faces an oracle problem of relating execution with off-chain events.
DLC - Discreet Log Contract. This kind of contract specifies execution based on an external event or oracle.
Oracles - a method of incorporating real-world data into contracts, such as a large number of independent observers, or well-trusted entities.
Multisig - the original protocols for “m-of-n” multisigs were bulky, as all “m” and “n” signatures needed to be stored on-chain. Many of the more complex contract schemes, including DLCs, require multisig addresses.
BIP118 - Bitcoin Improvement Proposal. This one describes a tapscript called SIGHASH_ANYPREVOUT which allows for additional flexibility in txns, allowing multiple users to have all parts of a DLC before it is funded.
Schnorr Signatures - BIP340. These replace the more traditional ECDSA signatures over the same cryptographic algorithm, while being more provably secure and solving malleability issues. They also have the property of “linearity” that allows conglomerations of keys into valid signatures, solving efficienty and anonimity issues with multisigs
Taproot - BIP341. Segwit output types that make script-based spending indistringuishable from traditional spending with a key.
Tapscript - BIP342. Full validation for taproot scripts, enabling their inclusion in higher level protocols like DLCs.
TSS - Threshold Signature Scheme. Any multisig with m<n will activate with just a subsection of signers.
FROST - Flexible Round-Optimized Schnorr Threshold Signatures. Communicating between multiple subsections of independent entities requires a flexible protocol to minimize the number of communication rounds needed.
ROAST - Robust Asynchronous Schnorr Threshold Signatures. The key word here is “asynchronous”, allowing all participants to communicate at once with a central server. This spells out a practical implementation capable of handling advanced TSSs like DLCs.
Layer 2 - in general, contracts and scripting can be executed mostly off-chain, with just their final form being posted on-chain. In many cases, just the possibility of posting an on-chain transaction is enough for parties to complete their portions of the contract, drastically reducing the need for on-chain data and keeping the blockchain slim and fees low.
LN - Lightning Network payment channels are pre-established pathways for txns to flow through that allows their assured validity without requiring posting on-chain. The signed but unpublished txns are held by all participants and represent the current balance of the network.
Eltoo - DLC payment channels can be used in conjunction with LN or independently. With LN, Eltoo allows users to throw away old states of the unpublished txns without fear. The use of “update/settlement” keys along with ANYPREVOUT allows the update txn to spend both the original channel open txn and all previous update txns.
Flutter Wallet - Peercoin’s mobile client, written in Flutter/Dart. This app would be a ready host for DLC’s and layer 2 solutions, leaving the core reference client and consensus mechanism untouched.

If anyone has any questions or anything, I’d love to discuss. Some of the difficulty here is understanding how to even approach such a complex topic as Schnorr signatures. However, I think we have an opportunity to be a uniquely well-informed community on these topics if we choose to hold the discussions necessary.

2 Likes
4

This is helpful thank you Nagalim. So I may be on the wrong track here but let me be the first (non dev) to ask a question. I presume the Oracles consensus is always a manual process. eg. I am one of the people chosen to be an oracle for a bet between Nagalim and Peerchemist. The result of the Cricket match has passed and I manually submit the result. “Yes, Australia beat India So therefore Nagalim wins.” (Or however that process will manually be carried out.) Back to my question, Is it possible that an answer can be processed by the oracle before the result has passed? eg. Nagalim agrees to pay Peerchemist 10,000 PPC to complete some Dev work on a dapp. Before the Job is complete, I manually submit my result as " Yes, release the funds to Peerchemist as soon as Nagalim agrees that the work is complete" And then Nagalim will Manually sign off that Peerchemist has completed the dev work which would release the payment to Peerchemist. So the oracles are acting as escrow but they wouldn’t know the answer unless Nagalim told them the work is complete. Maybe this would have to have a timeline built in to this so the work must be complete by 20/1/25 for payment. Am I asking this correct? Could this be processed without mammals? Does each Flutter wallet (or oracle) have a node that could process this with a code/script? Would you even need oracles for the second example? How did the Peer4commit work?

1 Like
5

It’s a little different than you have in mind, because the Oracles don’t even have to know Alice and Bob exist (just to keep things more understandable, Alice and Bob are replacing me and Peerchemist in our thought experiment as people who have entered a contract). Rather, Alice and Bob enter into a contract where they rely on the oracle’s signed statement of the outcome to act as the 3rd key. The Oracles are charged with simply reporting that Australia beat India, they don’t even have to post it on the blockchain, merely state publicly their signed message. Then, Bob will use their key and the oracle’s signed statement to receive their funds. Under the old multisig scheme, this required a custodian to intensionally sign the txn and act as a trusted oracle with a key to the money. The new design keeps the oracle out of the loop and untrusted except to deliver the correct signed message.

For Peer4Commit, the oracles may be more aware of what is going on, but that’s ok too. Devs can keep their anonymity and rely on a multitude of code reviewers instead of just one executor.

2 Likes
7

Sorry, i got some things wrong and edited my post. There is no custodian. The oracle’s signed public statement is used as the third signature.

The procedure is like this:

  1. Oracle provides pub key and intent to sign one of e.g. two outcomes to an event and post the signature publicly.
  2. Alice and Bob make a DLC based off tht pub key as the third signature.
  3. Oracle posts signed result of the event
  4. The winner signs their txn and adds the oracle signature and broadcasts, receiving their funds.

Peerchemist posted this in discord:

8

I saw on Discord that this will be posted publicly but what if the winner doesn’t see the post? Is this step automated or manually posted? Maybe we can develop a mini forum/chat room in the Flutter app for these results to be automatically published on. I am probably way off again. Its hard to get my head around how it works as a non dev. Which makes it even harder to try and imagine what it could be used for besides simple betting.

9

Let me try make a fool of myself on another subject. Wrapped coins. So I see that the dev team are currently experimenting with adding a browser to the flutter wallet to do workflows similar to Metamask. I sort of know how wrapping works on Ethereum. Basically its a way for any coin to be interoperable with other coin/token through the process of wrapping. The problem Ive always had with this is that I change my Peercoin into an Ethereum based token and I dont know enough about Ethereum to trust it. Especially with the threat of new regulations from the SEC over the past few years. I also know that ETH had an ICO which I believe is not a good thing. Will the Flutter wrapping process work in a way to swap these ETH tokens with other tokens? So basically doing the exact same thing as Metamask? Just with cheaper fees I think? Is there a way that Peercoin can come up with its own “Wrapping Machine” so instead of turning BTC into WBTC it actually changes it into PBTC (Peer Bitcoin)? So now Peercoin would have its own interoperable machine for all Coins or tokens to use?

1 Like
10

So in this case we would have an Oracle swarm called Dev Oracles. So it seems we could possibly have Lawyer swarms too. How much work is involved in making Peer4Commit work with the oracles in Flutter wallet? From what I understand, the Oracle swarm only needs a percentage of the total in the swarm to agree on the result for it to be considered a result/winner. eg. 6 out of 9 or 33/49 etc. As soon as the 6th (out of 9) agrees then anyone can broadcast the transaction. Is that right? If yes then would you still need Peer4Commit?

1 Like
11

Copying and pasting the hash seems an approachable thing, whereas automatically resolving would require either the oracle to submit to a particular protocol, or for the flutter app to be really good at e.g. reading discord messages. Instead, it seems fairly low-barrier to copy and paste a hash from discord into your flutter. However, hypothetically yes this could be automated. I just dont think that will be top priority.

For wrapped coins, the goal is to use ethereum’s scripting language so that you can access markets like quickswap. Here, it is important to have a viable market, which means that using ethereum exclusively is necessary for its big user base. Wrapping btc on the peercoin chain does not really make sense because peercoin does not have ethereum’s scripting language, nor its user base. Hypothetically, something like tapscript could maybe be used, but at that point I feel like something more direct chain-to-chain and trustless like atomic swaps makes a lot more sense than our current wPPC approach using trusted multisigs.

I’m not totally sure about the mechanics of what thresholds will be used for the swarms. However, yes we could have oracle swarms that specialize in different topics, and are generally recognized as more knowledgeable. This is an interesting social question, because you need to balance expertise with reliability/trustworthiness. Would you trust your doctor to sign a transaction on time?

I dont think we use Peer4Commit anymore, this would hypothetically replace it. I think thats what we’re going for, but dont quote me on that.

Finally, for everyone reading, I really appreciate these questions and don’t think anyone is making a fool of themselves here. These are complex topics, with a lot of nuance, and we should not shame each other for learning about them.

2 Likes
12

I was wondering if these specialized oracle swarms would have to somehow earn a fee? To be paid to each specialist that reply. eg. if the threshold is 6/9 then the first 6 get paid. This would obviously encourage the reliability side of the transaction but it could also open questions about the trustworthiness. Is there a decentralised way the flutter wallet could handle payment of such fees? Note; the fee is paid by the users. Another question would be is how much is the fee and how much time will it take to give an accurate answer? Same length as a piece of string? A solution for this is the fee amount will be agreed on before the contract is entered into. That may be another contract before the contract then?

2 Likes
13

Hopefully the outcome of making a “metamask” type of platform increases Peercoins users and increases our liquidity… Atomic swaps would be cool to have too.

14

One of the main points of a DLC is to keep the oracle and the contract separate. The oracle does not know about the contract, and as such does not profit off of it. Hypothetically, the same tech stack could be used by an oracle to send themselves money, and that might have applications in “tapscript” which would be like an on-chain computer that interacts with oracles to execute actions. However, the traditional DLC concept uses oracles that are motivated by some other reason, such as a desire to report the truth or abstract ideals, or yes someone could pay for such a service to be publicly accessible.

I think this tech stack has a lot of possibility for increasing application and use-cases, which for me is the main route to adoption.

2 Likes