|
Thanks for the help everyone. At this point, all indications point towards an insider job. We have traced the chain of custody and it is unrelated to any technical issue with Trezor.
|
|
|
|
Sorry for posting in here but it is somehow technical too. I put it on the main board and it got drowned by other posts very quickly. A friend of mine recently got his trezor wallet cleaned out and we are trying to figure out what happened. He gave me his ypub key and I imported it into Electrum to look at his transaction history. His last legit transaction was 2 weeks ago but yesterday he got two extra withdrawals. A test transaction was followed by a complete withdrawal of the entire wallet. https://www.blocktrail.com/BTC/tx/7a2f637bcd6f30a02c298c64022d4148c58d9587ed6e2191a3a758ad40c6fda2https://www.blocktrail.com/BTC/tx/7d708a9dc692ce79170a411563ebdcc4110bdfadfdfe1c726b8fb5d3d0bc17bfIMHO, the fact that there were 2 transactions points towards a compromised seed. The test tx actually returns most of the wallet amount back into the change address - which is a single use p2sh-p2wpkh address. Then the change address itself is cleared in the 2nd tx. The thief knows how to generate private keys for the entire hierarchical wallet. AFAIK, that requires the seed. So, it looks like a targetted attack. My friend says he never put his seed online, never took a picture of it, etc. He only kept it on a piece of paper, getting to it would imply someone who knows him. But the receiving address has activities that I don't understand then. https://www.blocktrail.com/BTC/address/18abkVcsfwvNHxFM1jN5WLAY9irB91FwTHThe address appear when he lost his funds and was itself cleared one day later. However, it also sees the transfer of over 1000 btc as if it was the staging area of a large scale attack. Does anyone know what has happened there? Thanks, --h |
|
|
|
A friend of mine recently got his trezor wallet cleaned out and we are trying to figure out what happened. He gave me his ypub key and I imported it into Electrum to look at his transaction history. His last legit transaction was 2 weeks ago but yesterday he got two extra withdrawals. A test transaction was followed by a complete withdrawal of the entire wallet. https://www.blocktrail.com/BTC/tx/7a2f637bcd6f30a02c298c64022d4148c58d9587ed6e2191a3a758ad40c6fda2https://www.blocktrail.com/BTC/tx/7d708a9dc692ce79170a411563ebdcc4110bdfadfdfe1c726b8fb5d3d0bc17bfIMHO, the fact that there were 2 transactions points towards a compromised seed. The test tx actually returns most of the wallet amount back into the change address - which is a single use p2sh-p2wpkh address. Then the change address itself is cleared in the 2nd tx. The thief knows how to generate private keys for the entire hierarchical wallet. AFAIK, that requires the seed. So, it looks like a targetted attack. My friend says he never put his seed online, never took a picture of it, etc. He only kept it on a piece of paper, getting to it would imply someone who knows him. But the receiving address has activities that I don't understand then. https://www.blocktrail.com/BTC/address/18abkVcsfwvNHxFM1jN5WLAY9irB91FwTHThe address appear when he lost his funds and was itself cleared one day later. However, it also sees the transfer of over 1000 btc as if it was the staging area of a large scale attack. Does anyone know what has happened there? Thanks, --h |
|
|
|
Somewhat shorter from bitcoin import *
with open("privkeys.txt") as f:
for line in f:
print(pubtoaddr(privtopub(line.strip())))
|
|
|
|
|
During handshake, both parties send their version message. They can cross since the communication is duplex.
step me node
1 version -->
2 <-- version
Then the other node received 1) and replied with verack. You did the same with your verack.
3 <-- verack
4 verack -->
Now that you have handshaked, the communication is in the normal phase. The other node is continuously broadcasting some of its state. So you should expect to receive inv, addr, tx, at any time. In addition, the other node can also send you a command like 'ping'.
The protocol isn't request/response. It is closer to a publish/subscribe. By connecting, you have subscribed to relay transactions and blocks and the other node will send you messages for that.
In short, you'll have an easier time if you organize your node around a message handler because messages can be unsolicited (at least not directly), or you can have a message with multiple responses (getblocks). Basically, be ready to receive anything and throw away the stuff you don't handle or need. If you want something, request it explicitly.
|
|
|
|
|
It's faster in wNAF and using Jacobian coordinates rather than Cartesian. Still nuts though...
|
|
|
|
I watched the video on lightning.network and have a question about a transaction which uses 3 channels (meaning the transaction with 4 people)
What happens if 3 (the second, the thirth and the fourth) of them work together? The one who will receive the transaction (the last one in the transaction-order) shares the key to unlock the Time-Locked-Transactions with the second person (the one the original sender sends his funds to). Now the second person can get the money from the original sender while the third person neither sends the funds to the fourth person nor claims the funds from the second person.
In that case only the first person paid the second person while the other transactions do not happen as the first person cannot broadcast anything to the blockchain.
All of that only works under the assumption that three of them work together to cheat the fourth person.
My question now is: Is there a code planned that will prevent that or can you steal someone's money that way or did I misunderstand something?
There are no key required for the time-locked transactions. They come from a 2-2 multi-sig address and are already signed by the 1 of 2. The other person just needs to wait and then sign it. The delay of the time lock is assigned decreasing from the last person so that in case of a refund situation, the last person can get it first. You can see the process as a Matroska doll. If you have A, B, C, D in a channel, A->B, B->C and C-D subchannels: A puts 1 BTC in deposit at B by funding a 2-2 multi sig with A+B, B does the same with C by funding a 2-2 multi sig with B+C, and finally C does the same with D by funding a 2-2 multi sig with C+D. So logically, 1 BTC went from A to A+B, B to B+C and C to C+D. D can't take the whole 1 BTC because it needs C signature. But D can see the money there and can consider 1 BTC credit line. This part is important.
Ideally, A could give 1 BTC to B in deposit, and B does the same with C. However, in this scheme, A has to trust B. B could decide to keep the 1 BTC and not give it to C.
So instead, A puts it in a trust fund (i.e. a multi-sig A+B). B can't get the money from A but sees it there. He funds another multi-sig with C. However, it's worth noticing that A has spent 1 BTC and so did B because B took 1 BTC from his own pocket to fund B+C. Without a refund capability, if A goes away B has lost 1 BTC since the A+B multi-sig cannot be spent without A signature.
With an additional hop, we see that C is in the same risky situation. He spent 1 BTC from his pocket to fund C+D.
The refund path is designed to eliminate this risk. A pays D for stuff up to 1 BTC and then they close the channel (or fund the channel further). * If they want to close, D broadcasts the transaction for the balance spending from C+D that has R. C sees R on the blockchain, so he can identify that D has closed the channel. He broadcasts his transaction closing B+C. And B does the same. * If not, A wants to get his money back. Obviously B, C want to get their money back too. D is the one who failed to close the channel - so he gets nothing. The lightning network must make sure that C gets the 1 BTC back first so that it can refund B who then can refund A. So the lock time for C must be lower than for B. I think they should also explain what happens in a partially closed channel. For instance, with A B C, C wants to close the channel with B but A doesn't want to close with B. Is it possible? Can A deposit 10 BTC with B and then have channels from B-C for 1 BTC and B-D for 9 BTC? That should be ok but I don't think it was covered. Also, do they need their new SIGHASH types with Segwit? I don't think so. PS: I skimmed over the video so apologies if some of the questions were answered. |
|
|
|
1. sid that gets passed to RUN comes from Run(P, my, VK[ ], sk, sid', 0)
where sid' is (sid, P, VK[ ]). Why do you need to have sid' if you are building a hash H((sid, sid, P ∪ {my}, VK[ ], run)). At this point sid is sid'. 2. I don't understand the commitment phase. "it is even for a rushing malicious peer a infeasible to have committed to an ill-formed vector that leaves mp intact". The DC-VECTOR exchanged between peers contain a DC-PAD component that cancels out when everything is summed up. Could you explain how would a malicious peer benefit from omitting it? Thanks, --h |
|
|
|
|
In step KE,
sidH = H((sid, sid, P ∪ {my}, NPK[ ], run))
How is NPK[] determined prior to receiving NPK[p] from p?
Thanks,
--h
|
|
|
|
|
It should be ok but bear in mind that there is no way to know which path you have chosen. If you forget that you have coins at 'bitcointalk.org', they will be lost and so will be every coin deeper in that branch.
|
|
|
|
1/58
about 1.7%
That can't be this simple since 100% of the p2kh addresses begin with 1  |
|
|
|
|
The first 1 comes from the address version and is always there for a normal bitcoin address. Every other 1 requires a byte equal to 0 is the pub key hash.
- 11: 1/2^8 = 1/256
- 111: 1/2^16 = 1/65536
- 1111: 1/2^24
etc
|
|
|
|
Somehow we worry about going to 2MB/block for fear of 'bloat'
Yes ... because of the network usage ... yet this is how much memory costs:
How does RAM help my bandwidth cost? |
|
|
|
|
I see your point. Craig has done some work on Bitcoin and deserves respect for that. Even if he messes up now, it shouldn't change the value of his previous contributions. That makes sense - but yeah - the media will not see it this way. They have lost credibility (or would have if they had any) and now are out of blood.
Personally, I think he went crazy. Kinda like if Einstein published a 'proof' that the earth is flat, years after his theory of Relativity.
|
|
|
|
|
It would take him a few seconds to sign a message with genesis key or one of the keys associated with Satoshi. And that would immediately clear his name and make fools of all the doubters. But no, instead he came up with a BS post followed by an apology.
If he's Satoshi and lost the private keys or can't access them for some reason, then he should have stayed anonymous . It is obvious that people would demand a better proof than what he showed. There aren't any good scenarios for him:
- He's not Satoshi: He's getting what he deserves
- He's Satoshi but all his stuff is locked somewhere else: He's also getting what he deserves for not showing the slightest foresight
- He's Satoshi and he's toying with us: He's getting what he deserves for being a douche
The media can be crappy but he was the one who contacted them. Now they are just doing the fact checking that they should have done in the first place before. So what if they are now calling a liar, no one really cares anyway. They are covering their ass and that story will blow away like it did before.
Nice try Craig but you are still gonna have to pay your bills.
|
|
|
|
Well you said - may be not in these exact terms because I don't have the thread either -
"afaics, you sign the same message - you get the same signature."
Those who don't have a cryptographically secure random number generator might use SHA384(signedMessage) for that. In this case you'll be getting the same signature again and again and again... PS: BTW, why people use random number generators for that? It's harder to generate a truly random number than to calculate hash(signedMessage). PS2: Disregard "PS", more likely it's because some of these people might use a random number generator with NSA backdoor. This reminds me something... Bitcoin core was using a random k, therefore the signature from the blockchain is using one. It's not going to match one produced by a deterministic hash of the message. |
|
|
|
|
Well you said - may be not in these exact terms because I don't have the thread either -
"afaics, you sign the same message - you get the same signature."
Besides, if you have a great refutal, why not repeat it here? Sounds like exactly what CW is doing - so maybe - you are Satoshi.
Edit to reply to your edit: LOL - That code is the description pulled from the Wikipedia.
|
|
|
|
Okay now we are starting to get some evidence that there might be a coordinated attack to hide the facts I have presented (note the following thread move to Meta is not the thread that Gmaxwell deleted)
People have refuted your theory but you just don't want to listen. "If you sign the same message with the same key, you will get a different signature". Your chances to get the same signature is ~1/2^256. Why? Because of the the 3rd step of the ECDSA algorithm. Quoting from https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_AlgorithmCalculate e = \textrm{HASH}(m), where HASH is a cryptographic hash function, such as SHA-2. Let z be the L_n leftmost bits of e, where L_n is the bit length of the group order n. Select a cryptographically secure random integer k from [1, n-1]. Calculate the curve point (x_1, y_1) = k \times G. Calculate r = x_1\,\bmod\,n. If r = 0, go back to step 3. Calculate s = k^{-1}(z + r d_A)\,\bmod\,n. If s = 0, go back to step 3. The signature is the pair (r, s). Their emphasis, not mine. Now, tell me. How did CW come up with the same signature as something from the blockchain if he was casually signing a message? Bear in mind that k is chosen by the signing software (openssl) and not an input from the user. |
|
|
|
|
Just to be clear, that's in addition to having the same message and private key, right?
|
|
|
|
|
Show Posts
