Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 13 2019 08:02
    @jaspervdm banned @matrixbot
  • May 06 2018 21:29
    User @ignopeverell unbanned @maesitos
  • May 06 2018 00:41
    @ignopeverell banned @maesitos
Yeastplume
@yeastplume
yep, sounds good
Ignotus Peverell
@ignopeverell
@yeastplume rest of the code looks just fine actually
Yeastplume
@yeastplume
great, I'll just make the changes to that struct then and you know when they're in
Alec Spier
@glitchdigger
    sup you guys
is there a testnet?
Ignotus Peverell
@ignopeverell
@glitchdigger not quite yet but going there little by little
sifr-0
@sifr-0
@apoelstra @yeastplume Thanks for your responses. I'd just like to add one more bit concerning the blocktimes. Even if pools allow clients to produce blocks I would argue that is not sufficient as it only addresses on of the problems. It may solve decentralization of block production, but a pool is still a centralization of hashing power. An malicious third party or government agency can easily have a pool taken down or DDOSd. Performing such acts on solo miners is far more expensive. I would argue that solo miners are strictly the best miners. In every objective measure they are better for the network than a pool miner. The health of the network relies on decentralized hashpower which cannot be censored. Discouraging solo mining via long blocktimes I fear will lead to a less secure network. I believe this may be a real concern for grin because if it offers true anonymity then it will certainly play host to transactions which governments would like to scrutinize.
sifr-0
@sifr-0
I've seen no mention of Proof of Stake anywhere in grin documentation. Is it safe to say that grin has no plans of going to proof of stake, fully or in hybrid fashion such as Decred?
Andrew Poelstra
@apoelstra
sifr-0: that is very safe to say
sifr-0: regarding "centralization of hashpower", that is not what a pool is either, a pool only centralizes payouts
if a pool is ddos'd it takes basically zero effort for the actual hashpower to switch to a different pool or to solo mine
Yeastplume
@yeastplume
This is probably just going to amount to a lot of stupid, but I’m considering the paper wallet problem, i.e. the fact that cold storage of any kind is going to be so unwieldy as to be unusable, cause you’ll need to update your offline storage with new amounts every time you send/receive anything.
Andrew Poelstra
@apoelstra
any ideas are welcome on that front, don't worry about sounding stupid :)
Yeastplume
@yeastplume
Heh, well, in ignopeverell/grin#28 if I read it right, I think the discussion seems to indicate that the only way to do cold storage in MW is to allow the amounts to be brute forced by iterating with transaction keys over the entire UTXO set, and since there’s potentially 8 or 10 sig digits per currency unit and a who knows how bit UTXO set, this would quickly become prohibitive. So the only way to allow cold wallets is to somehow reduce the search space that a wallet needs to brute force through. One suggestion is denominations, I’m not entirely clear on what that means, I’m guessing means that you reduce the values allowed in an input/output to known divisions, like a “quarter” at 0.00000025, etc, which seems limiting but weighing that against the need for cold storage might not be such a bad thing... however
Andrew Poelstra
@apoelstra
oh, that's a simpler problem than what i was thinking about..
i didn't see this bug, this one is easy ;p
Yeastplume
@yeastplume
What's the solution? I was thinking that since there’s communication between both parties anyhow, would it not somehow be possible for the receiver to indicate he wants the transaction structured in a certain way in order to reduce the space that needs to be brute forced through?
Andrew Poelstra
@apoelstra
if there's communication then that isn't cald..
old
Yeastplume
@yeastplume
What's the problem you're thinking about?
But I meant communication before the transaction is finalised
Andrew Poelstra
@apoelstra
how do you send money to a cold wallet when the cold wallet has to produce the outputs for you
yes, a cold-wallet in bitcoin doesn't communicate with anybody at all, except when redeeming coins
Yeastplume
@yeastplume
No, I didn't mean sending the money to a cold wallet, I meant as the transaction is being created, manipulate the blinding factor or transaction set somehow to make it easier for the recipient to identify later assuming he loses the amount, i.e. only has the private key that can be generated from cold storage
Andrew Poelstra
@apoelstra
oh yes, i posted on the github link how to do that
it's easy to encrypt stuff to yourself in your own rangeproof
and it's easy to detect your outputs by fixing the key for a specific digit
(it would be even easier with unconditional soundness where you have a key that's independent of the value)
Yeastplume
@yeastplume
ah, very good, I see that now
so what's the hard problem?
Andrew Poelstra
@apoelstra
the hard problem is sending coins to a cold wallet
without any online keys
MW inherently requires somebody prove ownership of transaction outputs, for those outputs to be valid
Yeastplume
@yeastplume
well, that seems to be a big stumbling block towards the claim of privacy in transactions, when you need to be running a wallet server somewhere in order to receive anything
Andrew Poelstra
@apoelstra
running a server isn't a big privacy block, you have to communicate with your counterparty anyway
you can improve network privacy using valueshuffle and tor (we believe)
Yeastplume
@yeastplume
Yes well... we can.. but the er... general public not so much
Andrew Poelstra
@apoelstra
if they can run a grin daemon they can run whatever protocol that supports..
Yeastplume
@yeastplume
Well, that's assuming you want the chain and the tech to remain the domain of the technical elite. Most people running bitcoin nodes don't have a clue how to do much other than download a file, install and run.
Unless you mean running all grin servers through tor as a default?
Andrew Poelstra
@apoelstra
that could be an option. i'm not really thinking about tor specifically, there is a lot of mix network research happening (the monero folks are doing some cool stuff i hear) and hopefully we will have a more modular darknet that is more appropriate for cryptocurrency
but morally, yes, that is what i'm suggesting
Yeastplume
@yeastplume
Yes, I think that's the right way to be thinking anyhow, you don't want to be handing out IP addresses or other easily geo-located data to people out of the box, it would be much safer if it went through some other protocol with tor-like privacy built in
matrixbot
@matrixbot
urza When you do transaction with someone in cash ($,€,..) you also need to meet the person and be both at the same place&time. We are used to sending btc to address without the recipient side even having to know about it, because that is how bitcoin works. But perhaps embracing mw/grin as equivalent of digital cash where both parties need to be online at the same time might not be such disadvantage as it sounds now, just because that is what we are used to?
Yeastplume
@yeastplume
I think it can definitely be played up as a feature.. it also helps in not sending money into black holes through simple clipboard attacks, etc
Andrew Poelstra
@apoelstra
well, ultimately you can use this model too in bitcoin. i think there's no need to frame this positively, most transactions happen such that both parties are online, the system is certainly valuable even without working well as cold storage
and this gives a simple answer to the people who ask fearfully "what if grin overtakes bitcoin?", i've met many
Yeastplume
@yeastplume
that's a lot of ifs before that happens
Andrew Poelstra
@apoelstra
lol, yeah
i think the pretty pictures in my slides gives a misleading impression of how complicated MW is and how much design work still needs to be done