Bitcoin Forum
September 19, 2018, 02:27:30 AM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Trezor developer coordination  (Read 7916 times)
jim618
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000



View Profile WWW
September 24, 2013, 02:57:06 PM
 #21

Agree with Mike that as wallets contain more information having a secure cloud backup/ sync would work well.

It helps with wallet recovery in case of loss of laptop too.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
1537324050
Hero Member
*
Offline Offline

Posts: 1537324050

View Profile Personal Message (Offline)

Ignore
1537324050
Reply with quote  #2

1537324050
Report to moderator
1537324050
Hero Member
*
Offline Offline

Posts: 1537324050

View Profile Personal Message (Offline)

Ignore
1537324050
Reply with quote  #2

1537324050
Report to moderator
1537324050
Hero Member
*
Offline Offline

Posts: 1537324050

View Profile Personal Message (Offline)

Ignore
1537324050
Reply with quote  #2

1537324050
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537324050
Hero Member
*
Offline Offline

Posts: 1537324050

View Profile Personal Message (Offline)

Ignore
1537324050
Reply with quote  #2

1537324050
Report to moderator
1537324050
Hero Member
*
Offline Offline

Posts: 1537324050

View Profile Personal Message (Offline)

Ignore
1537324050
Reply with quote  #2

1537324050
Report to moderator
stick
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250



View Profile
September 24, 2013, 03:18:42 PM
 #22

Remember that in future wallets will hold not only keys and labels, but also things like signed payment requests (receipts), micropayment channel state, info for dispute mediation and so on. Lots of stuff.

That's something we'd like to tackle on some of the upcoming BIPs. Basically it is just defining which path(s) in BIP32 tree will be used for various purposes (PGP, SSH, etc.). We can also change "Bitcoin seed" to "Meta seed" (or sth similar) in the HMAC call during initialization of the root to make sure we won't be mixing address tree with meta tree.

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
September 24, 2013, 04:38:08 PM
 #23

The right model is that the same private key seed generated by Trezor/your wallet is both used to control your Bitcoins and encrypt your wallet file (literally the .wallet protobuf generated by bitcoinj or other wallet equivalents).

You just wrote down my ideas :-).

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
September 24, 2013, 04:44:55 PM
 #24

Although it is mentioned in README.md of trezor-emu, maybe it isn't clear for non-pythonist:

Trezor-emu is using two modules which are not packaged yet - python-ecdsa and python-mnemonic. Please do following steps on fresh install of trezor-emu on RPi:


cd /home/pi/
git clone git@github.com:trezor/python-ecdsa.git
git clone git@github.com:trezor/python-mnemonic.git
cd trezor-emu
ln -s ../python-ecdsa/ecdsa
ln -s ../python-mnemonic/mnemonic


This is just a temporary solution, I'm working on accepting my patches of python-ecdsa into official release.

hivewallet
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


hivewallet.com


View Profile WWW
September 29, 2013, 06:22:24 AM
 #25

The right model is that the same private key seed generated by Trezor/your wallet is both used to control your Bitcoins and encrypt your wallet file (literally the .wallet protobuf generated by bitcoinj or other wallet equivalents). Once encrypted that file can then be uploaded to some cloud service, perhaps a P2P DHT run by the community. The files are only small. The public key (or hash of it) would act as the document name to let you redownload the wallet if you need it.

Mike, do you mean that users would maintain a small P2P filesharing network only for retaining backup copies of each others' encrypted wallets? We were thinking about an idea like that too. What do you think would be best, a tiny blockchain that is just a sticky ball of encrypted keys, or something more like DNS (and presumably keyservers?), with servers telling each other about/propagating new keys?

Hive, a beautiful, secure wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit.
Tweets @hivewallet. Skype us here. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1006


View Profile
September 29, 2013, 11:36:16 AM
 #26

Well I think the first stage would be to use existing cloud backup services rather than create a new distributed one. For instance uploading to Google Drive if you have a Google account is pretty straightforward and it eliminates any issues with needing to pay to make backups, etc.

A simple DHT could come later.
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
September 29, 2013, 12:06:09 PM
 #27

Mike, do you mean that users would maintain a small P2P filesharing network only for retaining backup copies of each others' encrypted wallets? We were thinking about an idea like that too. What do you think would be best, a tiny blockchain that is just a sticky ball of encrypted keys, or something more like DNS (and presumably keyservers?), with servers telling each other about/propagating new keys?

If wallets are being uploaded to a public network where attackers could get the encrypted data you'll need to make sure your users use a cryptographically strong password - at least 128 bits of entropy. Of course humans are awful at memorizing long passwords, so you'll have to make sure they write it down somewhere and back up the password.

But if they have a 128bit secret backed up, why not just use BIP32 private key derivation directly? That's sufficient to recover users' funds; the only thing such a backup could provide in addition to that would be metadata like notes. Given how important it is to keep your seed/wallet password backed up why complicate the issue with (to the user) confusing discussions of some kind of "cloud backup" service that'll just lead them to think their wallet is effectively backed up when it isn't?

stick
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250



View Profile
September 29, 2013, 12:13:18 PM
 #28

