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
jaspervdm
@jaspervdm
yeah, to generate the same proofs the utxo state would have to be rewinded to the one from that block, which I think is quite a bit of work (not sure on this). I'm not sure if this is planned to be implemented. Another option would be to rewind it a 1000 blocks only and generate proofs at that height (for the ones that exist at that point) so that at least old outputs are immediately spendable
yuntai
@yuntai
hmmm not sure i understand. isn’t mekrle proof for a particular output keeps changing every block as UXTO set changes?
should be able to retreive the block height from an output’s pmmr pos? otherwise relative lock can’t be implemented..
yuntai
@yuntai
ah i mean (non-relative) time lock..
yuntai
@yuntai
perhaps make wallet client downloading all blockheader and make node return output along with pmmr index to figure block height, when restoring?
Yeastplume
@yeastplume
merke proofs are removed from T3 anyhow
yuntai
@yuntai
ah it’s easier for a node to just return outputs with blockheight.. but it would be still heavy downloading all outputs? any plan related to bloom filter kind of stuffs and how?
jaspervdm
@jaspervdm
oh they are removed on testnet3? good to know
Ignotus Peverell
@ignopeverell
@lehnberg we have 4 planned hard forks at each 6 months increment after release, after that we'll have to get people on board
lehnberg
@lehnberg
@ignopeverell ah, right! What’s the difference between these planned hard forks and situations occurring after that? Wouldn’t we need to “get people on board” for the planned ones too?
Ignotus Peverell
@ignopeverell
the planned ones are already built in and the hard fork is forced, current code expects a block version update
Ignotus Peverell
@ignopeverell
@yeastplume looking at mimblewimble/grin#1214 too now
Yeastplume
@yeastplume
cool, hope there’s a relatively simple workround, but couldn’t see one myself
Ignotus Peverell
@ignopeverell
yeah it might need some rework, trying to see what makes the most sense
lehnberg
@lehnberg
@ignopeverell understood. :+1:
pomomoh
@pomomoh
Hi all. Only discovered Grin yesterday. Cheers
Blade Doyle
@bladedoyle
Hello @pomomoh Welcome to the party
pomomoh
@pomomoh
:-)
Alexander Liegl
@alexanderliegl_twitter
Howdy, big fan of grin. fyi, just came across this: https://www.beam-mw.com/
not endorsing the link, just thought people should now there's competition out there
Ignotus Peverell
@ignopeverell
@alexanderliegl_twitter interesting, thanks
Alexander Liegl
@alexanderliegl_twitter
np
Chris Wessels
@chriswessels
Not much info available on it
lehnberg
@lehnberg
This is what I managed to put together from the position paper & Telegram group:
  • Written in C++ from scratch.
  • Blocks are mined using Equihash PoW.
  • Emission rate using “periodic halving”.
  • No ICO or pre-mine.
  • 20% of block mining rewards for the first five years goes to the Beam Growth Pool to incentivise development and promotion.
  • Public Testnet launch in September (upon which code will be released).
Alex Romanov
@BigRomanov
Hi. My name is Alex and I am a CTO of BEAM. Will be glad to answer any questions.
François
@mably
Hi Alex, what do you think are the main advantages of BEAM over Grin?
@BigRomanov ^^
John Tromp
@tromp
i guess they see finite supply as an advantage
Alex Romanov
@BigRomanov

Don't know if I would call this advantages, I prefer a more conservative term differences.

We are implementing MW from scratch in C++, using the most tested and reliable libraries out there.

We use Equihash and have capped emission using halving.
Our architecture is different in some aspects, especially regarding the node logic, UTXO tree representation and use of Merkle proofs.
François
@mably
Ok, do you feel like BEAM is superior in some way?
Or just slightly different?
If it's just slightly different, don't you think it's a bit of a waste of time to work on BEAM instead of helping the Grin project?
Alex Romanov
@BigRomanov
We believe that MW is a very strong and elegant protocol that allows creation of confidential transactions wihtout the tradeoff of complexity or blockchain size and are working hard produce a best possible implementation of it.
Our decision to implement it ourselves were made based on both technological and economic considerations.
François
@mably
Had you heard of Grin before or did you started working on MW even before Grin existed?
Alex Romanov
@BigRomanov
We found MW when we were researching solutions in privacy and confidentiality space. We were aware of grin before we started our implementation.
jaspervdm
@jaspervdm
Why did you make the decision to start a new implementation instead of contributing to Grin?
Alex Romanov
@BigRomanov
As I have answered above, our decision to implement it ourselves were made based on both technological and economic considerations.
lehnberg
@lehnberg
What do you mean by economic considerations?
@BigRomanov ^^
jaspervdm
@jaspervdm
Somehow I missed that message, but the answer is really vague
Alex Romanov
@BigRomanov
We think that limited coin supply is more suited for store of value use case, similar to bitcoin
John Tromp
@tromp
you're asking the same questions of beam that bitcoin ppl asked of us:-) why start a new altcoin instead of contributing mw to bitcoin?
although admittedly the differences between grin and beam are much smaller
Alex Romanov
@BigRomanov
From technological point of view, we preferred C++ over Rust, and also we had some original thoughts about architectural and implementation details.
It was easier for us to assemble a team of experienced C++ developers which allowed us to release a working node and wallet PoC in only three month.
lehnberg
@lehnberg

@BigRomanov thanks! For the emission rate, were these thoughts raised in the Grin community?

For the C++ implementation, did you consider building an implementation of Grin in C++ instead, similar to Geth/Parity of Ethereum, or the Grin Go implementation?

Might be a lot of synergies made possible by having both efforts be part of a greater whole than what can be achieved by two individual efforts. (:

Alex Romanov
@BigRomanov
We are great fans of grin, and did not feel that mere porting to C++ would be of any benefit to anyone. We also wanted a freedom to experiment and take MW to different places.