Split Seed Revised
Edit (20th Jan): Just realised (maybe after resting properly yesterday), that a transfer of funds is not even required as with the initial setup below. All that's required, is that the full seed be decrypted after entering in the old key, and re-encrypted with the new key (derived from the new password - no part of the seed is dependant on the password any more with the new setup) and sent to the server to be stored.
This is better for users as they don't need to re-backup their full seed if they reset their password and if they've imported the full seed into another wallet, they don't need to do that again either.
Revision of the initial split seed mechanics here...
https://read.cash/@tibanne/split-seed-mechanics-39d15b5d
Our project has evolved quite a bit throughout the course of the hackathon based on various feedback. At the bottom of this update are our two new diagrams which resemble the current state of SplitSeed... which probably needs a new name now, as the seed is no longer being split. https://devpost.com/software/splitseed
Existing work included a very different version of the split seed scheme implemented into the registration and login flows of sharetip.me. https://sharetip.me/
Work done during the hackathon included recoding the registration and login flows to work with the revised version and then implementing from scratch the password reset flow including the generation of recovery PDFs.
EDIT: this is the only edit done below after submission time... "The main concern one should have when deriving the seed" -> "The main concern one should have when allowing the seed to be fetched and decrypted"
The main concern one should have when allowing the seed to be fetched and decrypted using entropy from a password is 1) the complexity of the password, and 2) whether the password or hash thereof has been exposed publicly by a hack on another website.
In our opinion there are a few ways to combat 2) to prevent malicious actors from taking advantage of people who've been pwned. a) Check if they've been pwned on registration and convince them to start using a password manager. b) On device change (using a device code stored in local storage and sent the the server to see if it's on a list for that user), make sure that you check they own their email by sending them a code or a magic link in addition to requiring their password.
To combat 1) we've used a client side javascript library to check if the password is of an entropy greater than a selected threshold.
Latest User Flow Diagram:
Latest Scheme diagram:
We look forward to feedback from this submission and it's the reason we entered the hackathon... to make this robust! Thanks for your time.
Split Seed Mechanics
Split Seed is a hackathon project with the goal of allowing an extra point of backup with minimal UX overhead. Namely, saving out half the wallet's seed words (**reset words**) on user registration so that they may be used to reset a user's password while retaining access to the user's funds. https://devpost.com/software/splitseed
Unlike the whole seed phrase, the half seed phrase can be stored conveniently as it does not allow someone who finds it access to the user's funds. Only when the half seed phrase is combined with access to the user's email, can the funds be recovered through a familiar password reset operation. The user flow follows:
This post steps through the mechanics of **registration**, **login**, and **password reset** under the Split Seed non-custodial wallet scheme. The scheme assumes that all client/server communication is done on a secured SSL connection.
For authentication, JWT and refresh token storage follow the setup outlined here to mitigate XSS and CSRF attacks. The diagram below shows a complete picture of the scheme: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/ https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Registration
The user supplies the email they'd like to use on the site. A verification email is sent to them with a tokenised link which sends them back to the site to enter their password.
When they set their password for the first time some setup is done to prepare the data that needs to be sent to the server:
1) Apply a slow hash with pre-generated salt to the combination of email and password.
2) Slow hash the result above with a different pre-generated salt to obtain a password hash which will be used to authenticate with the server.
The reason for the double hashing here is so that we can send the server `passwordHash` without giving it any information in `hash` which will be used to derive the first 12 seed words of our wallet's mnemonic (**reset words**).
3) Apply a fast hashing function to `hash`, and use half of the information in the result to derive the first 12 words of the 24 word wallet.
4) Fast hash the result above to obtain an encryption `key` which will be used to encrypt/decrypt seed data sent to the server. This key is stored in the browser's local storage so that data coming back from the server after a page refresh can be decrypted while the refresh token remains valid without inputting the password again.
5) Generate the second 12 words of the 24 word wallet randomly on the client. Anytime we have access to both these parts, we can construct the wallet.
6) Use the encryption key in step 4) to encrypt both 12 word parts. These will be sent to the server along with the user's email and `passwordHash` above to be slowly rehashed using a random salt and stored on the server.
This completes the registration process. After registering, the server returns a signed access JWT which is stored in memory and used to make authenticated requests to the server. The server also returns a signed refresh token which is stored as an HTTP only cookie, not visible to any client side execution, and sent to only one specific endpoint to refresh the access JWT.
Login or Refresh
Both login and refresh requests serve to fetch a newly signed access JWT and refresh token from the server along with the two encrypted 12 word parts. During login, the password is entered again and encryption `key` can be derived allowing decryption of the two 12 word parts. During refresh, the encryption `key` is fetched from local storage.
The two parts are then combined on the client to obtain the full mnemonic and create the client side wallet.
Password Reset
Great, we've reached the part for which this whole setup was created! When a user forgets their password, the standard practice is for the user to enter their email address and request a reset email. The sever generates a random token and embeds this in a URL which is sent by email to the user. The user clicks on this URL, and since the token in the URL matches the token in the database, they are known to be the owner of the account and are allowed to reset their password.
Usually, crypto services only suggest a user **write down offline** the full set of seed words that generates their wallet. If they fail to do so, and end up forgetting their site password, it's game over for the funds in their client side wallet. If someone finds the words, again, game over.
Using the Split Seed scheme, the first half of this word set is **downloaded by the user on registration and can be kept in convenient places** without concern that an attacker who finds access to them can access the funds in their wallet. Now, if the user forgets their password, they have the option to recover their funds by supplying these words during a familiar password reset. Or, if they happen to be on the same device, the `key` can be retrieved from local storage.
Once the encryption `key` is derived by hashing the first half of the word set, it can be used to decrypt both the first and second set of words sent by the server. The wallet derived from the user's old password can be regenerated and the funds moved to the wallet that is derived from the user's new password.
SplitSeed - a familiar password reset mechanism for non-custodial web wallets
Motivation
You're a regular Joe. You create an account on a crypto service with a non-custodial client side wallet. The service asks you to immediately back up your X word seed and recommends that this is done offline by writing down your seed words. You don't have time for this! You continue to use the service without taking this initial backup. Worse, you might copy and paste the seed and save it locally or snap a screenshot.
Time passes and something happens to make you forget the password you were using. Maybe you're not using a password manager yet and you didn't want to use the same password you've used in multiple other places because Chrome has started to tell you that you've been pwned through the lax security of others. Maybe you've upgraded to using a password manager but you forgot your master password. You can't log in and now your funds are irretrievable.
SplitSeed
SplitSeed is an attempt at solving this problem by creating a 24 word seed by combing two 12 word parts. The first part is derived from a combination of your email address and password and is never sent to the server. The second is generated randomly on the server during account creation and sent to the client to be combined with the first part whenever you log in.
On account creation, you're asked to stash the first part of the seed somewhere. It doesn't really matter how exposed it is, as without your password to login to the service, an attacker cannot take anything.
Now, if you forget your password, you can use a the very familiar email based password reset mechanism to change your password. During reset if you can supply the first part of the seed that you saved on account creation, the full seed that was constructed using your forgotten password can be reconstructed briefly and your funds can be moved to the location specified by the new password you provide.
Users can still opt to and should be recommended to save their full seed somewhere very safe.
CoinParty2020
I will be taking this concept through to a production implementation inside sharetip.me for the CoinParty hackathon. The registration and login part has been implemented already but the scheme has not been properly documented and vetted and the reset logic and UX has not been started. I'm hoping that the experienced panel of mentors at the hackathon will try to break the idea. If it still stands up at the end, then SplitSeed could provide a reasonable middle ground for lay people in the UX/security trade off.
Private tips and BCH's unsung hero
Most people like tipping in public. u/ErdoganTalk prefers to do it in private. I write this article about their activity with their permission.
To tip in private you send u/chaintip the URL of the post or comment you want to tip. Then you fund the relay address. Then the bot gives you a chance to write something about the tip you've just sent to the tipper (as you've not been able to do this publicly). Try it out by clicking this link: https://www.reddit.com/message/compose?to=chaintip&subject=PM+tip+request&message=REPLACE_WITH_POST_OR_COMMENT_URL
Private tipping is particularly useful on country based subs where it seems that the mods who controls these like to prevent regular bot functionality. And also obviously on r/bitcoin ;)
Here are some recent posts that they've tipped in private and, I assume, have also followed up with a custom personal message:
https://www.reddit.com/r/india/comments/im0j31/stock_market_aficionados_i_have_a_question_for_you/
https://www.reddit.com/r/Philippines/comments/ikgmsp/how_to_accept_international_payments_on_my_website/
http://www.reddit.com/r/Philippines/comments/ikii93/can_someone_explain_to_me_the_philippine_peso_and/
https://www.reddit.com/r/Philippines/comments/ikq741/pawnable_gold_resellers_on_ig_trustworthy_or_not/
http://www.reddit.com/r/india/comments/ikfm6z/foreign_inward_remittance/
http://www.reddit.com/r/Nepal/comments/ijuyr5/learning_investingtrading/
http://www.reddit.com/r/australia/comments/ikg9s1/bank_charged_me_for_drawing_my_own_money_is_this/
http://www.reddit.com/r/Kenya/comments/hq7hab/forex_trading_in_kenya/
http://www.reddit.com/r/Kenya/comments/ik33mp/matters_forex/
http://www.reddit.com/r/southafrica/comments/ijkng0/need_help_getting_shares_out_of_south_africa/
These were all sent this month (since the 1st of Sept)!
Here are a few recent comments that they've tipped this month:
http://www.reddit.com/r/lebanon/comments/ilvmpo/only_students_who_were_registered_in_schools_and/g3uzl8t/
http://www.reddit.com/r/iran/comments/ik7zwi/iran_currency_loses_more_than_half_of_its_value/g3k648t/
http://www.reddit.com/r/iran/comments/ik7zwi/iran_currency_loses_more_than_half_of_its_value/g3k2agv/
http://www.reddit.com/r/india/comments/ijwv65/gdp_contracts_by_239_in_june_quarter_compared_to/g3gjo8i/
A lot of the time, to people who already know what's up with the existing financial system and, I presume, letting them know about a way to side step it.
In total, u/ErdoganTalk has sent over 1500 tips in total (I generated this graph 2 days ago):
Most are between 3 and 5 dollars with a total count of more than 1 quarter of all chaintip use. All without taking any credit. This post is to give credit where it's due.
It's not only the number of tips or the total BCH spent tipping that's of value here. It's the time they take to find the people outside the BCH bubble that are most likely to see the benefit of BCH and ask them to download a wallet and see it in action.
**All contributions to this post will be forwarded to u/ErdoganTalk to give extra momentum to the great work they're doing**
p.s. this post isn't mean to discredit regular use of chaintip in any way, only to highlight what is not being seen by many. If others adopt this approach of spreading the usefulness of BCH, our community and the network effect of BCH will grow more quickly. Thank you to the other chaintip users and I'd like to give a shout out to u/AD1AD who as been publicly tipping a lot in subs other than r/btc.
A graph of the number of private (post or comment) vs public (null) tips is show below:
Ongoing discussion on dev funding
Context: https://www.reddit.com/r/btc/comments/etpkad/i_am_a_bch_miners_and_i_propose_a_white_list_of/ffi7weq/
... latest reply ...
Miner intention voting like that has never worked out well in the past. Look at what happened with segwit 2x. That was a binary decision in which miners majorly supported it, but they didn't choose to act on it later.
A list is something more complex... The only think I can think of is if there exists a public list somewhere (maybe on multiple sites so that it's not centralised) on which anyone can contribute to about their development endeavours which relate to BCH. These lists will allow miners to asses the validity of the claim of being a dev (proof of identity by linking to twitter or reddit also needs to be included). Then miners put their own list of who they see as possible deserving candidates of a dev reward in the block that they mine.
Now, the protocol can be changed so that 12.5% (or whatever people end up agreeing on) has to be donated to any dev reward address that appears in at least, say 7 of the last 10, blocks mined (these numbers can be debated). The list could be capped to something like max 100 unique addresses initially to avoid bloating the chain with scope for upping that later. If there are no addresses that appear in at least 7 of the last 10 blocks mined, then the block is only accepted if the BCH is sent to a designated hardcoded burn address. This should prevent miners from paying themselves. It will also allow miners to contribute to who they like as long as that person is in the 7 of 10 list for the block they are mining.
If the miners cannot agree on worthy devs that last 7 of the last 10 blocks, then the supply curve for BCH is slightly reduced and the eventual number of coins will be less (as many will be burnt).
Thoughts on the dev fund proposal
I'm all for trying to get money to devs. Many chaintips have gone to Amaury and others for their amazing contributions, and every time they do, I'm happy about it.
However, the proposed dev fund initially strikes me as a bad idea considering that a fund with centralised control is created reducing the decentralised nature of BCH.
If I'm not mistaken, if slightly more than 51% of the miners want this, it may get through but with a large danger to split the community... again.
If more (say closer to 75%) of the miners support this then just ante up the cash and leave the protocol alone. Who cares if 25% leech? The devs are still going to get 75% of what they would have if the change got forced through. An additional plus (on top of not having to change the protocol), the 75% actually get to individually assign where they think their capital should go and not some group outside their control.
Am I missing something? Is it difficult to coordinate this without introducing a protocol change?
We can sticky a thread on r/btc where devs who would like funding for their work/ future work, describe, and the miners who want to support them can tip them them publicly. People can see how much has been contributed to each. I'm not saying that this will work for sure, but it should at least be tried before this more drastic proposal.
Forcing the giving to be public will, IMO, make it more likely that all who agree to this donation effort actually give and don't back out. If someone is seen not to be giving publicly then they will be known not to be giving even though they have agreed to it. Chaintip could be used to record the giving publicly.
@tibanne