you'll need to make sure your users use a cryptographically strong password - at least 128 bits of entropy

If you've read the whole thread you would have learned that the plan is to use BIP32 - maybe a modified one, so the "metadata" tree would not collide with the main address tree. Smiley

Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
September 29, 2013, 12:30:29 PM
 #29

you'll need to make sure your users use a cryptographically strong password - at least 128 bits of entropy

If you've read the whole thread you would have learned that the plan is to use BIP32 - maybe a modified one, so the "metadata" tree would not collide with the main address tree. Smiley

Ha, fair enough.

So here's my suggestion: don't use the word "backup" anywhere when referring to such a feature. Describe it as something along the lines of "your transactions are being retrieved from the Bitcoin network" so the user never wrongly thinks the wallet itself is somehow being backed up.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1006


View Profile
September 29, 2013, 02:39:09 PM
 #30

Did you actually read the whole thread? The whole point of the scheme we're discussing is exactly so metadata does get backed up. Yes, it's not typically very important today, but it will become more and more so in future. It's not only labels but stored payment requests for receipts, transaction labels, micropayment channel states and so on. The metadata is likely to be important for filling out tax returns if nothing else. We don't want users losing it.

It also reduces the reliance on having big indexes of the block chain to do wallet restores. If somehow you lose your wallet file backups but not your Trezor-generated master seed, you either need a full blown index of the block chain, or to scan the chain which is slow. Ideally that only happens very rarely.
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
September 29, 2013, 11:21:41 PM
 #31

Mea culpa.

I put some thought into doing P2P data storeage awhile ago; if the data is encrypted you'll wind up having created a useful general-purpose data-storage service, so you might as well architect it to be a good one. Rather than thinking about "blockchain vs. DHT"(1) models at this stage, step 1 should be to decide on what you're going to use for spam control: bitcoin days destroyed is the obvious choice and is easy to prove (two merkle paths) and doesn't cost anything extra. Merkle paths are still kinda long, but the proofs can be discarded immediately. (and of course communications between nodes with full transaction indexes need not provide full paths)

1) Note how Freenet's weak anti-spam measure of retaining the most popular data and dropping the least doesn't work for a wallet backup system.

It's easy to define a consistent priority ordering for everyone's data by sorting all data in terms of (value*days destroyed)/size, or (value*days destroyed)/(size*data age) so that older data is eventually expired out. (these equations are all rough sketches obviously) People donating bandwidth and storage capacity to this scheme can now easily do so on a best effort basis and know that there is some rational way to allocate their donation. Because the ordering is consistent its also easy for nodes to advertise what the cut-off minimum priority is for the data they have in their store, thus making it easy to search for someone who might have your old data.

Building on stick's idea of a metadata tree for the encryption keys, I'd also suggest the use of a metadata tag tree whose values can be made public. That tree is then used to derive tags associated with each bit of data stored, so that queries can be later done for the tags in an efficient way to recover a wallet fully. Of course, this invites making those tags be pubkeys and allowing updates, but that means you've got to charge for update bandwidth fairly somehow - leave it for version 2 IMO.

Double-spending your priority is an interesting thing... in a chain-based system it's not possible, but with a strict DHT it might be. I'd suggest just sticking to an "everyone has all the data" model at first. The other thing you can do is commit to the data in the transaction itself, for instance with an OP_RETURN <digest> output or even deriving the nonce in the signature in part from the digest. Doing so publicly with OP_RETURN almost has a nice benefit: you can hold nodes to account for failing to return the data when queried in the "everyone stores the same data set" model; with some signed advertisements, queries and responses you can basically create a short fraud proof.

Except that doesn't work because there's no guarantee the data was ever broadcast... except in the case of the transactions themselves which are guaranteed to be public by virtue of being in the blockchain. So now rather than doing UTXO commitments, a complex and invasive change that may not be implemented anytime soon, you can do UTXO set search query fraud proofs. Basically you're just creating a system where some service claims they'll honestly return queries for all transactions/UTXOs with some H(pushdata) in them, like sipa's searchrawtransactions, and you can hold those services to account if they fail to return transactions that matched. Of course, this also means that system can be later extended to this data storage service if we (merge) mine it, although the lack of actual economic incentives is a bit troubling.

Andreas Schildbach
Hero Member
*****
Offline Offline

Activity: 483
Merit: 500


View Profile
October 02, 2013, 01:37:46 PM
 #32

A little update from my side: After realizing that my previous SD card had 32 MB not 32 GB Shocked , I finally bought a new card and installed Raspbian on it. And yeah, my raspi boots.

Now I wonder how do will Trezor setup be able to put its python software on the shield, given I do not have any network on the raspi.

Anyway... slush, I just read that python-ecdsa has been released. Does that change anything regarding the installation?
stick
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250



View Profile
October 08, 2013, 08:29:11 AM
 #33

Hi guys!

We created a mailinglist trezor-dev for developers on Google Groups which is a better way to discuss technical stuff than forum.

Subscribe at Google groups

or send a subscribe email to

trezor-dev+subscribe@googlegroups.com

to catch it all!

Jim: would you be so kind and lock this thread so we don't have two dev discussions going in parallel? Thanks!

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!