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)

David Burkett
@DavidBurkett
Well for wallet, usability goals are just as important, imho
chisana
@chisa0a
no tying of IP to public address
David Burkett
@DavidBurkett
Can someone come up with the goals for node side?
Yeastplume
@yeastplume
agreed. We can start a document somewhere and give it all the time/attention it needs to really fill out the points
David Burkett
@DavidBurkett
What's a good medium for this? Just a wiki?
chisana
@chisa0a
maybe add to rfc24?
Yeastplume
@yeastplume
Maybe a draft RFC?
chisana
@chisa0a
or that :)
David Burkett
@DavidBurkett
Yea, that's fine. I can create one
Yeastplume
@yeastplume
Actually, might be a bit format at present, given the stage we're at
even a forum post that can be updated/edited in a bit more of a lightweight manner than an RFC for the moment
Let me think about it for a bit, if that's okay
David Burkett
@DavidBurkett
Sure, take your time
chisana
@chisa0a
wherever it ends up, I'm interested in taking part in the discussion
David Burkett
@DavidBurkett
of course, I'll PM the link to you in case you miss it
Yeastplume
@yeastplume
:+1:
chisana
@chisa0a
much appreciation
lehnberg
@lehnberg

Some discussion about lightning and relative time locks in the context of Mimblewimble on the Bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017309.html

However, I believe that Lightning and similar offchain protocols are not possible on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.

I do not believe it is the lack of SCRIPT that prevents Lightning-over-MimbleWimble, but rather the lack of relative locktime, which seems difficult to validate without knowing the individual transactions and when they were confirmed.

Are these assertions correct? I was of a different understanding.

David Burkett
@DavidBurkett
No, they're not correct. They assume everything is pruneable, but apparently don't realize kernels hang around
@antiochp Is working on adding relative kernels now, and disproving that last point
That's a Hell of a lot of typing and speculating from ZmnSCPxj without spending a minute or 2 to drop in here and just ask :)
lehnberg
@lehnberg
@antiochp perhaps you want to clarify in thread?
John Tromp
@tromp
i sent a reply to the mailing list which awaits moderation
i receive the mailing list as a digest, so it might be slightly garbled:(
> However, I believe that Lightning and similar offchain protocols are **not possible** on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.

MimbleWimble can easily incorporate relative lock heights, in addition
to absolute lock heights. Grin and Beam have included the latter since
launch.

Grin's proposal for relative lock heights is at [1] with discussion at [2].
Based on these, Grin also has a rough design for payment channels at [3].

Beam included relative lock heights in its recent HardFork [4] and has
a payment channel design at [5].

regards,
-John

[1] https://github.com/antiochp/grin-rfcs/blob/relative_lock_heights/text/0000-relative-kernels.md
[2] https://github.com/mimblewimble/grin-rfcs/pull/19
[3] https://gist.github.com/antiochp/e54fece52dc408d738bf434a14680988
[4] https://github.com/BeamMW/beam/releases/tag/beam-3.0.5654
[5] https://docs.beam.mw/laser_beam.pdf
John Tromp
@tromp
ah, it passed moderation...
Antioch Peverell
@antiochp
:+1: @tromp
Antioch Peverell
@antiochp
pretty sure Andrew might respond there as well seeing as it was his talk that this post is in reference to (and I believe he is at least aware of our proposal for relative kernels)
Antioch Peverell
@antiochp

Andrew not really selling MW there -

Historically, this whole adaptor signature business came out of mimblewimble and in particular the question of how to add scripting to mimblewimble. As soon as I came up with this idea, I brought it to bitcoin and forgot about mimblewimble. As soon as I could do it with bitcoin, I ran away.

:sadface:
lehnberg
@lehnberg
Haha, well fair enough
Nice reply @tromp!
Yeastplume
@yeastplume
just occurred to me that 'floonet' is far better as a name for a MW-specific overlay mixnet than what we're currently using the term for
lehnberg
@lehnberg
nm, was a joke, a very poor one
Quentin Le Sceller
@quentinlesceller
and it's gone @lehnberg :)
lehnberg
@lehnberg
so I deleted it
haha
Quentin Le Sceller
@quentinlesceller
@yeastplume but yeah Floonet is definitely a very good name for that, too bad we used it for testnet. But it's still possible to change that .
Antioch Peverell
@antiochp
it never really made any sense for testnet...
jaspervdm
@jaspervdm
yeah, but its harry potter related and has "net" in it so :) anyway repurposing that name now might be a bit confusing
lehnberg
@lehnberg

As part of the tx building research I’m doing, I’ve collated the most relevant papers I’ve come across in one place:

https://github.com/lehnberg/mixnet-and-acn-research

Very much a work in progress, contributions are welcome.

Quentin Le Sceller
@quentinlesceller
:rocket:
Antioch Peverell
@antiochp
Hey all - we just bumped the build version on master to 2.1.0-dev.1 to reflect the upcoming 2.1.0 release. So if anyone wants to help test some early stuff out then please build and run the grin node from master - https://github.com/mimblewimble/grin
We modified the binary serialization format of tx kernels (to be more efficient size wise and to be more flexible) so early testing of this will be really useful to ensure network compatibility. Thanks!
One thing to be aware of - this migrates some existing data in the local db from v1 to v2. This is a permanent change and there is no easy way of reverting the local db. So if you are likely to want to revert to the official build (2.0.0) and hope to keep your db data then I would hold off testing master right now. Or test on a new fresh node only.
lehnberg
@lehnberg

Just need to update the comments) but once that's in that's all we had for 2.1.0 done on the wallet side (other than the BIP39 entropy issue, which I don't think we're going to do anything about)

@yeastplume what’s the BIP39 entropy issue here?

minjimw
@minjimw
Is talk about rolling our own mixnet serious? Even considering Loopix seems laughable to me
Even being generous, the only overlay networks with some resemblance of being proven are Tor, I2P and Freenet. Of those, I2P and Freenet simply do not meet the UX requirements we have. So from my perspective Tor is the only option out of all overlay networks, and it is a good one at that
minjimw
@minjimw
And calling I2P and Freenet "proven" is arguable. I don't see how Loopix can be considered at all
chisana
@chisa0a
depends what the UX requirements are, and how strong those tradeoffs are against the security/privacy requirements