Actually, compared to having bought your first on Jun 16th like me (when Bitcoin was around $110) it's not a better deal. If you're pricing in dollars, which they are not. I paid 1 bitcoin for a Trezor, when if I had ordered today, I could have paid 1 bitcoin for 2 Trezors. I assumed being an early supporter would offer greater benefit than being a late supporter. I was wrong. I thought Stick and Slush would be different than BFL. I was wrong. I'm done pre-ordering anything related to bitcoin. |
|
|
|
|
Stick and Slush, why did you take a page from the BFL playbook?
At the very last minute, with no warning, you say there will be a three month delay. Then, you offer new customers a better deal than your original supporters?
I guess our community needs a PR agency that accepts bitcoin, so you can be told "No, don't do that! It's stupid and you'll alienate your customers."
|
|
|
|
|
The Trezor alone can't protect against that attack, but the payment protocol can, and the Trezor already speaks the payment protocol, or an implementation is in the works. Can't remember which.
|
|
|
|
No. Not confused at all. Let's take an extreme example. Suppose one orders a 3 BTC Trezor when BTC are $33.33. They essentially paid $100. They can do nothing but sit and wait until the product is delivered. Delivered instantly, assuming your rates are the market rates, the buyer could turn around a sell it again for about 3 BTC.
Now suppose that they wait so long that 3 BTC at the time of delivery is $30,000. Can the buyer turn around and sell the unit for either 3 BTC or $30,000? Doubtful on both fronts. Or are you saying that you'll sell a metal Trezor for no less than 3 BTC for all time, regardless of was MtGox, Bitstamp, and Coinbase have to say about it?
Up to a point in time, the buyer assumes that risk that the BTC value with go up, and the seller assumes the risk that the BTC value will go down. The point in time is the promised delivery date. Now that it looks like we're going beyond that date, the tables turn, and the risk bearer ought to be the one who missed the deadline. In this case, it is the Trezor folks.
All of this is moot, as the buyer can easily negate this issue by repurchasing bitcoin after spending on the Trezor. |
|
|
|
October is comming to an end in 4 days, anyone received their Trezor yet? I'm pretty sure they haven't shipping anything yet, if they did, we would know about it. I understand that they are being quiet and don't want to be like BFL (two more weeks), but any news would be better than radio silence at this point. |
|
|
|
I would like to test the address before I trust it so I know it's really a valid key. But then I expose the public key and then I doesn't feel 100% secure because of that. This test shouldn't be needed if it was included in Armory because I trust that Amory doesn't fuck things up like I might do. If you have the correct number of bits, there is no such thing as an "invalid key". |
|
|
|
Now I feel really lazy but is there any simple way to do this? Any offline open source tools available to do this? Or how exactly do I convert dice results into a private key?
Can I ask why you want to use dice as a source of entropy? |
|
|
|
I would not trust that I got the information into /dev/random correctly and that Armory really picked it up. I would really appreciate some sort of user interface inside of Armory that allowed me to input dice results (In expert mode ofc).
Can't you just convert dice results to a private key yourself and import that into Armory? |
|
|
|
|
It's getting toward the end of October, is the plan still to begin shipping Trezors this month?
|
|
|
|
|
I know this is a long shot, but that's what I'm looking for. I'm willing to pay fair market value with bitcoin. I will only use a reputable community member or service for a 2 of 3 escrow transaction (I will pay the cost for this). I will travel to your location and pick the car up.
If you know of anyone that can help me secure a vehicle for bitcoin, let me know.
If you want to get a significant number of bitcoins without having to go through a KYC exchange, this could be a good way to go.
|
|
|
|
Let's do this! https://bitcointalk.org/index.php?topic=299684.0Please don't use it with large amounts of money yet. It's probably still chock full of bugs, but I've done quite a bit of internal testing and feel pretty good about the major features. Besides fixing the rescan-on-every-load issue, the feature set is frozen. I'd like to fix what's in it, rather than add anything new. A whole bunch of less-critical things (unicode fixes, message signing, tx size limits), will go into the next version (and that next version will not take 3 months to release  ). Please discuss bugs & general observations in that other thread, to not clutter this one!Can we run with a remote Bitcoin instance with this version, or maybe next version? I have a server which runs a persistent node and it would be great to only have one copy of the block chain (Armory's) on my main desktop. |
|
|
|
There's also going to be trust issues. Not necessarily. If users can easily force the device to generate a new seed, and there is some way to cryptographically verify the firmware on the device, the trust issues should disappear. |
|
|
|
It really isn't about what you can afford, it's about what you can do. If you're on a laptop with an SSD, you have 128GTB, maybe 256GB if it's a new one.
Sure that's enough for now.... but what's this 2TB you're going to plug in to your laptop and how is it going to work? You can't really compare the size of the blockchain in many years to hard drive sizes today... Anyway, with Armory storing its data on disk, you can run Bitcoin on another computer, so you're back to just 1x block data on your laptop. |
|
|
|
At the rate the bitcoin blockchain grows in size, 2.2x the growth worries me a lot more than 1x growth. It really shouldn't. Doubling the storage requirements is mathematically very little. If you can afford to store 10 GB, you can almost assuredly afford to store 20 GB. If you can afford to store 1 TB you can almost assuredly afford to store 2 TB. |
|
|
|
sweet or not, that price tag is ridiculous: BTC 0.45 a piece.
silver value: ~ 0.03 BTC = 6.7% of price
bitcoin value: ~ 0.1 BTC = 22.2% of price
markup: ~ 0.32 BTC = 71.1% of price
So the value you get by "recycling" the coin is roughly 29% of the price (even worse considering reseller pricing will have to be yet a bit higher and also shipping).
This percentage used to be close to or above 80%.
I was truly looking forward to reselling these coins, but frankly, Mike: that markup is preposterous and I'm going to have to let that business opportunity (if it is one to speak of at all) slip by. The 1/2 oz coins are ~48% (0.56/1.17) and the 1 oz coins are only ~64% (1.12/1.75). So while I agree the markup on these is higher, I don't think it's too far out of line with the others. It makes sense to me that smaller coins would have higher markup. |
|
|
|
I'm not 100% convinced of that. The issue is not slowness (well, it is an issue), but that these systems may be running out of RAM. For instance, it just can't be run on 32-bit because of the lack of address space. But if you virtualize a system that runs 64-bit OS with 16 GB of RAM (using 14 GB of disk), it may be possible to actually run it even though it takes 3 hours to sync.
I'd be interested to see someone try it, though I would bet 2:1 that it still doesn't work at all. But I can see why it might work. Can you run a 64 bit VM on 32 bit hardware? That doesn't seem right. Anyway, the original question was whether setting up a VM would help alleviate the problem of only have 2GB of memory, as the VM could "have" 64GB. The answer is of course no. |
|
|
|
Then repeat this mantra: " VMWare does not turn my PC into the computing equivalent of Doctor Who's more-capacious-on-the-inside space ship telephone booth "
haven't tried it, but when you're just talking RAM, a virtual pc should be able to have 64 GB of ram, with the vm actually having it as a file somewhere, no? i'm aware that it would be incredibly slow When your computer needs more memory than it actually has, Windows uses a file on your hard drive as virtual memory (Unix uses a swap partition). As you state, it's incredibly slow. So no, using a VM doesn't benefit you at all. |
|
|
|
I'll probably also need people to help with some testing this weekend I'd be happy to help test. Is there anything in particular you need, or do you want people to just start using the new version? |
|
|
|
See also the BIP32.5 thread on Bitcoin development. Here's the thread for anyone is like me, interested but not subscribed. |
|
|
|
|
Show Posts
