|
502
|
Bitcoin / Development & Technical Discussion / A couple of questions regarding Schnorr MuSig algorithm math notation
|
on: January 18, 2019, 08:40:47 AM
|
Reading the "Simple Schnorr Multi-Signatures with Applications to Bitcoin" by Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille .pdf link. I have some questions about some notations. I am generating a signature but the verification doesn't pass which leads me to believe I am misunderstanding some stuff here. in ai = Hagg(L,Xi) what do we hash? Is it the all public keys (L) "concatenated" together then public key i "concatenated" at the end? Don't think this makes a difference if consistency is kept but are pub keys in compressed form or uncompressed? For example with 2 keys is it calculated like this (so hash of a 99 byte long array: 3*(1+32 compressed))?: a1=Hash(pub1 || pub2 || pub1)a2=Hash(pub1 || pub2 || pub2)Similarly for calculation of 'c' is it again concatenation of bytes, also are the points (X ~ and R) in their compressed form or uncompressed (again I don't think it makes a difference but want to make sure)? c = Hsig(X~ ,R,m)Also I am assuming H sig, H agg,.. are all the same hash function like SHA256. And finally in verification step shouldn't it be R + X~ in the following equation since they are both points, multiplication doesn't make any sense? |
|
|
|
|
503
|
Bitcoin / Bitcoin Technical Support / Re: Math problem regarding recovery seed
|
on: January 08, 2019, 03:06:37 AM
|
I don't see how there are that many combinations unless he bruteforced every possible permutation of 4 from 24, which is roughly 331776 possibilities (minus repetitions I guess.)
I didn't brute force all the possible permutations, actually I am skipping a lot (eg. w1-w5 and w5-w1, also w1-w5 and w5-w10 since w5 was already swapped) which is why the total is 31878 instead of 255024. Additionally I stuck to this part of OP's comment: But since I screw up, maybe I have switched words in a non symetrical position.
|
|
|
|
|
504
|
Bitcoin / Development & Technical Discussion / Re: What libraries for secp256k1 have been used for bitcoin in the past?
|
on: January 07, 2019, 01:37:43 PM
|
It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.
How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key? Not necessarily since it can be a random number inside (0<k<n-1). It can also be deterministic in which case it is not exactly hash of the private key. If you are using a deterministic k then it is calculated using HMAC with an appropriate hash function (SHA256 in our case) with private key as HMAC's key. If there is a problem with implementation and you are not finding a random k and reuse the same value more than once, it is possible to calculate the private key from that. |
|
|
|
|
505
|
Bitcoin / Development & Technical Discussion / Re: spend P2SH output
|
on: January 06, 2019, 06:27:54 PM
|
I am not very good at scripts but I'll try. ripemd160(sha256(OP_2 OP_EQUAL)
You can not hash an operation, you has the values. OP_2 is also an operation but it happens to be adding a predefined value (2) to the stack. Your OP_Equal on the other hand is just an operation, so your hash looks like something like this: Hash(5 +) So your interpreter is surprised to see a + operation (or in your case an equality check op) where it is expecting a value. 16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)"
Here is the step by step of the script: 1. Stack is empty. OP_2 OP_2 OP_EQUAL OP_HASH160 5c9081ddd7c74d71e183b104abcc3f74be54c9c7 OP_EQUAL 2. Push value 2 on the stack: Stack is { 2 } OP_2 OP_EQUAL OP_HASH160 5c9081ddd7c74d71e183b104abcc3f74be54c9c7 OP_EQUAL 3. Push value 2 on the stack: Stack is { 2, 2 } OP_EQUAL OP_HASH160 5c9081ddd7c74d71e183b104abcc3f74be54c9c7 OP_EQUAL 4. 4.1. Pop 2 items from stack: Stack is { }, you have two values in memory 4.2. Check their equality... 4.3. Push (Boolean) result on the stack: Stack is { 1 } OP_HASH160 5c9081ddd7c74d71e183b104abcc3f74be54c9c7 OP_EQUAL 5. 5.1. Pop 1 item from stack, stack is empty and there is value 1 in memory 5.2. Perform hash160 hash on 1 5.3. Push the result of hash back on stack { .... } 5c9081ddd7c74d71e183b104abcc3f74be54c9c7 OP_EQUAL 6. (Assuming there is a push op behind this, the value will be pushed onto the stack) OP_EQUAL7. The same as 4 but the result is false because you were supposed to have Hash160(2) but you have Hash160(1) Edit: I've made a tiny mistake which I fixed. The script fails not because of final step or the equality check before that, it fails because in your script sig you have operations other than push operations. |
|
|
|
|
507
|
Bitcoin / Electrum / Re: Seeds segwit to standard?
|
on: January 05, 2019, 05:57:39 PM
|
|
(Edit: I was thinking in terms of BIP39 only, Electrum does it differently, read comment below)
Your seed words are the human readable representation of the entropy that you use to generate your keys. There is no difference* between a SegWit seed and a regular seed, in the end you are generating "private keys" and in bitcoin we only have one type of private key!
The final step is when you can decide to encode the corresponding public key to be a P2PKH output (base58 address) or a P2WPKH (bech32) or a P2WSH (base58 but starting with 3).
What the first couple of letters (xprv, yprv, tprv,...) are telling your code behind is exactly the last step otherwise everything else is the same. And those letters are representing 4 bytes which can not be changed otherwise the checksum (the last 4 bytes) would become wrong.
* There is an additional tiny difference and that is the derivation path which uses m/84'/../../.. so technically if you change your xprv to a zprv you won't get the same private keys unless you override this path difference but the "roots" are exactly the same.
|
|
|
|
|
508
|
Bitcoin / Development & Technical Discussion / Re: 10, 10 year old Bitcoins in 10 alternate universes!
|
on: January 05, 2019, 09:21:28 AM
|
Going to have to throw my hands up and admit I don't really understand these... any other external factors taken into consideration, or are all alternate versions working on the same assumptions of today?
The differences are in: - The elliptic curve that was used which are all over Fp but have different variable values. This will affect the security and also is used in the following: -- Calculation of `e` (based on size of the curve, for example for secp256k1 chances of trimming e is highly unlikely but in other curves it has a higher chance of happening, not a security disadvantage though) -- Choice of hash function that was used for these alternatives and needs to match the size of the curve. The function itself is used for: --- Getting transaction ID (for example in outpoint of btc521 in second post you can see the hash is a 64 byte one which is the result of a SHA512) --- In rfc6979's HMAC function (for getting a deterministic k value) --- Hash of the message for signing (for calculating e afterwards) Are we saying that speed and size of transactions were all that affected adoption? And security itself wasn't actually the biggest consideration (or are we assuming Schnorr is also the most secure?).
I didn't get into the topic about security that much, and I'm no expert. I can't begin to assume why Satoshi chose this curve but it is a good one right in the middle. It offers a good enough security and it is fast. And by that time ECDSA was more popular than ECSDSA. When security is concerned choice of the curve is based the "strength" of the curve. Bitcoin's curve offers 128 bits of security and according to SEC1 document it offers security beyond 2030 (which is just an estimation made in 2009). As for Schnorr, the security (AFAIK) is the same because you are still using the same curve with the same hash functions. The only difference is in calculation of the signature which is still pretty much the same. Schnorr (whether it is the original 1991 patented one or any of the other 4 alternatives or if it is the Sipa's implementation) is getting rid of 2 multiplicative inverse modulo n which exist in ECDSA and adds some hashing in there but everything else is the same. You still choose the same random k, multiply that with a point (G) for calculation of r and get s based on that. |
|
|
|
|
509
|
Bitcoin / Development & Technical Discussion / Re: 10, 10 year old Bitcoins in 10 alternate universes!
|
on: January 05, 2019, 05:56:55 AM
|
So would you say that once we have Schnorr signatures operative we would have the best Bitcoin on all of these universes or the ones with the tx sizes a bit smaller are better without compromises on security?
I was just having some fun with different Elliptic Curve Digital Signature Algorithms, I haven't even gotten to do explore the binary curves (F2m) or haven't even begun to mess around with RSA. This wasn't meant for showing which is "better", but only to show the alternatives. As for Schnorr, I see 3 benefits (there may be more): - Speed of signing transactions - Speed of verifying transactions and more importantly multiple transactions (like verifying a block or when you receive a tx message for your mempool) - Size of multisignature signatures which would help scaling a lot. I don't see any security issues with Schnorr. It is pretty much the same as ECDSA that we are currently using and it has been around nearly as long. The problem was with the fact that Schnorr was patented so everyone used the alternative which wasn't. |
|
|
|
|
510
|
Bitcoin / Bitcoin Technical Support / Re: Math problem regarding recovery seed
|
on: January 05, 2019, 05:35:02 AM
|
namespace SeedCracker
{
class Program
{
static void Main(string[] args)
{
string origin = "adjust concert sun teach sting ivory dentist increase hammer snake abandon loyal poem write tiger manage earth win slot weird rapid flat believe rhythm";
string[] words = origin.Split(' ');
for (int i = 0; i < words.Length; i++)
{
for (int j = i + 1; j < words.Length; j++)
{
string[] clone1 = (string[])words.Clone();
string temp = clone1[i];
clone1[i] = clone1[j];
clone1[j] = temp;
for (int k = i + 1; k < words.Length; k++)
{
if (k == j)
{
continue;
}
for (int m = k + 1; m < words.Length; m++)
{
if (m == j)
{
continue;
}
string[] clone2 = (string[])clone1.Clone();
string temp2 = clone2[k];
clone2[k] = clone2[m];
clone2[m] = temp2;
string origNew = string.Join(' ', clone2);
// Pass origNew to your BIP39 to get the BIP32 out of it
// Use m/44'/0'/0' as path
// Check the privatekey/publickey/address of index 0,1,2... (depending on what you have) against the result
// Print seed if equal and break out of the loop.
}
}
}
}
Console.ReadLine();
}
}
}
The original seed that I changed was (randomly generated using https://iancoleman.io/bip39/): adjust concert sun rapid sting ivory dentist increase write snake abandon loyal poem hammer tiger manage earth win slot weird teach flat believe rhythm The total count of this loop is 31878 and the correct seed was found after 16729 iterations. It takes about 20 minutes to find the correct answer but it may be reduced if the code was optimized (which mine isn't). The commented part above is like this: using CryptoCurrency.Net;
using CryptoCurrency.Net.BIPs;
using CryptoCurrency.Net.Coins;
using CryptoCurrency.Net.Cryptography.Hashing;
/**snipped***/
using (BIP0039 bip39 = new BIP0039(origNew, coin: new Bitcoin())
{
using (BIP0032 bip32 = bip39.ToBip32())
{
BIP0032Path path = new BIP0032Path("m/44'/0'/0'");
PrivateKey[] pks = bip32.GetPrivateKeys(path, startIndex:0, count:1, step:1);
if (pks[0].ToBytes() == pkBytesThatUserEnteredInTheBeginning)
{
Console.WriteLine($"Your correct seed is: {origNew}");
}
pk.Dispose();
break;
}
}
I took this part out because it is using my own library (CryptoCurrency.Net) which I have not released yet so you wouldn't be able to use it. But the first part should give you the idea of how to do it with any library or in any programming language. The bottlenecks are the following: - The PBDK inside of BIP39 (mine is optimized so it is fast) - The calculations inside BIP32: * If it is based on one private key they are only BigInteger math so can be pretty fast (mine is fast) * If it is based on public key then they are based on modular asthmatics that is used for EC multiplication which can be slow (here is the slowest part). * If it is based on address then it is limited by the speed of encoding (base58 or bech32) |
|
|
|
|
511
|
Bitcoin / Development & Technical Discussion / Re: 10, 10 year old Bitcoins in 10 alternate universes!
|
on: January 03, 2019, 05:55:21 AM
|
Here is the transaction for btc192: hex:
01000000016d6ba7a66e3a3b4da23d291f9d3c21b4045aeaba0000000052373034021864ea0d8b3fafaceb9c075851a557cac98ede918af3c540d902181cfaf71070fe68e655e37e0a76d8b227df1dd6a28b96e5eb011902c624107ac3d3d017d0fa1ab3a76a0611b861b97352717f11ffffffff01e2a69b00000000001976a9149be2268ea730df2d740130c35f75e18709a3e26a88ac00000000
Serialized {
"Version": 1,
"TxInCount": 1,
"TxInList": [
{
"Outpoint": {
"TxId": "baea5a04b4213c9d1f293da24d3b3a6ea6a76b6d",
"TxHash": "6d6ba7a66e3a3b4da23d291f9d3c21b4045aeaba",
"Index": 0
},
"ScriptSigLength": 82,
"ScriptSig": "373034021864ea0d8b3fafaceb9c075851a557cac98ede918af3c540d902181cfaf71070fe68e655e37e0a76d8b227df1dd6a28b96e5eb011902c624107ac3d3d017d0fa1ab3a76a0611b861b97352717f11",
"Sequence": 4294967295
}
],
"TxOutCount": 1,
"TxOutList": [
{
"Amount": 10200802,
"PkScriptLength": 25,
"PkScript": "76a9149be2268ea730df2d740130c35f75e18709a3e26a88ac"
}
],
"LockTime": 0,
"Flag": 0,
"WitnessList": null
}
Here is the transaction for btc521: hex:
0100000001a3c3da6490ed951c019723b5701acab524edafb3174c5c00220afc9c405d5b974aa9c5d1c134f77c9c3a9d6bc1d4494acc828ce84243da078e40451b574734ae00000000d04c8b3081870241744426278a6defed8a7f992ef8dd29638d09e6aa3162ec55054b6a1b548ea9d152f330ec8e85db5270198d18d1bf87bf088fb95776b99251959e555f035e17a6f9024200af953acce4583801d99c3c84f32df01392ae4c4f4b47ae3aae21306c1eba02b69032768895b4f308be8b26a3b4b4c17606b6c9f902dd9c825509274a6230a5109f0142026f3f5e111adacfe4a0e9f2536df34db0907cb5085a277b0da3c78905b7eed258791a94b713de18a6a13ba71fcf9bb40f79011dd01b1571f690273d67c5ef675a96ffffffff01e2a69b00000000004576a940d17fdb75bb04d2c59fb5b8d6ab090fe8a7fb5f779b9f3d1cfc716b72d174aa2dde7a200d4f686d1cebb210729684a15350ba0ec21016848600e8855bfe1b9dbb88ac00000000 {
"Version": 1,
"TxInCount": 1,
"TxInList": [
{
"Outpoint": {
"TxId": "ae3447571b45408e07da4342e88c82cc4a49d4c16b9d3a9c7cf734c1d1c5a94a975b5d409cfc0a22005c4c17b3afed24b5ca1a70b52397011c95ed9064dac3a3",
"TxHash": "a3c3da6490ed951c019723b5701acab524edafb3174c5c00220afc9c405d5b974aa9c5d1c134f77c9c3a9d6bc1d4494acc828ce84243da078e40451b574734ae",
"Index": 0
},
"ScriptSigLength": 208,
"ScriptSig": "4c8b3081870241744426278a6defed8a7f992ef8dd29638d09e6aa3162ec55054b6a1b548ea9d152f330ec8e85db5270198d18d1bf87bf088fb95776b99251959e555f035e17a6f9024200af953acce4583801d99c3c84f32df01392ae4c4f4b47ae3aae21306c1eba02b69032768895b4f308be8b26a3b4b4c17606b6c9f902dd9c825509274a6230a5109f0142026f3f5e111adacfe4a0e9f2536df34db0907cb5085a277b0da3c78905b7eed258791a94b713de18a6a13ba71fcf9bb40f79011dd01b1571f690273d67c5ef675a96",
"Sequence": 4294967295
}
],
"TxOutCount": 1,
"TxOutList": [
{
"Amount": 10200802,
"PkScriptLength": 69,
"PkScript": "76a940d17fdb75bb04d2c59fb5b8d6ab090fe8a7fb5f779b9f3d1cfc716b72d174aa2dde7a200d4f686d1cebb210729684a15350ba0ec21016848600e8855bfe1b9dbb88ac"
}
],
"LockTime": 0,
"Flag": 0,
"WitnessList": null
} |
|
|
|
|
512
|
Bitcoin / Development & Technical Discussion / 10, 10 year old Bitcoins in 10 alternate universes!
|
on: January 03, 2019, 05:55:05 AM
|
I have been learning more about bitcoin and programming at the same time all the while having some fun with both. On bitcoin front I have been exploring the Digital Signature Algorithms and mainly focusing on elliptic curves, on programming front focusing on Inversion of Control and it has been letting me do stuff like this. Since bitcoin is 10 years old today I chose 10 different bitcoin implementations and posted the results here. There are 2 different Digital Signature Algorithms (ECDSA and ECSDSA) using 5 different curves hence 10 different coins. The algorithms being Elliptic Curve DSA that bitcoin is using and Elliptic Curve based Schnorr DSA. The list of them with additional information can be seen in the following table: * Schnorr algorithms are based on the original 1991 paper in Journal of Cryptology not the sipa’s unofficial BIP. The reason is that the later has a Jacobi Symbol and I wasn't sure if I was calculating it correctly and I have no unit tests although my verify returns true. To make it related to this occasion (the 10th bitcoin birthday) I chose the following “Easter egg” which can be found in the very first bitcoin block as a seed to find the first private key using a simple SHA512 hash. The Times 03/Jan/2009 Chancellor on brink of second bailout for banks To reduce the size of the key for each coin a simple % curve.N was performed. prvbtc521: ctCJLpKQRGeEy1vfwURYJCwwP7AGkyo9V75f8K7DVTSdLaJ4cfMatnQUdZg6Dp3RyrBKm2HjrbsgzR1NmPEikMFB2Qxx6QSDr
prvbtc: cTf2PDXMK6fbZUAC4GV8N8wewnzurabVeXJ2JqvpZbMvcxDjZGyz
prvbtc192: ci9qEELh7Fba2YUP8HLAtaEwRuossREiMfXamMPNj
prvbtc384: Cs5Yoy2n2y7kVcwotu1kGfrhqnSjqhuMubCXQMggGS7q23HsnnNEAz5YYTCXy95AaK4YdW5C3Z
Here is the transaction with bitcoin (I'll broadcast the rest in the alternate universes!) https://www.blocktrail.com/tBTC/tx/7feef9bf65de07a391658e57a61ff9f3ba3b7dd8fce8f28fea38d0267cad89fcI have not used any libraries, everything is my own implementation so it means it is not optimized and it may contain bugs. But it is interesting to say that the time signing operation takes is increasing with the curve size but with a whopping rise with last two ones which I believe is partly because of the a and b values of random curves compared to Koblitz curve. As for Schnorr the time is reduced about 5% because it doesn't have the multiplicative inverse modulo n. Of course Schnorr becomes more interesting when it involves verifying many signatures at the same time. Transaction sizes for each curve, just for fun: * Schnorr transaction sizes are the same with 1-2 byte difference. Here is how bitcoin would look like with Schnorr (note that I believe Schnorr signatures will be implemented through SegWit with a new witversion but I am just guessing since I had no time reading the roadmap yet so I simply change the signature algorithm with Schnorr here): hex:
01000000015a2647bfc3a43aa2104c8da0d9d71c8954826a6dd6f8e42df9cda6f96fb2e331000000006c493046022100bf560f18bddd23959b2600dbbfc8acdc8de8f747e01cd357f1dd2c1d5be9e875022100f932d8b2bf204b1b0a44a774099a0c670b44dcaccad489e124610d423984e5550121034a60644fb34922cfaef5648ab96593a2597d57d2aafaa698333995499c4fb113ffffffff01e2a69b00000000001976a914ecb20c627ad0e84456952666ed6c1d0c7eb9bc9388ac00000000 Serialized: {
"Version": 1,
"TxInCount": 1,
"TxInList": [
{
"Outpoint": {
"TxId": "31e3b26ff9a6cdf92de4f8d66d6a8254891cd7d9a08d4c10a23aa4c3bf47265a",
"TxHash": "5a2647bfc3a43aa2104c8da0d9d71c8954826a6dd6f8e42df9cda6f96fb2e331",
"Index": 0
},
"ScriptSigLength": 108,
"ScriptSig": "493046022100bf560f18bddd23959b2600dbbfc8acdc8de8f747e01cd357f1dd2c1d5be9e875022100f932d8b2bf204b1b0a44a774099a0c670b44dcaccad489e124610d423984e5550121034a60644fb34922cfaef5648ab96593a2597d57d2aafaa698333995499c4fb113",
"Sequence": 4294967295
}
],
"TxOutCount": 1,
"TxOutList": [
{
"Amount": 10200802,
"PkScriptLength": 25,
"PkScript": "76a914ecb20c627ad0e84456952666ed6c1d0c7eb9bc9388ac"
}
],
"LockTime": 0,
"Flag": 0,
"WitnessList": null
}Happy 10th birthday, bitcoin. |
|
|
|
|
513
|
Bitcoin / Development & Technical Discussion / Re: Decentralised bitcoin address book
|
on: January 02, 2019, 02:12:55 PM
|
I think my email is greater than 20 chars also.
You can drop the extra stuff and use some sort of coding. for example add 1 byte (256 options) indicating which Email provide it belongs to. For example 0x01 can mean gmail.com, 0x02 can mean protonmail.com so you effectively replace 9 bytes and 14 bytes respectively with only 1 byte. What's wrong with reusing addresses other than the privacy issues, a lot of services mean you have to use them.
Can you convince me on why this would be a bad thing?
There is nothing wrong with reusing addresses but it is not "recommended", not to mention that by design, a bitcoin address is a single use token. Read more: https://en.bitcoin.it/wiki/Address_reuseonly argument you would have would be the security of signing multiple transactions with the same key which is really getting less and less exploitable as an attack target the more time goes by.
When you sign anything with your private key, you are revealing your public key. This operation is a one way operation but if there is any weakness in the implementation you are using or some day a weakness in the algorithm itself is found then your funds will be at risk compared to if you never revealed your public key. I understand its good to follow best practices, but it becomes a negative feat when you do it without asking yourself why.
It is never "negative" when you follow the best practice even if you don't know the reason for it. This doesnt solve the proof of identity problem. Anyone can sign a tx and include any email phone without proving themselves as the owner. I understand you want to keep the privacy of bitcoin, but know that not everyone cares about privacy. Solving this problem would definitely be worth creating something new.
I've already pointed out this flaw and also pointed out that it is the same with any other decentralized way of doing it. You can't prevent people from registering any address with any name no matter what method you use. |
|
|
|
|
514
|
Bitcoin / Development & Technical Discussion / Re: Decentralised bitcoin address book
|
on: January 02, 2019, 08:37:06 AM
|
First of all this is encouraging address reuse which should be avoided. Secondly you are complicating things by a lot! Try to think simpler and try to stick with what bitcoin already offers. Let's see what you want to do. You want to link a bitcoin address to another "information" which can be anything including Email, phone number, website link,... So why not use OP_Return? It offers all you want. It signs a "message" so the owner of the key would be clear and it can include any "information" in it. You just have to make a new transaction from that address and include that "information" inside a OP_Return output. Like this (the link to my github page): 6a68747470733a2f2f6769746875622e636f6d2f436f64696e672d456e7468757369617374
Then all the clients have to do is to search the blockchain for OP_Return outputs and build a local database from them. It inherits the same flaws as your proposed system as it encourages address reuse and also it has no mechanism from stopping anyone from linking anything to anything because of decentralization! |
|
|
|
|
516
|
Bitcoin / Electrum / Re: There has been an increased number of "fake" electrums out there, be careful.
|
on: December 30, 2018, 02:01:29 PM
|
Just out of curiosity what was the intended use for it in Electrum?
AFAIK this is the way the servers communicate with the clients that connect to them. For example when you send a transaction with low fee you receive a message telling you why your transaction was rejected with a "low fee" message, or if you broadcast a message with wrong signature,... you'll receive another message, and so on. The problem is that these messages (which are normally bitcoind responds) could be anything instead of being hard coded in the client and being predefined. As kano stated the feature is not like the old alert system in core that required keys before alert messages could be sent to the network.
Of course the core alerts required a key (which also was compromised at some point prior to the system's retirement) while Electrum messages can be sent by anyone. And I do realize that it wasn't a good example but there is a good similarity there, which is why I mentioned it in first place. For starters both cases are following a similar not-predefined message structure which the sender decides what to send. So the message could display anything including a link. |
|
|
|
|
517
|
Bitcoin / Electrum / Re: There has been an increased number of "fake" electrums out there, be careful.
|
on: December 29, 2018, 09:25:20 AM
|
They will need to build a warning system or a popup notice into the wallet application to warn people who are not reading forums.
This IS what this attacker was using! The feature to send a warning message from the server. The only way it can be prevented is if the servers can only send predefined messages. For example they can send a "code number" like sending 1 means you need to update, sending 2 means there is a fork going on,... so that it is not arbitrary. |
|
|
|
|
518
|
Bitcoin / Electrum / Re: There has been an increased number of "fake" electrums out there, be careful.
|
on: December 28, 2018, 04:05:16 AM
|
I emailed them about that and got no response.
It took them about half a day to respond but I've gotten the answer to my report and now the account and the page are both removed from GitHub. The electrum-projects one was actually verified by github and had the green verified logo next to it. That is another factor that led to me downloading it.
What is this "verified logo"?  I don't recall ever seeing any Github repo that has a "verified by github" logo attached to it? Even the official Electrum repo here doesn't seem to have any verified logo? "Verified" simply means that the commit in that repository was signed. It can be when you commit things through the webpage when signed in so they are signed with GitHub's key, or if you use git (for example I push commits from Visual Studio) you have to either signed them with a PGP key or they are not marked as verified. This doesn't mean much though! https://help.github.com/articles/managing-commit-signature-verification/An example: https://i.imgur.com/lWER7ZL.jpg |
|
|
|
|
519
|
Bitcoin / Electrum / Re: There has been an increased number of "fake" electrums out there, be careful.
|
on: December 27, 2018, 04:16:10 PM
|
Another reason for Full-Validation,
Was only a matter of time before the the servers became a point of attack.
This has nothing to do with being an SPV client. It is about the implementation (software) having a flaw that was exploited and it can happen to any software whether it is a full node or an SPV one. The weakness was in a "feature" in Electrum where the server you connect to can send you a well formatted message (containing a link like the posted screenshot for example). It may not be completely similar but Bitcoin-Core's alert system comes to mind which was a point of weakness that could be exploited in a similar fashion. That is removed now. |
|
|
|
|
520
|
Bitcoin / Electrum / Re: There has been an increased number of "fake" electrums out there, be careful.
|
on: December 27, 2018, 06:18:49 AM
|
Do you know if they think it was just the standalone client that is the issue or is it malicious files aside from it?
If you have downloaded the files (standalone, portable, linux tar.gz file,...) from anywhere else other than the legitimate links, then they are all malicious and should not be used. There is not even a single chance the pop up came from the official Electrum. That's a fact.
The "pop up message" that I posted in OP is appearing in Electrum (the real wallet software). It was a bug that was being exploited where the server can return an error message and it showed up like what you see in your wallet. The error message is returned when you send a transaction. |
|
|
|
|
Show Posts
