Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 13 08:02
    @jaspervdm banned @matrixbot
  • May 06 2018 21:29
    User @ignopeverell unbanned @maesitos
  • May 06 2018 00:41
    @ignopeverell banned @maesitos
Cameron
@da2ce7_twitter
I love the “techie” style of the text based gui. 👍 Really cool. - I think that for our first “Desktop Apps” will just be putting the text gui in a window (and support for tray icon, etc).
jorgeelmundoso
@jorgeelmundoso
what is the reasoning behind adding the http API code within libwallet?
lehnberg
@lehnberg
Is it possible to wrap a TUI into a native app? Would you need to run a whole unix shell for that?
Antioch Peverell
@antiochp
PR up to enable "kernel first" tx propagation by default - mimblewimble/grin#1971
this will only affect new nodes as this PR simply changes the default capabilities in the generated grin-server.tonl file.
If anyone wants to enable this on an existing node, you can change the capabilities "bits" from 7 to 15.
looking at the network we can see a healthy number of nodes (v0.4.1) that support this now
related - mimblewimble/grin#1969 we fixed a bug where peers were only looking for peers with the same capabilities as themselves, so if you're seeing any connectivity issues then upgrading to latest master should resolve it
jaspervdm
@jaspervdm
yes
lehnberg
@lehnberg
config file I believe
jaspervdm
@jaspervdm
change the config file
Antioch Peverell
@antiochp
run_tui=false or something similar
Guy Corem
@vcorem
OT but relevant: Zooko's lecture in devcon4: https://slideslive.com/38911617/privacy-for-everyone
François
@mably
7051 txs and counting: https://i.imgur.com/yXThPNb.png
Ignotus Peverell
@ignopeverell
good load testing
François
@mably
Let's go to 10k ;)
Ryan Zimmerman
@RyanZim
How many decimal places of precision does grin have?
Ignotus Peverell
@ignopeverell
@RyanZim 9
Ryan Zimmerman
@RyanZim
@ignopeverell Thanks!
mikhailivanovic
@mikhailivanovic
this is what I do in my free time... https://imgur.com/a/XjzzwOx Meme-away friends.
Ryan Zimmerman
@RyanZim
Somebody want to do a test transaction via the file protocol?
@tromp
GPU and ASIC mining algos being considered for zcash
(and a positive comment about Grin from zooko)
Captain Crypto
@kylanhurt
Anyone know what the upper-bound is right now for # of transactions per second?
Guy Corem
@vcorem
Twitter thread in reply to Fouda's article, relevant to Grin as well: https://mobile.twitter.com/vcorem/status/1062614097034969088
lehnberg
@lehnberg
@vcorem
  1. How much tx aggregation and cut through do you expect to actually happen through dandelion?
  2. What happens to the likelihood of coming across a node with a tx ready to merge with yours as the number of nodes grow?
  3. How do decoy transactions help to obfuscate the graph?
valdok
@valdok

Hey @lehnberg.

Basically we implemented the following logic: txs with less than 5 outputs MUST be aggregated, tx with less than 40 outputs MAY be aggregated.
So, when a Node receives a tx in the stem phase, it does the following: If more than 40 outputs - it's immediately relayed. If less than 5 outputs - it's delayed (up to some timeout). If num of outputs is between the thresholds - it's aggregated with some number of delayed txs that have "similar" fee/size ratio.
If the delay timer expires for a transaction - then it gets "decoy" UTXOs appended up to 5 outputs, and then relayed.
Every created decoy UTXO gets a timer, after which it would be appended as an input to another random tx.

So, regarding your questions:

  1. Tx aggregation would be very common. Actually they're involuntary.
  2. Don't fully understand your question. Basically all the valid txs that don't have mutual conflicts (double-spends and etc.) can be aggregated. And we check for conflicts, to prevent DoS attacks.
  3. Decoy UTXOs create a "background" fake activity, which overlaps with the real one, and (hopefully) should be hard to distinguish.
