Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 254. (Read 965789 times)
Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?
I'm not sure I understand the issue here. Can't the device simply show both amounts (output + fee), and the user confirms that?
To calculate the fee you need to know all of the inputs and their balances, because a fee is not stored in transactions, it is just sum(inputs) - sum(outputs).
There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.
Device stores variable of highest acceptable fee per kB, so transaction with higher fee will be rejected. This will have some reasonable amount pre-setted from factory, but there'll be an API to change it's value if bitcoin fees become bigger than this limit (of course the change will show warning message on the display and will ask for confirmation by hw buttons).
I'm not sure I understand the issue here. Can't the device simply show both amounts (output + fee), and the user confirms that?
There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.
Device stores variable of highest acceptable fee per kB, so transaction with higher fee will be rejected. This will have some reasonable amount pre-setted from factory, but there'll be an API to change it's value if bitcoin fees become bigger than this limit (of course the change will show warning message on the display and will ask for confirmation by hw buttons).
Quote
Does the device have any internal storage? What you could do is integrate the block chain sync process with talking to the device. As relevant transactions are discovered they are sent to the device which strips out the values of the outputs and stores them in its internal storage alongside the tx hash. Once all tx outputs have been spent the data can be deleted.
Unfortunately device won't have enough memory to store tx hashes and some other metadata. We're designing the device to have no arbitrary limits for transaction amounts and sizes.
However we're planning to do SPV validation of tx inputs (and storing fixed amounts of checkpoints in the device to speedup the process for next time), so maybe we can somehow use fees from these transactions to approximate this maximum acceptable fee for the future. Thanks for the idea, I'll think about it a bit more.
There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.
Does the device have any internal storage? What you could do is integrate the block chain sync process with talking to the device. As relevant transactions are discovered they are sent to the device which strips out the values of the outputs and stores them in its internal storage alongside the tx hash. Once all tx outputs have been spent the data can be deleted.
This increases internal storage required but reduces the need to send lots and lots of transactions to the device each time.
Does the device have any internal storage? What you could do is integrate the block chain sync process with talking to the device. As relevant transactions are discovered they are sent to the device which strips out the values of the outputs and stores them in its internal storage alongside the tx hash. Once all tx outputs have been spent the data can be deleted.
This increases internal storage required but reduces the need to send lots and lots of transactions to the device each time.
quick splashscreen for the little device if you want
no colors, sorry. just monochromatic black/white bitmaps. :-/
Edit- what do you think now
quick splashscreen for the little device if you want
no colors, sorry. just monochromatic black/white bitmaps. :-/
quick splashscreen for the little device if you want
quick splashscreen for the little device if you want
quick splashscreen for the little device if you want
We're actively working on the project and we're making progress on many details. You know, there's no linear progress. Every piece must be finished independently, then integrated to the final solution somehow. At this stage many pieces already work. It requires some patience to put them all together and then *bang* - we're done :-).
I'm working on RPi software prototype, Stick is preparing circuit and PCBs for custom device, Lionluck is preparing casing prototypes and optimizes them for mass production (next prototypes will be finally made from eloxed duralumin/aluminium, not from plastics
).
Our original deadline was to have working prototype on RPi in December, which was somehow fulfilled - I already signed transaction with deterministic wallet over protobuf/serial connection and broadcasted it to bitcoin network. Then I disassembled it again because I found better solution for transaction streaming. I also heavily refactored original code, to be more similar to MCU environment (single threaded, non blocking code in master loop). It also interfaces HW buttons and OLED display with fancy UI (if we can call "fancy" anything on 128x64 px viewport
).
So there's progress, but it is all under the hood. At this stage there's nothing breath-taking to show publicly, but nevermind - that time will come :-).
I'm working on RPi software prototype, Stick is preparing circuit and PCBs for custom device, Lionluck is preparing casing prototypes and optimizes them for mass production (next prototypes will be finally made from eloxed duralumin/aluminium, not from plastics
).Our original deadline was to have working prototype on RPi in December, which was somehow fulfilled - I already signed transaction with deterministic wallet over protobuf/serial connection and broadcasted it to bitcoin network. Then I disassembled it again because I found better solution for transaction streaming. I also heavily refactored original code, to be more similar to MCU environment (single threaded, non blocking code in master loop). It also interfaces HW buttons and OLED display with fancy UI (if we can call "fancy" anything on 128x64 px viewport
).So there's progress, but it is all under the hood. At this stage there's nothing breath-taking to show publicly, but nevermind - that time will come :-).
Sounds awesome, keep it up!
We're actively working on the project and we're making progress on many details. You know, there's no linear progress. Every piece must be finished independently, then integrated to the final solution somehow. At this stage many pieces already work. It requires some patience to put them all together and then *bang* - we're done :-).
I'm working on RPi software prototype, Stick is preparing circuit and PCBs for custom device, Lionluck is preparing casing prototypes and optimizes them for mass production (next prototypes will be finally made from eloxed duralumin/aluminium, not from plastics ).
Our original deadline was to have working prototype on RPi in December, which was somehow fulfilled - I already signed transaction with deterministic wallet over protobuf/serial connection and broadcasted it to bitcoin network. Then I disassembled it again because I found better solution for transaction streaming. I also heavily refactored original code, to be more similar to MCU environment (single threaded, non blocking code in master loop). It also interfaces HW buttons and OLED display with fancy UI (if we can call "fancy" anything on 128x64 px viewport ).
So there's progress, but it is all under the hood. At this stage there's nothing breath-taking to show publicly, but nevermind - that time will come :-).
I'm working on RPi software prototype, Stick is preparing circuit and PCBs for custom device, Lionluck is preparing casing prototypes and optimizes them for mass production (next prototypes will be finally made from eloxed duralumin/aluminium, not from plastics
).Our original deadline was to have working prototype on RPi in December, which was somehow fulfilled - I already signed transaction with deterministic wallet over protobuf/serial connection and broadcasted it to bitcoin network. Then I disassembled it again because I found better solution for transaction streaming. I also heavily refactored original code, to be more similar to MCU environment (single threaded, non blocking code in master loop). It also interfaces HW buttons and OLED display with fancy UI (if we can call "fancy" anything on 128x64 px viewport
).So there's progress, but it is all under the hood. At this stage there's nothing breath-taking to show publicly, but nevermind - that time will come :-).
Any updates slush? Sorry for being impatient but I'm really eager to see this being finished and sold to end users 
ripper234, World, thanks for links, lot of useful information inside.
Yeah I guess I'm getting a bit ahead of myself here
At least its open hardware so we can make all kinds of insane things with it.
maybe on the Hardware wallet 2.0 At least its open hardware so we can make all kinds of insane things with it.
interesting video have look time 16:30 Digital Money - Panel Discussion
Yeah I guess I'm getting a bit ahead of myself here
At least its open hardware so we can make all kinds of insane things with it.
maybe on the Hardware wallet 2.0 At least its open hardware so we can make all kinds of insane things with it.
interesting video have look time 16:30 Digital Money - Panel Discussion
Slush/everyone,
I haven't been following the thread, but I suggest you take a look at this 5 minute video about "Crowdtesting" (a cross between Kickstarter and A/B testing) - it might fit the bill.
I haven't been following the thread, but I suggest you take a look at this 5 minute video about "Crowdtesting" (a cross between Kickstarter and A/B testing) - it might fit the bill.
Interesting.
From the "a few non-obvious things you want to keep in mind when launching a crowdtesting project" section on that page:
Quote from: http://customerdevlabs.com/2012/12/02/crowdtesting-using-crowdfunding-kickstarter-test-an-mvp/
Don’t sell your story. A lot of consumers support crowdfunding projects not because they want the rewards, but because they want to support the person raising the money. You don’t want that. You want people pre-ordering your product because they want it so badly, they’re willing to put down money early, to ensure it gets made. Avoid talking much about yourself during the campaign and instead focus on the value prop – that’s what you’re trying to test.
Slush/everyone,
I haven't been following the thread, but I suggest you take a look at this 5 minute video about "Crowdtesting" (a cross between Kickstarter and A/B testing) - it might fit the bill.
I haven't been following the thread, but I suggest you take a look at this 5 minute video about "Crowdtesting" (a cross between Kickstarter and A/B testing) - it might fit the bill.
Yeah I guess I'm getting a bit ahead of myself here
At least its open hardware so we can make all kinds of insane things with it.
At least its open hardware so we can make all kinds of insane things with it.
Jump to: