Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 22 16:14
    glemercier opened #3053
  • Sep 21 23:56
    shannon1916 closed #3041
  • Sep 21 16:57
    kamushadenes opened #3052
  • Sep 21 11:50
    antiochp commented #2880
  • Sep 20 18:10
    antiochp labeled #3051
  • Sep 20 18:10
    antiochp milestoned #3051
  • Sep 20 18:10
    antiochp edited #3051
  • Sep 20 18:06
    antiochp demilestoned #3038
  • Sep 20 18:05
    antiochp edited #3038
  • Sep 20 18:04
    antiochp edited #3038
  • Sep 20 18:04
    antiochp edited #3038
  • Sep 20 18:03
    antiochp edited #3011
  • Sep 20 18:02
    antiochp opened #3051
  • Sep 19 21:00
    antiochp commented #3034
  • Sep 19 20:33
    antiochp commented #3046
  • Sep 19 20:02
    antiochp labeled #3023
  • Sep 19 20:00

    antiochp on master

    DB v1->v2 migration (#3044) * … (compare)

  • Sep 19 20:00
    antiochp closed #3044
  • Sep 19 20:00
    antiochp closed #3043
  • Sep 19 19:57

    antiochp on master

    fix: Add some more stats to bas… (compare)

Mark Renten
@rentenmark
invalid peer ban issue mimblewimble/grin#2670
is there any limit on the number of inputs or outputs in a transaction that is explicitly enforced by the wallet?
jaspervdm
@jaspervdm
didnt find a relevant issue so created one for it mimblewimble/grin#2671
Mike Dallas
@mcdallas
Gary Yu
@garyyu
@jaspervdm mimblewimble/grin#2575 for your 2671
jaspervdm
@jaspervdm
oh
somehow i didnt find it when i was searching for it, closing mine
thx
oh i see its merged in milestone 1.1
David Burkett
@DavidBurkett
We’re still having issues with floonet. I can’t find any connections for new peers.
David Burkett
@DavidBurkett
@garyyu @jaspervdm Would either of you able to restart your floonet seed nodes?
jaspervdm
@jaspervdm
done
David Burkett
@DavidBurkett
Thanks!
Gary Yu
@garyyu
@DavidBurkett I checked one of my server and it’s only 42 peers and should be accessible.
David Burkett
@DavidBurkett
@garyyu Are you able to check the logs for 71.60.45.57? I’m wondering why I couldn’t connect to yours
Gary Yu
@garyyu
okay
11 lines of this:
20190311 22:43:50.282 DEBUG grin_p2p::serv - Peer 71.60.45.57:53504 banned, refusing connection.
David Burkett
@DavidBurkett
Hmm. Are you able to lookup the ban reason? That’s a grin++ node, so maybe I’m doing something sketchy
should be able to do a get on /v1/peers/71.60.45.57
Gary Yu
@garyyu

searched all the log files, no any other interesting logs about this banning.
And here is the peer info:

{"addr":"71.60.45.57:13414","capabilities":{"bits":15},"user_agent":"MW/Grin 1.0.2","flags":"Banned","last_banned":1552201414,"ban_reason":"None","last_connected":1552201226}

need look into the code and add more logs to find why, but can’t do it today, 11pm here :-)
David Burkett
@DavidBurkett
Thanks for your help @garyyu. Have a good night!
Gary Yu
@garyyu
welcome @DavidBurkett :smile:
Noah Yeh
@noahyeh_twitter
Guys remember tomorrow will be the first Grin Community Project Day, we’ll have 5 to 6 projects presenting their updates, 5 pm UTC at grin/ecosystem chat
valdok
@valdok
Hello grin team! Recently we discussed with @hashmap some aspects of the node synchronization. Recently we improved our synchronization scheme, in particular it supports now incremental cut-through (i.e. not from the beginning). Perhaps you'll be interested too. We've described it here: https://github.com/BeamMW/beam/wiki/UTXO-set,-horizons-and-cut-through
David Burkett
@DavidBurkett
@valdok So bascially you’re creating “light” clients (ie. don’t verify certain things like old rangeproofs) at the cost of needing archive nodes. Am I understanding that correctly?
Nevermind, looks like you’re maybe only removing bulletproofs from spent TXOs
David Burkett
@DavidBurkett
I think I fully understand the proposal now, but it has the downfall that your node may only be able to sync from certain nodes. We could always just make the Hi/Lo values part of the protocol, though. It would also require keeping an entire history of “sparse blocks” (basically just compact blocks), which we can probably just use our blockInputBitmaps to generate. Thanks for sharing @valdok
valdok
@valdok
Basically each node can sync with any other node that has adequate Lo/Hi horizons. And if we restrict it to just 2 most common configurations (archive and standard), then archiving are only able to sync with theirselves (once they're late by more than day), and standard will be able to sync with everyone else. And this does NOT require keeping the entire history of "sparse blocks" forever, it may be restricted to half a year or something similar.
David Burkett
@DavidBurkett
@valdok I would only expect archive nodes to ever only sync with themselves though. Why would that be a problem? As long as “standard” nodes can sync with all other standard nodes, isn’t that the best-case scenario?
Wait, maybe I’m not understanding something. Archive nodes that go offline for just 1 day can’t sync with standard nodes?
valdok
@valdok
They can't. Because standard nodes will "reduce" all the spent TXOs after 1 day since they are spent. If there's an UTXO that was created and spent within this window - the archive node won't be able to get the "original" TXO from the standard node
David Burkett
@DavidBurkett
So how are re-orgs beyond 1 day done? Do they have to re-download utxos?
valdok
@valdok
yes. Either re-download, or reset and download the new cut-through from the beginning. It's a problematic scenario indeed. But the even idea of cut-through is problematic if extremely deep reorgs are allowed
David Burkett
@DavidBurkett
Gotcha. I may need to read through again, but can’t at the moment. Are you normally on gitter? Or is telegram the best place to reach you if I have questions?
valdok
@valdok
I'm always on telegram. Checking gitter from time to time, but not systematically :)
David Burkett
@DavidBurkett
Ok, I will find you on telegram then. Thanks @valdok
Guy Corem
@vcorem
@DavidBurkett Telegram is better for immediate response.
valdok
@valdok
you're always welcome. Please feel free to ask and share ideas
David Burkett
@DavidBurkett
:thumbsup:
Michalis Kargakis
@kargakis

@kargakis if I set a "node port" for the grin p2p service, that applies to all nodes, correct? But that needs to be in the 30000->32xxx port range, right? Then I would need to figure out how to add some kind of forwarding rule from port 3414 to that nodePort?

yes, you should also be able to hardcode that nodeport @bladedoyle

I am not sure if it is supported in gcp but you may also be able to hardcode the node name in your pod so you are always getting deployed in the same machine
Ignotus Peverell
@ignopeverell
@valdok do you have stats on archival node vs normal node ratios on beam? just curious
I've love to have those for grins, as well as full sync vs partial sync frequencies
valdok
@valdok
@ignopeverell Stats on UTXO set, little outdated. Last time I checked there were 1,430,960 TXOs ever existed, from whom 355,590 were unspent. So we're talking about 25% of all the TXOs that are unspent. Regarding the local storage sizes - right now I can only roughly estimate. I believe it's close to 1:3 (something like 1.5GB archive node, 500MB standard node), since besides of UTXOs there are kernels, headers, and some overhead for indexing.
But don't forget - we're using decoy UTXOs when needed. So part of the created and spent UTXOs are probably due to the decoys. I'm curious now what is the ratio in grin, probably more than 25%. Am I right?
Ignotus Peverell
@ignopeverell
can't recall right now @antiochp had some stats last week but somewhat buried by now
David Burkett
@DavidBurkett
@valdok Finally got a chance to re-read, and I just have a few more questions. 1. Why wait until the end to verify? Couldn’t you just verify as sparse blocks come in?
valdok
@valdok
It can only be verified partially. Can verify kernels, and bulletproofs for those outputs that were not "reduced". But you can't verify the "overall arithmetics", proof that no value is created from thin air. You just can't verify this. Because "sparse" block may not contain all the original outputs!
jaspervdm
@jaspervdm
633k TXOs of which 44k unspent