|
1. install python 2.7.6 for Windows.
2. install Github for Windows
3. Clone Electrum to your local drive.
4. install dependencies.
5. Run Electrum
|
|
|
|
I'm curious. I've never used the IRC where this was discussed. Is there a reference I can refer to to get on there.
If you don't have an IRC client: https://webchat.freenode.net/for your client, if you have one, it's irc.freenode.net join #bitcoin-dev |
|
|
|
dabura667, I'm not sure exactly what you're proposing, but adding extra nonces (e.g. these Rn's) will only get you so far. If you have N secret values which are combined linearly to produce keys, then N linearly independent equations (i.e. collusion by N parties) will be able to solve for them all. So your collusion resistance is only linear in your system complexity :/.
I'm not proposing anything. ffe's post spoke of adding more complexity, not mine. |
|
|
|
You're right. r0 and r1 aren't truly independent random variables.
You would need a separate r for sub key at each level.
Something like rn = H(n,a,1) instead of r=H(a)
Then pass a separate Rn for each sub key to the auditor. Ugh
never mind
Yeah, at which point... it would be better just to give the Auditor a list of the pubkeys for each department and not just the master pubkey. it's a rough problem... |
|
|
|
Wait. If you know the equations for 2 different n, you now have _three_ unknowns: "a", r0, and r1. You still can't solve for "a". You know Rn but not rn for different n's.
ok, let's say we know x0 and x1 (two derived private keys).... and we know A and R. to generate s0 and s1 we just take H(0,A) and H(1,A) to generate t0 and t1 we just take H(0,R) and H(1,R) now we have x0, x1, s0, s1, t0, t1, A, R since Rn = tn*R, we can replace it as such: (Q is the generator point) x0*Q = s0* a*Q + t0* r*Q x1*Q = s1* a*Q + t1* r*Q Remove the points to get: x0 = s0* a + t0* rx1 = s1* a + t1* ra = (x0 - t0*r)/s0 a = (x1 - t1*r)/s1 0 = s1x0 - s1t0*r - s0x1 + s0t1*r s0x1 - s1x0 = r(s0t1 - s1t0) r = (s0x1 - s1x0)/(s0t1 - s1t0) (Note: this division should be inverse modulo operation against the order of the curve) then plug in r to solve easily for a simple add/sub/mult/div of normal numbers (mod order of the curve) will find you both a and r. the only unknowns in the two equations are a and r. all other are known. Remember, the index information in "n" is ONLY contained in tn. so when you say r0 and r1, you are actually saying t0*r and t1*r... which all tn can be derived from the pubkey for R. |
|
|
|
From IRC: 18:28:54 <sipa> xn = sn*a + tn*r
18:29:14 <sipa> Xn = sn*A + tn*R
18:31:10 <sipa> if you know sn and tn and xn for 2 different n, you can solve it
18:31:43 <sipa> as you now have 2 equations with 2 unknowns (a and r)
18:32:17 <sipa> and given A and R you can compute sn and tn for any n
18:33:56 <sipa> so give me A and R and xn1 and xn2, and i can find a and r So your method would effectively lower the risk from "One Master Public Key and one derived private key" to "One Master Public Key and two derived private keys" |
|
|
|
|
Edit #2: check the second reply in the next post.
Sounds good so far.
Question:
How would the owner of xn (private key) be able to derive a private key in the depth below him in such a way that the owner of "a" would be able to redeem the funds?
Edit: I think I got it.
we could store the compressed pubkey of R in addition to the chain code and A...
Then when you derive the pubkey Xn, you would store the chain code, Xn, and Rn. This would continue down the chain.
This is very interesting... and would remove the need for hardened keys. (although I'm sure someone will still find a use case for them.)
|
|
|
|
Actually, if you concatenate the whole blockid of the block containing the tx, that would require the miner to brute force multiple solutions to the block until he found one that mixed with the txid to generate the desired solution. This kind of attack is well known. The pool owner creates transaction for 50/50 bet and does not broadcast it to a network but places in in his block template. If the block is found by everyone else - nothing happens. No bet, no lose, no win. Nothing. If the block is found by a miner of this pool there are two possibilities for an owner: if his transaction wins - he broadcasts the block as usual if his bet loses - he withholds block. Miners lose their profits, but not an pool owner. Sorry for my English Yeah, for a 50/50 bet. In the OP situation, he was saying to bet 0.1 BTC to get a return of 100 BTC... we can assume that the requirement will be more than 50/50... more like 1 in 1000 or somewhere close. Pool operator waiting for 1000 block solutions will DEFINITELY raise flags with his miners LONG before he finds a winning combination. |
|
|
|
|
The block time is less about propagation (though low block times DO run into problems with propagation, yes) and more about the distribution of solutions over time.
Super fast propagation would help alleviate orphans in a low block-time environment, but would not eliminate it. The decrease from 10 min to 30 sec would increase the orphan rate FAR more than the IBLT would reduce the orphan rate.
|
|
|
|
you can take a sha256 ( txid | blockid ) where | stands for concatenation
but "bad" miner (pool owner) can play against you
Actually, if you concatenate the whole blockid of the block containing the tx, that would require the miner to brute force multiple solutions to the block until he found one that mixed with the txid to generate the desired solution. Even finding one solution to a block takes YEARS for a single person, but if you are looking for a value that has a low enough probability, even GHash.io wouldn't be able to brute force it. Even if they COULD (which they can't) all you have to do is say "and you are required to send the unconfirmed tx within 5 minutes from now." then there's not enough time for GHash to solve enough blocks to make the hash ot (txid | blockid) match a certain value, unless it was something like "if the first bit is 1" or some high probability thing... |
|
|
|
|
1. Copy the txid of the payment TO your Electrum Wallet.
2. Check it on blockr.io or some explorer.
3. Check where the outputs lead.
4. If you see it as "Unspent" in your address, it's fine.
|
|
|
|
|
No, you need to use git.
Also, you need to install all the dependencies.
|
|
|
|
Shorena said, it is bad for a phone. Phones can be attacked easier than a computer. So it is bad. That's the point here.
~~MZ~~
Please explain to me how iPhone is more easily attacked than a computer. Be as in depth as possible in your justification. |
|
|
|
|
Check the spelling. There are a lot of words in Electrum seeds that are close, like "through" "thorough" etc.
Also, make sure you are connected to the server.
|
|
|
|
|
1. for watch only, tap "restore" and "scan QR seed"... then scan the QR shown with your "Master Public Key" and it will create a watch only wallet.
2. to switch wallets you will need a separate file manager app. Basically. 1. Kill Electrum and sl4a processes. 2. change wallet.dat to blahblahwallet.dat (or whatever... as long as you remember what file it is, I might keep the word wallet in there) and when you restart Electrum it will have you create a new wallet. 3. repeat 1 and 2 switching out the names so that wallet.dat is the wallet you want to open before your start Electrum.
WARNING: Electrum Android is unreliable. Use at your own risk.
|
|
|
|
|
mnemonic != passphrase
the mnemonic has a checksum, and thus is limited in combinations.
the passphrase is a salt to the hash used with the mnemonic, so changing the salt changes the seed of the HD wallet.
Optional plausible deniability.
|
|
|
|
3MkwFfGNQDve7vz1z6gUDVxkuQpcSV3Mz8 decode to hex Header byte: 05 (05 is p2sh, commonly known as multi-sig with a "3" at the beginning)
hash160: dc2047e70aeac3df47eb8a8aa676db7d8efe2278
checksum: 86ea9db1 (for error checking) 1M4vL7mvrKcG2mHas11snsbpktXtqNYJiD decode to hex Header byte: 00 (00 is p2pkh, normal bitcoin addresses with a "1" at the beginning)
hash160: dc2047e70aeac3df47eb8a8aa676db7d8efe2278
checksum: 13dacaa2 (for error checking) Notice they are using the exact same hash. I would bet a large sum of money that the rich list does not recognize the 05 header byte (meaning it is not optimized for multi-sig) and just made the address using the hash that was in the output assuming it was a normal bitcoin address. |
|
|
|
I guess I am confused... What is the problem with someone sending you a million little bits of btc? Besides flooding your transaction history, I guess I fail to see the negative side.  You fail to understand how bitcoin works, then. Every time you receive bitcoin, it's like receiving a "bill" in that amount. So imagine I receive 1 BTC... A. but in one situation I just receive 1 BTC over the span of 1 transaction. B. In the other situation I receive the 1 BTC over the span of 100 transactions. Now let's send the 1 BTC to a friend in each case. A. There is 1 input, so the transaction is likely around 250 bytes, and does not require a fee if you wait a day after receiving it... or 0.00001 BTC if you want to send right away. B. There are 100 inputs, so the transaction is likely around 14978 bytes to 18178 bytes ish... which disqualifies the amount for a free transaction, AND the fee will be about x15 to x19 times the previous fee. (0.00015 to 0.00019) But more importantly... the transaction in B is so large that some miners will pass over it in order to save the block from getting too large. If you have a ton of 1 satoshi inputs in your wallet, and the wallet is dumb... it will try to use those every time you try to send a few dollars out during normal usage, and the fees will become very large. |
|
|
|
|
Human generated entropy is ALWAYS a good idea. /s
|
|
|
|
|
Show Posts
