Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:54
    yeastplume edited #3667
  • 15:50
    yeastplume review_requested #3667
  • 15:50
    yeastplume edited #3667
  • 15:31
    yeastplume edited #3667
  • 15:23
    yeastplume edited #3667
  • 15:23
    yeastplume synchronize #3667
  • 15:17
    yeastplume synchronize #3667
  • 12:31
    yeastplume synchronize #3667
  • 11:05
    yeastplume synchronize #3667
  • 10:21
    yeastplume synchronize #3667
  • Nov 26 11:26
    yeastplume synchronize #3667
  • Nov 26 11:25

    yeastplume on master

    Fixmmr part2 (#3666) * use 0-b… (compare)

  • Nov 26 11:25
    yeastplume closed #3666
  • Nov 26 11:25
    yeastplume edited #3666
  • Nov 25 15:47
    tromp synchronize #3666
  • Nov 25 07:51
    tromp review_requested #3666
  • Nov 25 07:50
    tromp edited #3666
  • Nov 24 20:28
    tromp synchronize #3666
  • Nov 24 15:24
    yeastplume synchronize #3667
  • Nov 24 13:50
    yeastplume synchronize #3667
Nick Hansen
@nitronick600
ah, seems its been filed
Gary Yu
@garyyu

Find a small regression for "skip_sync_wait".
Please use this workaround in case you need use it:

git revert ea4407a9

will submit the fix now.

Aqua Chiang
@Aqua_Jiang_twitter
Hello
lehnberg
@lehnberg
Hi Aqua. Feel free to ask any technical integration questions you or your team may have here
alesito85
@alesito85
@lehnberg maybe someone could take a look at this issue mimblewimble/grin#2318 ?
David Burkett
@DavidBurkett
I’m not sure I understand Grin’s usage of the dandelion patience timer in some situations. When I implemented Dandelion in Grin++, rather than having a “Fresh” status that would then get updated to “ToStem” or “ToFluff” during the DandelionMonitor loop, I just perform the coin flip immediately upon receiving a stem transaction. Does that make me a bad person? Unless I’m thinking about it wrong, this means transactions will pass to the next relay patience seconds faster, on average, without sacrificing the number of transactions that get aggregated, on average.
To clarify, I don’t immediately stem or fluff a tx upon receipt. I only mark it as “ToStem” or “ToFluff” based on the biased coin flip.
@quentinlesceller and @antiochp, I believe you two worked a lot on our dandelion implementation, if I’m not mistaken, so perhaps either of you could shed some light on this?
Antioch Peverell
@antiochp
we use Fresh and then transition to ToStem or ToFluff so that the next loop will transition it to Stem or Fluff - that way we can be sure we only process each tx once (when its Fresh)
there are definitely different ways to do this though
in your impl if you immediately tag a tx as Stem how do you ensure it only gets processed once on the next loop?
David Burkett
@DavidBurkett
I tag it as ToStem, not as Stem. I just don’t wait patience seconds before tagging it.
Antioch Peverell
@antiochp
ah ok - give me a sec to think this through... there is a reason we did it this way, just don't recall exactly what it was...
David Burkett
@DavidBurkett
Cool. No hurry. Just let me know once you think of it. I can’t think of any advantage to waiting, but I obviously haven’t put near the thought into as you guys have.
Antioch Peverell
@antiochp
either way - this is likely only short lived as Dandelion++ changes how all this works pretty significantly
David Burkett
@DavidBurkett
O, so the plan is to implement Dandelion++ soon? Didn’t realize that
Antioch Peverell
@antiochp
I have a branch with some rough work on it - it actually simplifies our Dandelion code pretty significantly, just not ready for mainnet
a lot less timers and delays going on
David Burkett
@DavidBurkett
Nice! Looking forward to it.
Antioch Peverell
@antiochp
tl;dr full stem propagation can happen without any delay, all delay on the last node on the stem path (the one that aggregates and fluffs collected txs)
lehnberg
@lehnberg
@DavidBurkett some context & discussion: mimblewimble/grin#2176
David Burkett
@DavidBurkett
Ah, that would clean things up quite a bit.
Great, I’ll check it out. Thanks @antiochp and @lehnberg
Antioch Peverell
@antiochp
:+1:
Photon
@phooton
I was given some info about AMD inner workings and was able to optimize the OpenCL code (polaris 1 gps -> 1.5 gps, Vega 2.2 gps -> 3.3 gps) this puts AMD at (polaris) or ahead (Vega) of nvidia when it comes to power efficiency. Need to verify I'm not losing edges/cycles, code will of course be open source so that Grin can have healthy mining from day 1.
lehnberg
@lehnberg
wow!
Codeb Fan
@codeb2cc
Incredible
Yeastplume
@yeastplume
thanks @phooton .. I wish all solver developers behaved as you do
hashmap
@hashmap
@phooton amazing! will it change host - gpu interface or kernel intrenals only?
Photon
@phooton
It could be implemented either way, I will just go for safest way as there not much time left. But you will be able to change the code very quickly in any case
hashmap
@hashmap
@phooton ok, sounds like a plan!
John Tromp
@tromp
@phooton for checking loss of cycles, you can try my simple cycle stat tool
./cuda29 -r 1000 | perl ../perl/cycles.pl
is an example that i run in src/cuck*oo
btw, gratz on amazing efficiency boost!
once you verify no cycle loss, then please reply in my best GPU miner forum topic...
Photon
@phooton
I know I wanted to make proper detector, but no time... I'm just letting it run and as long as it converges to solution every 42 graphs I'll call it good enough for now
François
@mably
@phooton it will be interesting if you can get a hand on the new Radeon VII when it is released.
jaspervdm
@jaspervdm
Whoa great job @phooton
pk
@pkrasam
domo arigatou @phooton your GGM craftsman-ship will shine
vdorut
@vdorut
hi all , it's looks like this chan is better for my question
does anybody have build a docker-compose or just an images for the explorer ?
Hendrik Richter
@hendi
AFAIK there's no docker stuff for the explorer, but we've recently improved the instruction. Let me know if you need a hand or run into any issues
Mark Renten
@rentenmark
CRoaring rust library travis builds for windows and OSX coming to travis soon https://travis-ci.org/saulius/croaring-rs/builds/478257470 just a matter of time before we remove this blocker for windows builds of grin reference implementation
vdorut
@vdorut
@hendi i will
thanks for your work
Quentin Le Sceller
@quentinlesceller
@rentenmark that's great
Mark Renten
@rentenmark
@quentinlesceller thanks, I saw that the C library already had MSVC builds so I figured it was just a matter of getting the configuration right, still not sure about the GNU/windows target but it should also be possible
jaspervdm
@jaspervdm
awesome!
Yeastplume
@yeastplume
@rentenmark that’s great, I was just thinking I’d like to see a bit more focus on sorting out our windows issues soon