Maybe one day all people will use xbt for practical reasons, but until that day btc it's so much better.
I kinda liked the idea to use BTC for 1 Bitcoin, and XBT for 100 satoshis. That way trading / financial software can cope (only 2 decimals) with XBT. 1 XBT = 1 bit = 1 mBit = 100 satoshis 1,000,000 XBT = 1 BTC |
|
|
|
but, what will happen next?
the 1 million bitcoin question. |
|
|
|
I have a question (to devs or anyone else): I read trezor uses RFC6979 deterministic ecdsa signatures to prevent leaking of seed or any other private data through the "random" number used in non-deterministic signatures. I read that hereIs there an easy way to check wether this is true by looking at a transaction signed by trezor? I am not sure if BitcoinJ uses deterministic signatures by default and if they use the same pseudorandom function as described in RFC6979, but if both are true you can try importing TREZOR's seed into Wallet32 and see if they produce the same signatures for the same combination of privkey/message. Thanks, stick, for that description / suggestion. I will try this once I get my plastic trezors (I have my metal one in "productive" use now and don't want to fiddle with it). You can easily see that the signatures produced by TREZOR are deterministic, because they produce same result for same combination of private key/message (that's what we use in unit testing afterall ...)
Seeing they are deterministic isn't an indication against you potentially leeking seeds through the k value, is it? Even if you leaked seeds like that, signatures could still be deterministic. Btw: thanks again for an awesome product, I can't wait to give some plastics away to friends, who I can then finally offer a good method to store their BTC. |
|
|
|
The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used.
One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it. Please correct me if I'm wrong. I think you're wrong: the idea could be for the trezor devs to use k = <seed XOR some secret> in order to leak the seeds of people to the blockchain, visible only to them, of course. It's a potential attack by the trezor devs, not just anyone. |
|
|
|
it is extremely extremely BORING oh my god, when will the price move , common man
there's not excitement without boredom. yin & yang, tao and shit, remember? |
|
|
|
I have a question (to devs or anyone else): I read trezor uses RFC6979 deterministic ecdsa signatures to prevent leaking of seed or any other private data through the "random" number used in non-deterministic signatures. I read that hereIs there an easy way to check wether this is true by looking at a transaction signed by trezor? |
|
|
|
It is possible to generate seed in TREZOR, load recovery words into software that supports BIP39+BIP44 on an offline computer, and let the software generate xprv key for first account. Then import this xprv key into Wallet32.
At the moment it is a theoretical thing, because all these processes are not very easy to do yet and you have to trust your offline computer that does the computation.
Once this process is easy we might offer this a feature for advanced users, but we don't want beginners to enter private seed anywhere, because of the security implications.
Ah, I didn't think that the individual accounts functioned as private keys on their own. I thought they were keychains, i.e. seeds that determine a list of public keys. Reading about extended keys might help. I think that's what stick talked about calling the "extended private key" "xprv key"? |
|
|
|
No block for 30 minutes.  Could it be we're starting to reach hashrate saturation? |
|
|
|
I am not sure it gives us much information, what do you think? "5k to $700 and 5k to $620 at finex" is also true |
|
|
|
hehehe  |
|
|
|
|
does it feature some sort of blockchain or what's the deal with posting that here?
|
|
|
|
concerning Wallet32
Can I export the private key of one account only and use that on wallet-32 compatible with trezor.
Just like exporting only parts of the trezor DH-tree
You can't export any private information from TREZOR. well, to be correct: you can export the root private seed at one point. In fact you should... onto a piece of paper or similar. |
|
|
|
this coin is lacking promotion and leadership right now and that's killing the price. things need to happen, news and stories to be told. moves must be busted  screw price. this coin needs adoption. It has another chance (2nd round of airdrop in 6 weeks). I'm pretty sure there wont be such crazy hype and insane price rise as last time, so Icelanders wont be as tempted to sell. Also this time we have android wallet ready. We also have https://litepaid.com easy merchant app:  What we still need (lack?) of course is a sizable community in Iceland. Anyone from Iceland here who can assess the situation? |
|
|
|
|
starting to feel a bit uneasy... both shorts and longs have increased on finex (longs: 22.8 million USD up from 22.4 yesterday, shorts: 4720 BTC up from 4480).
Whichever way we go, it could be quite violent due to squeezing plus maybe some panic.
|
|
|
|
You guys sure as hell better not still be mining on ghash.
+1 |
|
|
|
It's not even 7 dollar, lol  half a pizza today... but if you manage to hold on... ;-) |
|
|
|
Sorry but if I can get coins from them with no fees Im signing up in a heartbeat.
If you're not paying, you might not be the customer, but the product. |
|
|
|
|
I'm having trouble: a transaction on the blockchain since about 10 hours shows as unconfirmed in myTrezor.com wallet. It's outgoing.
Also I can't initiate any new transaction, "not enough funds". There's plenty of funds.
I suspect some problem with the backend?
Can someone confirm / deny he's also having backend-related problems?
|
|
|
|
Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification. ok, the it seems wallet32 doesn't follow that recommendation. |
|
|
|
|
Show Posts
