I disagree with all points.
Grin is still cool, though.
1 Like
Interactivity is cumbersome and not minimal or lightweight. But supporting use cases like cold storage and reducing the complexity of a transaction makes for minimum basic functionality and a lightweight transaction by cutting the mass of the required participants by approximately half.
It is minimal and lightweight on the protocol level.
2 Likes
We currently support 3 ways of communicating to facilitate interactivity, that doesnt seem minimal or lightweight. Also, requiring keys to be in memory to use is a massive security burden on the protocol, again not minimal or lightweight.
2 Likes
Thatâs what I thought as well which is why I was trying to find a solution to this, but then I came to the conclusion that it doesnât really change the security âasymptoticallyâ. I think itâs really just a factor of 2. In one-sided txs you need keys when you send. In two-sided txs you need keys when you send and receive. If we say that half of the transactions we do will be sends and half receives, then it is just a factor of 2, so nothing substantial imo. Overall a tx usually has two parties so it requires only twice as many keys present for a tx.
Edit: If you like to think in terms of the transaction graphs, one-sided txs needs keys for out edges, two-sided need the key for both out and in edges.
l am in favor of having both. I know this contradicts my statement about reducing transaction types.
Full interactive transfers (including the finalise step) should stay supported simply because interactive shemes are likely to allow for more advanced transaction types that we cannot fully forsee yet.
In a way I would see it similar as having coin control, yes you should have it around, no most people will not use it for day to day transactions.
Similarly interactive transfers with the finalise step should stay around for desktop users, normal day to day transfer can skip the finalise step while mobile payment involving QR codes could be either transactions skipping the ginalise step or non-interactive transfers.
I think it is important to think from use cases/user-stories perspective and then carefully select which magic to make it happen, with 90% of the users being totally oblivious what magic eas used.
Handling of dust outputs can maybe be done by self spending, so signing them with a trusted key, while untrusted dust outputs are burned. In this way all wallets will know if dust outputs can be used or not.
Edit: No, I am wrongđ¤. Interactive and non-interactive transfers should stay but after some more thought transactions without the finalize step should contain the same information as transactions without so there is no need to keep it around.
Not a fair comparison at all. For asynchronous methods that involve receiver accepting, sure, if you want them to also type their password to receive. But for any listener-type synchronous transactions (most use cases), then itâs not a quick decrypt and perform an action. Private keys must remain decrypted, in memory, on an internet accessible device. This is horrible for security.
And I get that your solution, once again, is probably that users should manually accept transactions. But despite you really wanting that to be the case, thatâs just not what users want at all, nor does that even work for always-on services like exchanges and payment processors. You canât ignore the desires of the actual users of Grin just because it makes for a clean technical solution.
2 Likes
Iâll have to disagree with you on that one @david. Everybody I know uses a payment app that forces you to accept payments. I use it too. And we all have plenty of other options, but this one completely dominates over the market, so I donât think the UX is terrible, quite the contrary in fact. accepting money with one click gives a good feeling and is not really inconvenient.
1 Like
Afk, so I will respond thoroughly later. But quick question: Does this mean youâre in favor of removing tor transactions, and instead using slatepacks (preferably with no finalize step), and then requiring users to also type their passwords when receiving? That is the only possible way Phyroâs security argument remains true.
Agreed. This kills Bitcoin and that is the reason of all that bitcoin maxie & HODL culture and why after 10 years of existence Bitcoin havenât become some significant payment protocol. People were more enthusiastic about accepting payments in cryptocurrencies in 2012 than now. But now they call it âstore of valueâ, fight with the money printer and like that. Enemies are everywhere.
Here you can only sell lower than you bought because the value decreases constantly.
No. This depends of the balance of supply and demand and generally is unpredictable.
No one knows this for sure. HTTPS is not forbidden yet but it can be depended of the political situation.
I doubt. Yes, fixed-supply dogmatics are great nuisance and Grin is better here. But I doubt that scheduled emission are even good for a good currency. With that the emission rate doesnât correspond to the demand. Now we have high emission rate in Grin while the demand is low as usage fo the wallets is hard, lack of exchange and overall ecosystem immature. Itâs better to have low emission rate at this time. And letter with more mature software and ecosystem when Grin becomes more accessible for newcomers emission rate will became lower. And in some point in future emission rate will fall to the numbers not very different from that fixed supply coins. That is what I want to say. Grin monetary policy is better only when we compare it with monetary policy of Bitcoin or similar coins. But better currencies are yet to come. Governable emission is very undervalued in the crypto space.
Oh, thatâs good! But the new website design are much less yellow than the previous I am dare to notice.
Grin has basically everything it needs to become something meaningful in the next decade
I hope there will be a place for Grin in the multi-asset âinternet-of-currenciesâ in future.
2 Likes
- Iâm not in favor of removing Tor transactions. The sender can transfer his slate via Tor and then the receiver has to accept and post it. Maybe Iâm missing something but I see no conflict here (assuming no finalize step).
- Yep asking for a password/passcode/fingerprint when receiving is not a big deal in my opinion.
Asking for a password makes tor transactions nearly impossible. The user only has a second or 2 to type the password or the tor http request will drop.
Also, how would a store that accepts grin scale if manual acceptance is required?
EDIT: Ah, you meant when thereâs no finalize step. Yea, I guess tor could still be used along with requiring passwords if we do that.
Not for a fiat currency. But itâs the only sane choice for a decentralized crypto currency.
But we do. We have low emission all the time.
Only one per second!
How low would you want it at this time?
Because manual acceptance is not a consensus rule but a wallet rule. Iâd like it to be the default for most wallets, but seems like wallets could make it automatic if they wish, correct me if Iâm wrong.
2 Likes
Sure, but then the security claim is no longer true for those folks. Stores and other services that choose to go this route would no longer have the benefit of cold storage, and would be required to have their keys decrypted in memory at all times. And itâs highly impractical to just expect grin-accepting stores (just as an example) to hire someone to accept transactions 24/7 by continually unlocking their offline hardware wallet or cold storage device anytime a purchase is made. Their keys would be much safer when using a currency with non-interactive txs.
1 Like
But inflation changes. I am more concerned for the future when it drops to a low rate. Maybe tail inflation about 4% would be better. The number is purely empirical, Dogecoin has inflation like this for years, Bitcoin had it before the last halving.
Initial supply need to be distributed somehow. In a pure minable coin the only way is to mine with high inflation. But some soft of slow start is what I want to see. First 3-4 years are needed for building initial software, wallets, tools, ecosystem and integrations into exchanges as well. A monetary policy based on logistic curve + tail inflation or like that.
And if it is not than coin with it will be replaced in free competition. I think itâs a mistake which Satoshi did. Fixed supply is good for a fixed-size community, e.g. population of a country. Cryptocurrencies have small communities of enthusiasts from the start and grow with the time. Then they need an efficient mechanism of value redistribution toward new people. And in cryptocurrencies we have only mining rewards and fees. Without ability to scale monetary supply cryptocurrencies are trying to scale with number of new coins using the cryptocurrency market itself as the main mechanism of redistribution.
The protocol doesnât care about how you facilitate interactivity. The protocol is pure and simple Mimblewimble: minimal and lightweight.
The security burden is a problem, sure, but Iâm not aware of any alternatives. Furthermore, that doesnât take away from âminimalâ and âlightweightâ. The two words arenât just placeholders for any positive thing you can think of.
Iâve heard you say this before, but I have probably 4 payment apps (the biggest ones in the world afaik) and none of them operate this way.
1 Like
You missed my point @johndavies24. Iâm not saying this is the best or most popular UX flow, but I am insisting that itâs a completely viable one.
I do not see it as a viable solution. Most of my payment apps do keep the transferred money in a separate account and I have to trigger it to go to my desired bank account (they may have an option to have this happen automatically now, not sure). So in a way, it is sort of like you say, but from a practical standpoint the money is mine immediately with no intervention from me.
I am not against this being an option but it should not be forced or default imo. Maybe a child wallet for auto received txs. It would also be interesting if receive keys could be separated from spend keys but I am not sure how that could be done, especially not in a minimalistic way.