i just want to ask , if it possible to add such a feature to this script :
if x amount of red comes in a row return the scripts to beginning.
Yes... the "streak" of losses will be stored in "currentstreak" as a negative number... which is what the script is currently checking for while doing the preroll. "if currentstreak < -preroll"... it checks to see if the losing streak is more than 5 losses in a row... then it starts multiplying. You can add a "maxlosses" variable... and check that, if exceeded then return to default settings: chance = 49.50
multiplier = 2
base = 0.00000001
preroll = 5
prebet = 0.00000001
nextbet = 0.00000001
maxlosses = 15
function dobet()
if win then
nextbet=base
else
if currentstreak== -preroll then
nextbet=base
end
if currentstreak < -preroll then
nextbet=previousbet*multiplier
end
if currentstreak < -maxlosses then
nextbet=base
currentstreak = 0
end
end
end
WARNING: I haven't extensively tested this code... use at your own risk  |
|
|
|
But if you make a mistake somehow with a letter off or accidentally deleted a character like m and put n instead... yes i know you should be copying/pasting the seed and never type it.... I know this is just a typo, but I really hope you aren't keeping some digital copies of your seed somewhere?! Sadly, despite the many warnings and recommendations NOT to do so, I suspect jerry0 decided to store his seed (encrypted) in a password manager like keepass/lastpass...Possibly due to his requirement for "easy access" while travelling. |
|
|
|
o god... I think my bitcoin might've been hacked or something?  does it look like it? All we can determine from that screenshot is that your wallet received ~0.005 BTC on the 21st Sept... and then the ~0.005 BTC was subsequently sent somewhere else on the 12th of Oct. If you didn't initiate the send transaction, then your wallet was compromised in some way. The most likely scenarios are: - Someone has a copy of your 12 word seed (did you store it digitally? screenshot? text document? email? cloud service?  ) - You downloaded and installed a fake version of Electrum that automatically sent your coins out. Check your browser history for where you downloaded Electrum from. - Someone got a hold of a copy of your wallet file and any password that the wallet file has. PC is possibly still compromised. You might also want to consider wiping your PC and reinstalling the OS to remove the possibility of any malware lingering around. |
|
|
|
Maybe we can back up the discussion a little bit and you guys could help me understand the different formats we are dealing with.
Using 4.0.9 I can choose to "export", and "copy to clipboard". This gives the transaction encoded in base64? And if I choose to "export to file" that is same base64 converted to ASCII?
Not quite correct... Electrum now uses the "Partially Signed Bitcoin Transaction" (aka PSBT) format when exporting "unsigned" transactions. As already noted, this psbt file format is defined here. The important thing to note is that it is a binary file format... there is unlikely to be any human readable text contained within it (aside from the "psbt" magic bytes at the the beginning of the file) As far as the Electrum exports are concerned: - When you use "copy to clipboard"... Electrum encodes that psbt binary data into Base64 text format (as copy/pasting "binary" data can be somewhat problematic). - When you use "export to file"... Electrum simply writes the psbt binary data into the file directly. Is there anyway to take either of these representations of the transaction and convert it to something that is in a human readable form? I thought I could take base64 string from the clipboard and convert it to hex using: https://cryptii.com/pipes/base64-to-hex Then, take the hex and use a tool like https://live.blockcypher.com/btc/decodetx/ to decode the hex to a json representation of the transaction. But this does not work. I think the hex is bad, but not sure. Correct... using that base64-to-hex converter will indeed convert the "Copy to Clipboard" Base64 encoded psbt data from Electrum into the "hex" output... The problem you have is that this hex is in psbt format... which is NOT the same format as a standard bitcoin transaction. This is why you get errors when trying to use a Bitcoin Transaction decoder. Having said that, the "raw unsigned transaction is actually contained in the psbt... and, the bonus is that it is included right at the beginning! So... the basic format of the psbt file is: 4 bytes - Magic Bytes - 0x70736274 (Magic bytes which are ASCII for psbt) 1 byte - separator - 0xff Then it should be the "global" key-value "map"... this is "variable" length, but the format is: key length - int specifying number of bytes of the key key data - the actual key data value length - int specifying number of bytes of the value data value data - the actual value data It looks quite confusing... but hopefully an example will give you some hope...  Here is a PBST from the "copy to clipboard"... so it's in Base64 format: cHNidP8BAKACAAAAAo6AHdHDG49pUtMKtxy4zCwK7QY0CtCwfwiV6Lh2yCnLAAAAAAD9////3pHCZunJoabQc89f5IJTdjhVVp/AeJ4l5/H07F4GTPYAAAAAAP3///8CgoOYAAAAAAAZdqkUB/HU3mNuQvFvSZiMjcF+lEMG0mWIrICWmAAAAAAAGXapFFC6xnhio5hP5yg5rw8U4roI5nZkiKyJAh0AAAEA3wIAAAABvezCKQ3mY4LrjFOE8dnESCz7sAxPbbcdtCcQW3+jMI0AAAAAakcwRAIgCgsC9bw0YySu2sgEkK850tLWOeAd7jkfZim5/qnAiR4CIHVOTuA54s1qSDJppXLs8sq67sVda4035Iey5ZL2Yb9yASEDsO+Ka7A1s9cQ+qU9wDR56hP3JKNYs1IIsse9j4NRhvr9////AiKTmAAAAAAAGXapFK69AmfhNVMSEueR6yJVEL5m8Dz+iKwA4fUFAAAAABepFKdL1i+Rxwfqhr1wpPq5plBjnoo4h28xGwAiBgJjb4/vozNp1NLAfAewBDLt5aFVaIx7T8zaf+hF8RnnTAxrFj/5AQAAACIAAAAAAQDiAgAAAAGVl0bY5YaEfpcoXrwvXsL+nklaBPo5bdMcjmXwqcxDwAAAAABrSDBFAiEAh1wXXt69BhgVXQQawnI+zW/Jfk0pzh+N9UFMrR0pUBsCIAdFzlefu+XaKOg47EUzC/5TCR8wdNQK4DcYcMezKdL4ASEDKmFJM+504tv6gZbkwercqdWhPDd2D625GiNlGZ7tWOr9////AlaImAAAAAAAGXapFCkJ7Rj8JufGcxWlejQCZvSMHUVHiKyAlpgAAAAAABl2qRReMpJuA8PCbLIc5Eq8oc23PKd8T4isCQQYACIGAgKXNL1Qs696n22XEACcUvK3QLnuW/IlECDWEmobjYw4DGsWP/kBAAAAFQAAAAAiAgIG2/DJxpZGsYyAQF4QkRbENKVzebjk/AwnOm7OcHeVkwxrFj/5AQAAACsAAAAAIgIDO6NEp2YaMzKa4YHss0Fxy6Wg5W/8A69EChNBZr/7w1EMaxY/+QAAAAAAAAAAAA==
We run that through the "Base64 to hex" converter (set "Group By" = None), which gives us this: 70736274ff0100a002000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00000100df0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00220602636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c0c6b163ff90100000022000000000100e20200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800220602029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c380c6b163ff901000000150000000022020206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece707795930c6b163ff9010000002b000000002202033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc3510c6b163ff9000000000000000000
Now, looking at the beginning of the file... 70736274ff0100a002000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb00000 00000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf600 00000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d 26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac8902 1d00000100df02000000.... We see: 70736274 == magic bytes ff == separator Then the "global key-value map" starts: 01 == length of key == 0x01 == 1 byte 00 == key value = 0x00 == "Unsigned Transaction PSBT_GLOBAL_UNSIGNED_TX" <--- This is the "key" we're after! a0 == length of data = 0xa0 == 160 bytes == 320 chars 02000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb00000 00000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf600 00000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d 26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac8902 1d00 == actual data value == the unsigned transaction hex! SUCCESS! If we put that hex into the decodetx utility... we get: {
"addresses": [
"1j1S6J5Azgju5PtpkwMLd5YMHBDD14BeP",
"18Mroim7a2auG6C9X8QEDAUgUx5hDKMzZj"
],
"block_height": -1,
"block_index": -1,
"confirmations": 0,
"double_spend": false,
"fees": 0,
"hash": "0334ca8de093b635b490ec4480764b8e4a5a0c524ae2825135dd2aa4e2903822",
"inputs": [
{
"age": 0,
"output_index": 0,
"prev_hash": "cb29c876b8e895087fb0d00a3406ed0a2cccb81cb70ad352698f1bc3d11d808e",
"script_type": "empty",
"sequence": 4294967293
},
{
"age": 0,
"output_index": 0,
"prev_hash": "f64c065eecf4f1e7259e78c09f565538765382e45fcf73d0a6a1c9e966c291de",
"script_type": "empty",
"sequence": 4294967293
}
],
"lock_time": 1901193,
"opt_in_rbf": true,
"outputs": [
{
"addresses": [
"1j1S6J5Azgju5PtpkwMLd5YMHBDD14BeP"
],
"script": "76a91407f1d4de636e42f16f49988c8dc17e944306d26588ac",
"script_type": "pay-to-pubkey-hash",
"value": 9995138
},
{
"addresses": [
"18Mroim7a2auG6C9X8QEDAUgUx5hDKMzZj"
],
"script": "76a91450bac67862a3984fe72839af0f14e2ba08e6766488ac",
"script_type": "pay-to-pubkey-hash",
"value": 10000000
}
],
"preference": "low",
"received": "2020-12-29T08:05:12.865990958Z",
"relayed_by": "3.86.86.99",
"size": 160,
"total": 19995138,
"ver": 2,
"vin_sz": 2,
"vout_sz": 2
}
Obviously, it won't always be 160 bytes for every psbt that you create, so you'd need to find and calculate the "data length" value and then extract the appropriate number of following bytes...
Otherwise, another somewhat simpler (and less error-prone) option is to use NodeJS and the 'psbt' package with it's decodePsbt() method. We simply pass in the psbt "hex" and it outputs the fully decoded "psbt" with the raw transaction displayed at the end, like so: > const psbt = require('psbt')
> psbt.decodePsbt({psbt:'70736274ff0100a002000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00000100df0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00220602636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c0c6b163ff90100000022000000000100e20200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800220602029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c380c6b163ff901000000150000000022020206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece707795930c6b163ff9010000002b000000002202033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc3510c6b163ff9000000000000000000'});
{
inputs: [
{
non_witness_utxo: '0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00',
bip32_derivations: [Array]
},
{
non_witness_utxo: '0200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800',
bip32_derivations: [Array]
}
],
outputs: [ { bip32_derivation: [Object] }, { bip32_derivation: [Object] } ],
pairs: [
{
type: '00',
value: '02000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00'
},
{
type: '00',
value: '0200000001bdecc2290de66382eb8c5384f1d9c4482cfbb00c4f6db71db427105b7fa3308d000000006a47304402200a0b02f5bc346324aedac80490af39d2d2d639e01dee391f6629b9fea9c0891e0220754e4ee039e2cd6a483269a572ecf2cabaeec55d6b8d37e487b2e592f661bf72012103b0ef8a6bb035b3d710faa53dc03479ea13f724a358b35208b2c7bd8f835186fafdffffff0222939800000000001976a914aebd0267e135531212e791eb225510be66f03cfe88ac00e1f5050000000017a914a74bd62f91c707ea86bd70a4fab9a650639e8a38876f311b00'
},
{
type: '0602636f8fefa33369d4d2c07c07b00432ede5a155688c7b4fccda7fe845f119e74c',
value: '6b163ff90100000022000000'
},
{
type: '00',
value: '0200000001959746d8e586847e97285ebc2f5ec2fe9e495a04fa396dd31c8e65f0a9cc43c0000000006b483045022100875c175edebd0618155d041ac2723ecd6fc97e4d29ce1f8df5414cad1d29501b02200745ce579fbbe5da28e838ec45330bfe53091f3074d40ae0371870c7b329d2f80121032a614933ee74e2dbfa8196e4c1eadca9d5a13c37760fadb91a2365199eed58eafdffffff0256889800000000001976a9142909ed18fc26e7c67315a57a340266f48c1d454788ac80969800000000001976a9145e32926e03c3c26cb21ce44abca1cdb73ca77c4f88ac09041800'
},
{
type: '0602029734bd50b3af7a9f6d9710009c52f2b740b9ee5bf2251020d6126a1b8d8c38',
value: '6b163ff90100000015000000'
},
{
type: '020206dbf0c9c69646b18c80405e109116c434a57379b8e4fc0c273a6ece70779593',
value: '6b163ff9010000002b000000'
},
{
type: '02033ba344a7661a33329ae181ecb34171cba5a0e56ffc03af440a134166bffbc351',
value: '6b163ff90000000000000000'
}
],
unsigned_transaction: '02000000028e801dd1c31b8f6952d30ab71cb8cc2c0aed06340ad0b07f0895e8b876c829cb0000000000fdffffffde91c266e9c9a1a6d073cf5fe48253763855569fc0789e25e7f1f4ec5e064cf60000000000fdffffff0282839800000000001976a91407f1d4de636e42f16f49988c8dc17e944306d26588ac80969800000000001976a91450bac67862a3984fe72839af0f14e2ba08e6766488ac89021d00'
}
|
|
|
|
It appears that OP has 114GB of disk space free in the data partition where the blockchain is being stored.
Aye... only just saw the "df" output in the debug file that the OP linked... I had originally scrolled right past it!  Disk space is definitely NOT the problem |
|
|
|
Seems that they finally took down the multibit website that actually had all the installers hosted on it... and the github only has the source code... so you'd need to clone/download the multibit wallet source code from the github and compile it... Failing that... I could upload a copy of the 0.5.19 windows installer, but then you'd have to trust that my copy wasn't "fake" or malware. Or is there any other way to get access?
If you know the password... you can decrypt the .key files using openssl... the trick is that they changed a setting in openssl a few years back, and there is an extra commandline argument that you may need to include. The explanation of the .key file format is here: https://github.com/Multibit-Legacy/multibit/wiki/Export%20and%20limited%20import%20of%20private%20keysThe recommended command line usually doesn't work: openssl enc -d -p -aes-256-cbc -a -in <encrypted.key file> -out <plaintext file>
and you'll get something like the following "bad decrypt" error, even if the password is 100% correct!!?!  : ...
bad decrypt
139987437556160:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:537:
But, by adding "-md md5" to the commandline, it should work as intended: openssl enc -d -p -aes-256-cbc -md md5 -a -in <encrypted.key file> -out <plaintext file>
If you need/want to practise using openssl on .key files... so you know that it's working OK... you can use this .key file I just created in multibit 0.5.19: https://keybase.pub/hcp/cwoern.keyAs you can see, the contents of this .key file is similar to the one you posted earlier: U2FsdGVkX18LSYm98B5HRgLWHgx35xMcsSpjjtdC9XG6iEYh9OC+vfyQA1fNmjEKs64cm/bntH7g
/AMeb5NNSEe9hzYAgp/DRvOR+GX9E95pGcl4Gb2AHGMyUfAww7uV
The password (when prompted by openssl) is: abc123 The unencrypted file contents should be: L2pUS76P4M1mPN98CRdHb64p2fVLzQuWQ44XadnsCospkiPjpweb 2020-11-29T16:15:26Z
NOTE: OpenSSL isn't included in Windows by default... but there are links to various binary downloads here: https://wiki.openssl.org/index.php/BinariesI have personally downloaded/used the OpenSSL 1.1.1i 64bit binary from the "curl for win" page: https://curl.se/windows/ (source: https://github.com/curl/curl-for-win#binary-package-downloads) and successfully tested it with the cwoern.key and password from above. |
|
|
|
When i send btc, i have to make sure the address is correct... triple check it many times before i click send. Obviously everyone should be doing this.
Yes, that is good practice... especially if you're copy/pasting addresses, to avoid issues with clipboard malware. But if you make a mistake somehow with a letter off or accidentally deleted a character like m and put n instead... yes i know you should be copying/pasting the seed and never type it.... but obviously it could somehow happen if you accidentally type in an extra letter or deleted a letter by accident and replaced it by another character... what typically happens?
The wallet software detects the address is invalid and displays an error. Nothing "bad" happens. I heard the odds of it being sent to another address was almost impossible... is that correct or not?
Correct. Like could you be off a character... and that btc address is actually a btc address? Thus you woulda sent btc to someone else by accident?
No. Obviously when you deal with big amounts, besides being very careful the address is right and the amount is correct... is make sure you are sending it with the recommended sending fee right? I can't imagine someone sending something like 5 btc... then pay like the minimum sending fee on their nano ledger s? Why not? If you're not in a hurry, sending with a minimum fee is fine... the fee rate used has no bearing on the "security" of the transaction, nor whether you entered the correct fee, nor the value of the transaction... if you're not in any particular hurry for the coins to arrive at destination, you can send with 1 sat/byte fee. If you need the funds to arrive quickly, using a "good" fee for the current network state is always recommended... regardless of the amount being transacted. If you're concerned, use RBF so you can increase the fee if needed. Also, stop using bold font everywhere. |
|
|
|
But right now what is the minimum usd amount it seem to cost right now if you send btc?
Depends on the data size of the transaction... you can still send with 1 sat/byte fee rates... it'll just take a while, given that there are nearly 50 something blocks worth of unconfirmed 1 sat/byte transactions currently.  Even with the massive spike in price... that's 0.00027 US cents per byte... So, a "standard" 1 in/2 out type transaction of around 200 bytes would be 0.054 US cents... obviously, if you want it confirmed quickly, you'd currently need to pay a higher fee rate (somewhere around 80-100 sats/byte at the time of writing)... which would be ~$4 - $5...  |
|
|
|
I saw this post on someone using a hardware wallet called keepkey and used a malicious chrome extension through google...
So what happened here then? This person typed in his keepkey seed? Again i don't know of any hardware wallets besides nano ledger and trezor... but this guy mentioned he used a hardware wallet.
Exactly, if you read the various details of that story (and any other involving loss from hardware wallets), it's generally because the seed has been compromised by either: - some fake piece of software that asks the user to enter their seed on the PC... boom! coins gone. or - user stored their seed in a screenshot, email, instant messenger, text document, other digital format etc. and it got compromised. Yea obviously you should not click on whatever link is in the email. But i got to assume it has to be malware/keylogger at least right? I can't imagine a hacker putting a link and you only get screwed if you actually type in your seed. I mean... wouldn't they make it malware/keylogger as well so then they can get into your email or say keepass/lastpass and thus they find your seed somewhere there?
Which do you think is easier and quicker to make (and more likely to success)? A website that says "hey this is Ledger website, please confirm your 24 word ledger seed here:" and harvests 24 word seeds... or create an installer for malware that goes targeting keepass/lastpass databases on the off chance the victim actually has those installed, and they actually stored their seed there (against all common sense and recommendations of NOT storing your seed digitally)? Also i assume the safe way to find out if a link has malware/keylogger or any malicious would be use a separate computer that uses linux or chromebook then? Or even if you use a windows computer, make sure its like a throwaway computer or a testing computer so to speak... to see what it is? I recall i saw some youtube video where a guy intentionally click on malware/virus/keylogger links to see what it did to their computer... and they used a virtual machine for that.
So someone installing a virtual machine or using linux/chromebook could possibly test this all out without risk to their main computer? But would there be any danger to their internet though?
Why does it even matter??!? Just DON'T click on the link... who cares if it's just a website asking for your 24 word seed or malware disguised as wallet software... there is literally ZERO reason (for normal users) to click on the link. Seriously, just delete the emails and move on with your life. |
|
|
|
but how do you know the exact price you received it then for tax purposes?
Again... there is no "exact" price... so you're asking for the "impossible" The best you can do is approximate... There are services that offer historical BTC prices (usually averaged across major exchanges to flatten out localised dips/spikes), usually via API's etc... that's how most of the "price history" charts work. How you choose to deal with that for "tax purposes" is up to your, your tax department and any rules they may enforce on calculating prices. I heard of that double spending with btc. So if someone sends me btc and say i send them cash or online funds... how do i make sure that transaction won't get double spend?
...
How do you counter against that? Do you look at the transaction fee that person paid for the transfer or how?
Transaction fee means nothing... The only thing you need to look for is number of confirmations. Zero confirmations means exactly that... ZERO confirmations, the coins could still be theoretically double spent in another transaction with a higher fee. These days, with the current level of total hash power, executing a 51% attack is nearly impossible... at the very least it would be insanely expensive. So, any non-zero number of confirmations (ie. 1 or more) means that the transaction is, for all intents and purposes, basically irreversible. If you're dealing in transactions of massive value (ie. $10s/$100s millions) you might want to wait for a few more like 3 or 6 etc.... but in general 1 confirmation should be enough and considered the absolute minimum. Same with RBF... if someone sends an "RBF enabled" transaction, it should not be "trusted" until there is at least 1 confirmation. At that point, RBF cannot be used to "respend" coins. |
|
|
|
I've noticed that on BIP39 total words on mnemonics can be either 3, 6, 9, 12, 15, 18, 21 or 24.
To be technically compliant with BIP39... they should be 12, 15, 18, 21 or 24 words. The BIP39 specification says the initial entropy needs to be between 128 and 256 bits. The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits.
Anything outside that range is technically not compliant with the BIP39 standard. Using mnemonic lower than 12 words, has low entropy and can be guessed by an attacker. While most of the wallets use the 12 words option, some others have different philosophy. For example, trezor chooses to use 24 words. Since 12 words are strong enough, why should someone use more than that? Does it offer extra security? I doubt.
(Isn't it 128 and 256 bits?)
Technically, yes... it does offer "more" security... but it's like saying that it's more difficult to get to Pluto than to Jupiter because it's further away... they're both a looooooooong way away and very difficult to get to... but one is technically further away than the other. Same with 128bit vs. 256bit entropy... the latter is theoretically "harder" to bruteforce than the other by sheer fact that it's so much bigger, but the former is already "impossible" to bruteforce anyway. Mnemonics tend to be easy to memorize, besides on their writing convenience. If you really want to keep your funds safe, but are afraid of losing them, you can try to memorize the words. I personally haven't, because I don't think I need to, but it's possible with only 12 words. With 24, it isn't.
Because attempting to memorise 12 words and keep them memorised over a long period of time is a recipe for disaster. There are countless threads on these forums where people struggle to remember all sorts of things (wallet passwords, words from mnemonics, what software they had installed, when they did things etc) Human memory is a delicate thing... a simple knock to the head from any manner of things can cause "permanent" memory loss. IMO, there is no way that memorising a 12 word seed is a way to "really keep your funds safe"... quite the opposite in fact. |
|
|
|
Have you checked the free disk space on the server again using the "df -h" command? It's possible that your server has simply run out of space for new blocks. From your earlier screenshots, it had something like 370gigs free before it had started downloading any blocks at all... my Bitcoin datadir folder is now pushing 400gigs... as I have txindex=1 set as well, and the tx indexes are taking up something like 28gigs on their own. |
|
|
|
So I installed this 1st on the 28th of Nov https:raw.githubusercontent.com/specnimo/specnilon/main/electrum-4.0.5-setup.exe
That's a fake (and now removed) github repository. You downloaded a fake version of Electrum which sent all your funds after you restored/opened your wallet file using it.  then updated using this DL address is electrum.org/4.0.9/electrum-4.0.9.exe later in December.
That is most likely the correct and legit version of Electrum, but by then it was too late Would it help to post the transaction ID?
No, your funds are gone. The transactions are irreversible. You will not be getting those coins back. I hope you didn't lose too much. |
|
|
|
I just noticed that "Multibit.key" had/has two lines and the second is actually 52 characters long (I miscounted before, not sure why I 'missed" the first line before). The first line has 76 characters.
It looks like this (I x'ed out several characters):
U2FsXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXTMMp7aMoHkdguZZVn7CPoyrwprwtfV95 (<--- doesn't look at all like the public address "1BRiwhJ2Av1PtB5XXXXXXXXXXEufDDedjd")
5Q1NKVXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXD5dlSO
The entire code isn't accepted, nor the first or second line individually entered (screenshot with several blanked out characters below)
multibit.key files were usually encrypted by default... the fact that the file starts "U2F" would indicate that is indeed the case. I suspect the fact that your 2nd line starts with a "5" is just a coincidence... and while it is 52 chars long, it is NOT a private key... the "l" and "O" at the end are a giveaway, as they are excluded characters in the Base58check encoding system used by Bitcoin. It's possible to decode that file and extract the private key, but you'd need to know what password was used to encrypt it in the first place when the export was made... Before I wiped the old computer, I seem to have copied the Multibit folder onto a memory stick, I also believe I must have generated/exported a "multibit.key" which was/is on the stick as well.
What is in the "multibit" folder that is on your memory stick? is there a .wallet file? That will more than likely be easier to recover your private keys from than the .key file... |
|
|
|
Has anyone here clicked on the link that those scam/spam emails posted and if so, what is it? Is it malware/keylogger or is it something else? Like asking you to type your seed? Could you lose your coins just clicking on those links? Read about chrome extension and how someone got their coins stolen in it... when they used a hardware wallet... but it wasn't ledger or trezor.
You can't lose your coins from a Ledger (or other hardware wallets) simply by clicking on a link... That is the entire purpose of hardware wallets. You would need to have the device connected and explicitly authorise a transaction on the device itself to send a transaction, and the private keys/seeds are shielded from external applications. The simple answer is that it doesn't matter what the link goes to (be it a fake version of Ledger Live, keylogger or a website asking for your 24 words), you simply should NOT click on it... it's obviously fake and a poor attempt to try and steal your coins. |
|
|
|
If he use "Copy to clipboard", it will result with a Base64 string; IDK for the "Export to file" but it looks like a 'binary version' like he said.
Ah yes... you are indeed correct. "Copy To Clipboard" option is a Base64 encoded string... the "Export to file" file is simply just the hex values written out to the file. I was unaware that the signed transaction will be exported in Base64. (I have not been able to get 4.0.9 to start yet for my offline wallet) So, at least I can still visually verify the signed transaction.
Yeah, I got it wrong... I assumed the "copy to clipboard" and "export to file" options were exporting in the same format... they're not! as per nc50lc's comment, clipboard is in Base64 (which can be decoded directly using the Bitcoin Core RPC tool)... whereas the "export to file" is just the ASCII encoded hex values... ie. just a binary file. Just have 2 more questions,
1. Is there an easy way to decode the contents of the unsigned binary encoded .psbt file that does not involve using Electrum?
2. Can someone recommend an off-line utility which will decode the contents of the signed Base64 encoded .psbt file?
So, you can simply open the .pbst file with a hex editor to retrieve the raw hex values... or you can use an ASCII to hex converter: https://www.rapidtables.com/convert/number/ascii-to-hex.html and copy paste the contents and it'll give the hex (set the output delimiter string to "None" if you use that converter). The file format is defined in BIP174: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawikiThere are a few tools floating around that will decode the PSBT... the easiest is the Bitcoin Core RPC online: https://bitcoincore.org/en/doc/0.20.0/rpc/rawtransactions/decodepsbt/ (or Bitcoin Core console itself if you have it installed, but that requires it to be in the Base64 encoding!) Otherwise, there seem to be various Python and NodeJS/npm libraries floating around that seem to handle PSBT data. Python: https://github.com/btclib-org/btclibNodeJS/npm: https://www.npmjs.com/package/psbt |
|
|
|
Can you give me a example code on how to change the currency during betting?
I've never actually tried... The currency name is stored in the "currency" variable... so just set currency == "currency_that_you_want"... ...
if lossstreak == 5 then
currency = "btc"
end
...
WARNING: doing this might play havoc with the GUI, charts and stats etc... as they won't be reflecting the change in currency correctly... here you can see a small script that goes from betting 10 PLAY to betting 0.00000001 BTC on crypto.games... chance = 49.5
basebet = 10
nextbet = basebet
bethigh = true
betcount = 0
currency = "play"
function dobet()
betcount = betcount + 1
currency = "btc"
nextbet = 0.00000001
if betcount >= 2 then
stop()
end
end
It purposely stops after 2 bets... but you can see how the graph and stats are messed up as both currencies are combined:   |
|
|
|
Can anyone tell me anything more about how the latest release handles saving unsigned transactions to a file? I like to manually verify all the outputs in the unsigned transaction file before I allow the file to be copied to a blank thumb drive. (And then loaded on the offline wallet to be signed.) Is there anyway to validate the contents of this file using something external to Electrum before signing the transaction? I tried to open the file but it looks like encrypted contents now. The documentation does not appear to be updated since this was changed.
It's Base64 encoded... and the data is in "Partially Signed Bitcoin Transaction" aka PSBT format... You can read about the PSBT format here: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawikiNOTE: Something like this tool will decrypt the Base64 to Hex: https://cryptii.com/pipes/base64-to-hex |
|
|
|
You could try starting Windows in "safe mode" and then see if Armory works. If it does, then it is indeed likely that another process that is launched at start up is interfering with ArmoryDB. You might need to try the suggestions on this thread to configure ArmoryDB to use a different port number: https://bitcointalk.org/index.php?topic=5106791.msg49610329#msg49610329 |
|
|
|
|
Show Posts
