Wallet receiving clarification

Tech Support
#5

Transactions are indeed interactive. But if Tor is set up, it feels as if they are automatic yet you still get the properties of interactive txs (no on-chain addresses, can’t send coins into the void).

Slatepacks do make things much, much easier than they were before. There is also ongoing discussion in minimizing the number of steps users have to take (from send -> receive -> finalize to just send -> receive).

By the way, I don’t know why you opened a port as there’s no longer a need to do any port forwarding.

2 Likes
#7

Never used TOR before and haven’t learned about it yet. Have been putting it off for too long!

#8

Not much to learn really, just install it (and maybe add it to PATH). The wallet handles the rest. I can help if you want.

#9

I’m glad someone asked this. Thanks.

#10

I thought the same, but now i like the interactivity of it because i have a choice on weather or not I recieve money. Unlike bitcoin where anyone can send me money, be it dirty or clean money, and there’s nothing i can do to stop it from happening.

I may be wrong here, but in my mind grin transactions are analogous to passing someone bitcoin using an opendime (BTW Rodolfo Novak is super rad, and I love my collection of opendimes).

#11

For anyone who finds this thread, it seems it is a common discussion in the grin community. There is
a more in-depth discussion here that I found. Pep Talk for one sided transactions
I hope the developers will consider 1 sided txs.

1 Like
#12

I do also kind of enjoy the interactivity. It is like a hand shake. I think it is a little bit much for others unless it is somehow seamlessly integrated and they are unaware of the process. But then you are probably relying on a third party.

1 Like
#13

I think this interactivity of transactions allows for different if/then logic for the cryptospace entirely. I know this is abstract thought, i can’t quite wrap my head around why this ‘handshake’ (plus privacy, plus bitcoin) is important in terms of CS, but someone like Peter Wuille, Peter Todd, or Gregory Maxwell may understand how the interactivity could allow for new different applications. Anyway, the interactivity seems like its a majorly cool feature, not a bug or flaw, and we just can’t wrap our minds around why it’s so important just yet.

#14

I am also think so. Non-interactive one-side transactions which are prevalent in crypto space are convenient but inefficient. And this convenience is not free. Lightning Network is interactive, PayJoin is interactive. But the convenience of one-sided transactions make a gap for these applications and people don’t use them. Better UX for these applications and the underlying infrastructure can be developed by it’s much easier to start yet another blockchain project with regular wallet apps than to build a synchronous payment/financial overlay network. And and for it we pay with fees and lack of scallability.

I’d thought recently about something what can be called “Lightning DeFi”. Uniswap is the top gas consumption application on Ethereum. This is awesome how liquidity pools with automated market maker replace regular order-based exchanges. Buy Uniswap works entirely onchain, inefficient an unscalable. And such the app can be reworked into payment channel based. Why to use liquidity pools, when anyone can run software similar to Lightning Network node, but with several different assets, with a preferable AMM strategy to convert one asset to another, and earn on fees and slippage? End such system can be organically integrated in payment process itself. For example, Alice wants to tip Bob but has only Bitcoin and Bob wants to receive only USDT. Alice’s wallet just finds a path through a liquidity provider and pay in a single atomic transaction which is inter-asset as well as inter-chain. And with atomic multi-path payment Alice can aggregate liquidity from all the providers at the best price in simple “accept the payment invoice” workflow. And all the transaction fees, exchange fees and slippage fees will be combined in a single transaction fee which can be even hidden form the wallet interface as falls under fee threshold settings. A global scalable multi-asset payment network. But such network will require strong underlying synchronous messaging protocol, infrastructure and software.

MW/Grin is in an unique position here. For proper user experience Grin needs such communication protocol not only for applications like Lightning Network and PayJoins but for regular on-chain transactions too. And if a convenient way for non-interactive transactions were found Grin will be trapped by that convenience as any other blockchain.

1 Like
#15

I also see interactive txs as a feature. Bitcoiners want to have them to make payjoins possible. I’ve come to think that payjoins are a good thing to have and equally important, interactive txs may give a user full control over their wallet. Noninteractive txs only allow you to control what you move out from your wallet while interactive txs add a possibility to control also what moves into your wallet (we don’t do that now). I find it really weird that the whole space thinks partial wallet control is fine. I’d prefer to actually own a wallet in every meaning of the word. This would also get rid of dusting attacks and help mitigate utxo spoofing methods with payjoins. Also, since lightning is interactive, the UX of interactive txs will need to be solved somehow.