jaspervdm
@jaspervdm
Regarding number 2: if you increase number of nodes (and keep everything else constant), you expect there to be less aggregation. Adding decoys may mitigate that a bit but it will increase fees
valdok
@valdok
You mean having more nodes for the same Tx throughput- yes, you’re right
Antioch Peverell
@antiochp
Who "owns" those decoy UTXOs? How and when would they get spent?
Guy Corem
@vcorem
each node owns its, and will keep spending them forward
Antioch Peverell
@antiochp
And are you paying a fee to participate in this if your node is creating fake UTXOs?
Guy Corem
@vcorem
no.
Antioch Peverell
@antiochp
interesting - we considered variations of "decoy" outputs a couple of times, similar to this in some ways
does this open you up to potential spam/dos attacks? How do you prevent a node from generating large number of these UTXOs if there is no fee involved?
Guy Corem
@vcorem
The miners may decide to discard such Tx, if it's too huge and the fee is too small.
Antioch Peverell
@antiochp
ahh - the "per output" fee will decrease as the number of decoy outputs increases as the overall tx fee will remain constant?
but a mischievous node could maybe just keep adding a handful of new UTXOs every time they propagate a stem tx and grow the overall UTXO set - that seems problematic over time if enough nodes are misbehaving (and someone could spin up a lot of nodes with very little cost)
its interesting though
valdok
@valdok
The DoS is prevented by the fact that any node that is supposed to relay txs check that it's valid, and no conflicts arise when they're merged. Regarding spam - well, this is basically unavoidable, anyone can append anything, we can't stop this.
But with time, I believe, "misbehaving" nodes can be identified. In particular when you sent a tx and it gets bloated with too much decoys, or merged with tx with much lower fees - you can try to broadcast it to another peer next time.
lehnberg
@lehnberg
Thanks @valdok. Some follow up questions.
  1. What’s the distribution of # of outputs on transactions in general? Is there some kind of ball park number? How common do you expect it to be for txs to be below the <5 output threshold?
  2. With the upper bound rule of >40 outputs and you immediately relay the transaction, does that mean that a >40 output transaction would immediately expose the originating node's IP as there’s no stem phase essentially?
  3. If num of outputs is between the thresholds - it's aggregated with some number of delayed txs that have "similar" fee/size ratio. What does this mean exactly? Reading it, it sounds like the transaction is supposed to sit with the same node until it becomes aggregated with txs that have “similar” fee/size ratio? What’s the likelihood of that happening? Do these also get decoy tx attached to them if the delay timer expires? What’s the delay timer set to?
  4. If the delay timer expires for a transaction - then it gets "decoy" UTXOs appended up to 5 outputs, and then relayed. Is the delay timer identical for every transaction? Doesn’t that then make it trivial to identify the decoy UTXOs as they get appended?
  5. How do these decoy transactions behave? Are these UTXOs later participating as inputs for future decoys? Or are they “single use” so to speak? If the former, what’s the logic for selecting these decoy transaction patterns. More generally speaking, if there are discernible patterns to how these decoy transactions behave, how are you preventing chainanalysis algorithms from identifiying these?
valdok
@valdok
First, regarding the magic numbers - of course they are configurable, and right now are experimental, and not based on any serious research. It's just for starters, then, hopefully, we'll be able to tune them.
  1. Depends on the wallet strategy of course. But basically I believe most "native" txs would have 1-2 outputs. If I pay you, then you usually create a single output, and maybe I'll need the change. You wouldn't want to create several outputs without a good reason, since outputs are the heaviest tx elements wrt size.
  2. I meant - tx is realyed as usual, with about 90% probability in the stem phase, and 10% in fluff phase. It's just we don't want txs to grow to indefinitely-large sizes.
  3. Think of it as an avalanche (BTW ski season is coming, I just can't wait!). Small transactions are delayed, in a node. But once you get a large one - it just "flushes" most of them. Another way of looking at it - a chain reaction. Once a single tx reaches its "critical mass" - it's broadcasted, and collects many other txs on its way on all the nodes it is being passed throught. Until some limit, as we said.
  4. Delay timers are identical. But not to forget - we're talking about the stem phase. Then one that gets a tx from you most probably wouldn't know if/how much it had been delayed.
  5. Every decoy UTXO is (pseudo)unique. Just a commitment+bulletproof, exactly as all the others. After appending it to a tx, its creator (i.e. the node that created and appended it) puts a random timer (in terms of blockchain height) in some range, after which this specific UTXO is appended as an input to another random tx. End of story.
lehnberg
@lehnberg
Thanks valdok, I think I understand the approach better now.
@quentinlesceller question re our implementation of dandelion. I may not have understood it properly but if probability to stem = 90% and probability to fluff = 10%, without some upper limit, there will be instances where certain transactions take forever to fluff. Play enough times, there will be this tx that hits their 90% stem coinflip 1,000 times in a row etc. Our solution to this is the embargo timer basically? After 3 minutes the originating node falls back to default behaviour?
John Tromp
@tromp
@lehnberg try get 64 consecutive coinflips to come up heads
lehnberg
@lehnberg
@tromp sure. can I flip 1,000,000 times?
John Tromp
@tromp
that won't be nearly enough
jaspervdm
@jaspervdm
can i flip 1.8e19 times
but yea 2^64 is quite a big number