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
Ignotus Peverell
@ignopeverell
maybe in the community section, you can have the github, gitter and mailing list links with icons
Fernando Lobato
@fernandolobato
For sure, I can do that and give some air to the decentralize section
Ignotus Peverell
@ignopeverell
@apoelstra I reserved mimwim.com/org/net some time ago just in case (somebody had already taken mimblewimble) if we wanted to do something with it
Andrew Poelstra
@apoelstra
oh, awesome ignopeverell
Ignotus Peverell
@ignopeverell
@fernandolobato and if there's any possibility to make that list less of a big blob, that'd be great
maybe some icon for each item and more of a tile layout instead of a bulleted thing?
@fernandolobato and thanks for the work, it's great! don't worry too much about the text itself, I can edit that easily after merging
Fernando Lobato
@fernandolobato
Perfect, will give you guys a heads up during the weekend. It's my pleasure, I really like this project
Ignotus Peverell
@ignopeverell
thanks!
lkblkb
@lkblkb
@fernandolobato I do English writing for a living. Let me know if I can help with proofreading/copy writing!
I can also access people who can do a Chinese version 😁
Ignotus Peverell
@ignopeverell
@lkblkb a Chinese version would be cool after this
Andres G. Aragoneses
@knocte
apoelstra: why reusing keys is much more dangerous in MW than in BTC?
reusing keys is very important if you want to publish a well-known address and keep receiving payments in it, without the need to tell your peers to update the address everytime (e.g. Bitwage)
Andrew Poelstra
@apoelstra
you basically can't do that in MW
and for privacy reasons you sholudn't be doing that anyway
anyway if you do reuse keys your spending transactions could be vulnerable to replay attacks
because outputs aren't connected to anything, there's no unique txid to reference them by, so if you make the same one twice, the original spending transaction can spend the second one
Andres G. Aragoneses
@knocte
well, shit, why? cannot grin use a count like ETH does?
Andrew Poelstra
@apoelstra
no, that wolud completely undermine the pruning that MW offers
and it's also a shitty idea for privacy
and it leads to weird things like transaction ordering mattering
Andres G. Aragoneses
@knocte
isn't "transaction ordering mattering" needed anyway to avoid double spends?
Andrew Poelstra
@apoelstra
no, i'm talking about ordering of otherwise-valid transactions
Andres G. Aragoneses
@knocte
I see
then it's going to be a challenge for wallet developers
Andrew Poelstra
@apoelstra
yes, it will be
such is life with MW
if you do everything via payment protocol it's not so bad, it's basically the same as bitcoin
but cold wallets are a bear
Andres G. Aragoneses
@knocte
cannot the replay attacks be prevented seriously? adding a timestamp and making the transaction be valid only for some hours for example?
Andrew Poelstra
@apoelstra
yes, if you put timeouts on transactions that would block replays. that's a really nasty solution, there's a reason bitcoin has endeavored to never make a mechanism that let a valid transaction become invalid (except doubl-spending it)
it basically makes every transaction non-reorg-safe, like coinbases are
and creates incentives for miner censorship in same cases
Andres G. Aragoneses
@knocte
mmm
Andrew Poelstra
@apoelstra
it's also an incomplete solution if your payments aren't always very spaced out
Andres G. Aragoneses
@knocte
how about making it opt-in? for recurrent payments you use an address that has timelocks, but for the rest (change addresses), it's default and replayable
(just thinking out loud)
Andrew Poelstra
@apoelstra
that wolud be impossible, it would still break MW pruning
Andres G. Aragoneses
@knocte
mkay
Andrew Poelstra
@apoelstra
you can't put any conditions on outputs except what you can encode in their EC keys
(or things that stop mattering once they're spent, like them being non-negative)
Andres G. Aragoneses
@knocte
how about making it impossible to send money to an address that has received money before? would that also break pruning?
I guess those heuristics should be rather implemented at the wallet level?
Andrew Poelstra
@apoelstra
yes, it would require everyone know about spent outputs
Andres G. Aragoneses
@knocte
but then, wallets would need to keep all history or connect to fat "txindex" servers that don't prune, :-m
Andrew Poelstra
@apoelstra
yes, and the benefit of all this infrastructure and inefficiency is that users are able to undermine the privacy of the system
such users shouldn't use MW, hopefully we will be able to sidechain to other chains that support such uses
Yeastplume
@yeastplume
So it's not just me thinking the need for the recipient to provide a blinding factor is going to be a bit of a hurdle... also, if you're running a wallet at a certain address, you're basically giving telling an attacker exactly where you're storing your private keys.
Yeastplume
@yeastplume
BTW if anyone's listening, transactions are only being written to stdout at the moment, I'm going to implement the http post directly to another wallet over the next day or so and submit another PR