1 Like
#16

I like the idea of embracing the unique properties of Mimblewimble, and not adding baggage to try to make it into something it’s not. If we apply the same idea to the question of how to obfuscate the transaction graph, then we might come up with some aggregation services, as an alternative to Dandelion.

You would send your non-urgent transaction (by TOR) to an aggregation service that you trust (e.g. run by the core devs, or by David Burkett), and they would await sufficient aggregation (I think any number significantly larger than 11 would do:-) before being published.

Yes, there is a small risk that the aggregation service is compromised, and your original tx is visible to someone, but this is no worse than the current situation, and the there’s a good chance that the situation will be much better…

1 Like
#17

I agree. This sounds very similar to GrinJoin - @David what’s the status of that? Is it in operation currently? Over Tor? Is it opt-in? Do you have any usage stats?

1 Like
#18

:+1:t2:

I don’t disagree on this… but… at the same time, I can’t count how many hours we have invested giving support to Grin++ users from countries like China, because their addresses are not green (= available)… but the Censorship isn’t just in China, also Venezuela, Iran and other countries. Relying on third-party project (Tor) may not be ideal, we don’t know how many 0days are out there or which bridges are compromised by bad actors, also, bypassing censorship is getting harder and harder… but maybe that’s the only option we have right now. I’m pretty sure things are going to be better after the next HF, but also because of the effort @Paouky is doing documenting Grin, I’m expecting more people to get involved in grin soon.

Me too and I think is really important.

1 Like
#19

When Tor is not available, some other medium (like Dandelion stem phase) can perhaps be used to send a tx to an aggregation service.

#20

I’d really, really like to see an easy way to do Dandelion stem phase aggregation. If I wanted to do so right now (I do want) I’d have to ask users to enter my aggregation node as the only allowed peer connection. That’s the only way to guarantee I’ll receive their stem tx.

This UX hurdle basically the only thing holding me back from trying it.

#21

Have you looked at the Objective-Dandelion idea? I think it’s neat, but it might need some fixing because it’s more likely to give away the source of the tx with this modification. The issue is that the order of ‘stem path nodes’ is increasing in terms of ‘score’ so if you get a tx from a node with a low score, it’s likely they are the source. I think it can be fixed so it’s probably not a big issue.

#22

I killed the server. People are still struggling with basic transacting, so I didn’t like the idea of adding another obstacle to getting transactions confirmed.

When it was operational, it was opt-in and over tor. Usage wasn’t enough to make it worthwhile yet. There is less than 1 transaction per minute in Grin, so even if every transaction used GrinJoin, the server would have to wait 15-30 minutes to have any kind of meaningful aggregation.

1 Like
#23

@oryhp I have not yet, I will soon.

@david I think the only viable way to do aggregation with current usage is to make aggregation windows of 12 hours, even up to a week. My preference is 2-day periods. It could:

  1. Be fun (proof of concept).
  2. Allow for some graph obfuscation.

It would mostly be Intended for users to self spend, not for real economic transaction. If someone can point me to how it can be done with an easy UX (and not too complicated to build), I’d love to make it happen and maintain it.

1 Like
#24

The downside of fixed-size aggregation is that it could be effectively (although at some cost) undone by broadcasting lots of dummy transactions around the same time.

A fixed time window doesn’t suffer that downside. Perhaps it would make sense to have separate hourly, daily, and weekly aggregation servers, to accomodate different tradeoffs between speed and traceability.

#25

Yea, only time-based aggregation windows should be used. Fixed-size aggregation requires much higher fees to prevent dummies.

At this point though, running a coinjoin server is little more than an academic exercise. We know coinjoins are possible (in fact, trivial in mimblewimble). And nobody using Grin at these usage levels should expect any level of privacy. The best way to improve privacy right now is through increasing adoption or someone coming up with a clever crypto solution.

Starting up my GrinJoin server just creates more work for me with no practical gain. When we see more adoption, I’ll fire it up again.

2 Likes