Subtle:
Like a brickwall across a freeway... Obvious alt is obvious!  I mean, who creates an account, just to comment on a gambling scam accusation thread 7 minutes after registering to basically say: "You need to use Game Protect" |
|
|
|
...that is the only case i can think of that says "pending" and doesn't ask for "fee" since you aren't making a transaction.
It also says "Pending" and never asks for a fee on 4.0.2 if you goto the "Send" tab and put in an Address and an amount and click the "Save" button...  Basically, the OP has simply started the transaction process, but no fee has been set and it hasn't been signed. @jeangenie, If you don't want that transaction, you can simply right-click->"Delete" that "pending" transaction from the list on the "Send" tab... NO coins will be lost! If you still wanted to send it, you could right-click->"Pay" that transaction (and you'd see the fee setting windows or the transaction preview window if you have "advanced preview" set in preferences) |
|
|
|
...or regtest for learning purposes?
While not necessarily the original intention of the regtest (regression testing) system... it's certainly useful for learning without worrying about losing any coins etc  There is nothing stopping you setting up a regtest environment and then creating/signing/broadcasting transactions and then generating blocks etc. |
|
|
|
Transaction invalid: some outputs that it attempts to spend have been already spent or are no longer valid. It's a strange warning, it's the first time I've heard of it, how can it happen? How can you or the person who wants to scam you make this invalid transaction? when he uses a wallet support RBF, you will get RBF flag error. Not necessarily... you might get a "warning" that the incoming transaction is marked as "RBF enabled"... but it won't necessarily stop you from trying to spend those coins. For a lot of wallets, they are considered the same as any other "unconfirmed" coins. How can you send and get this error?
The error is caused because the "UTXOs" (ie. Outputs from previous transaction(s)) that the current transaction is attempting to use as inputs are: 1. "already spent" - which means another transaction that was using those same UTXOs has already been confirmed in a block and the UTXO is therefore no longer available to be spent as you can't spend the same money twice!  or 2. "no longer valid" - which means that one or more parent transactions is no longer considered a valid transaction, so any UTXOs that they created are likewise no longer valid. This is most likely because it was replaced before it was confirmed by using RBF or a double spend attack. Because the network is quite overloaded at the moment... it's fairly "easy" to create a low fee rate transaction that is not likely to get confirmed any time soon... and then replace it using RBF with a much larger fee rate transaction. So, it can be possible to trick people into thinking they've been paid, and then redirect the funds elsewhere using the high fee rate transaction before the original low fee rate transaction gets confirmed. If you are selling or trading NEVER send items/money etc until the receiving transaction has at least ONE confirmation... |
|
|
|
I used electrum to make that transaction. I kind of wish it let you choose a vbytes fee instead of a bytes fee if it detects a segwit wallet open.
As others have stated... it is a sats/ vbyte fee used in Electrum... It is simply a UI decision made by the devs to get the terminology the same across all transactions. It can be very confusing because when some places say "sats/byte" that do actually mean sats/byte... as opposed to sats/vbyte  I would definitely recommend that you stop using blockchai n.com and switch to one of the other explorers like: btc.comblockchair.comor blockstream.infoThat all do a much better job of showing the difference between bytes/vbytes and the matching fee rates |
|
|
|
Tried broadcasting that using ElectrumBCD and it said: error: {'message': 'the transaction was rejected by network rules. 16: bad-tx-version
...
Did you actually create this transaction in BitcoinDiamond "Core" wallet? or did you use a Bitcoin wallet like Bitcoin Core? It seems to have the wrong "version": if ( fCheckForkVersion && !tx.IsCoinBase() ){
if (tx.nVersion != CTransaction::CURRENT_VERSION_FORK ){
return state.DoS(10, false, REJECT_INVALID, "bad-tx-version");
}
if (tx.preBlockHash.IsNull()){
return state.DoS(10, false, REJECT_INVALID, "bad-tx-preblockhash");
}
}
Your transaction has version "2" ...
"size": 734,
"total": 1432237000,
"ver": 2,
"vin_sz": 6,
"vout_sz": 1
}
Whereas, the Bitcoin Diamond network requires version 12: /** The basic transaction that is broadcasted on the network and contained in
* blocks. A transaction can contain multiple inputs and outputs.
*/
class CTransaction
{
public:
static const int32_t CURRENT_VERSION_OLD=2;
static const int32_t CURRENT_VERSION_FORK=12;
// Default transaction version.
static const int32_t CURRENT_VERSION=CURRENT_VERSION_FORK;
I'd suggest downloading the Bitcoin Diamond "Core" wallet... and creating the transaction using that and see if it correctly populates the version field. |
|
|
|
how could i figure this out, if i get a "new" change address or an old one ? ( i use electrum )
You can view the transaction created in Electrum... "receive" addresses within your wallet will be highlighted green... "change" addresses will be highlighted in yellow. If you see an "output" that is green, it is most likely being recycled back into the original receive address. This generally happens if you create a wallet in Electrum that only has imported private keys (in the title bar at the top, it should say [imported]), because Electrum cannot generate new private keys/addresses automatically for this type of wallet... it will only ever have the private keys that you have manually imported. If you have a "standard" wallet... Electrum will generally automatically generate new change addresses as required. However, this wallet type will not let you import private keys, you can only "sweep" them. what if i'm not sweeping my imported keys but just sending to my general wallet ? does it hold my privacy level in any way instead sweeping ? You don't sweep imported keys... you either sweep the keys, which sends funds from those address(es) to a new address(es)... or you import the keys and the funds stay on the original key(s)/address(es) until spent... So, which one are you doing?  |
|
|
|
I got bored and started playing around with this... So, here is my pretty crappy 5 minute Python code that will take any form of the PubKey (compressed/uncompressed) and output the address of the compressed public key. NOTE: The hexstring -> int conversion for "y" should be both Python 2.7 and Python 3 "safe"... If you're using Python 3 there is the int.from_bytes() function available, which is a bit tidier. import binascii
import hashlib
import codecs
def public_key_to_address(public_key):
print('Wanting to convert this [%s] to address'%public_key)
output = []; alphabet = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
var = hashlib.new('ripemd160')
if public_key[0:2] == "04":
print("------------------------")
print("Found UNcompressed PubKey, converting")
#break into x and y components
x = public_key[2:66]
y = public_key[66:]
#print('x: ' + x)
#print('y: ' + y)
#convert hex str to int
y = int(codecs.encode(binascii.unhexlify(y),'hex'),16)
#test if y is "odd" or "even" and assign prefix as appropriate
if 1 == (y % 2):
public_key = "03" + x
else:
public_key = "02" + x
print("Compressed PubKey: " + public_key)
print("------------------------")
try:
var.update(hashlib.sha256(binascii.unhexlify(public_key.encode())).digest())
var = '00' + var.hexdigest() + hashlib.sha256(hashlib.sha256(binascii.unhexlify(('00' + var.hexdigest()).encode())).digest()).hexdigest()[0:8]
count = [char != '0' for char in var].index(True) // 2
n = int(var, 16)
while n > 0:
n, remainder = divmod(n, 58)
output.append(alphabet[remainder])
for i in range(count): output.append(alphabet[0])
return ''.join(output[::-1])
except:
# Nothing
return -1
pubkey = '041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E'
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
pubkey = '0408FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52520FAC06060EC7B3FEAE3F92EB840399B09E7E82AB332060D882ED4D4829D383'
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
pubkey = '021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7'
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
hardcorepawn@HardCorePC:~$ vi pubkey_fun.py
hardcorepawn@HardCorePC:~$ python pubkey_fun.py
Wanting to convert this [041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
------------------------
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
Wanting to convert this [0408FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52520FAC06060EC7B3FEAE3F92EB840399B09E7E82AB332060D882ED4D4829D383] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 0308FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52
------------------------
CompressedAddress: 1NCasbMhu3gUjmN6nNmrX3Kqb2H6bzY6Lw
Wanting to convert this [021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7] to address
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
hardcorepawn@HardCorePC:~$ vi pubkey_fun.py
hardcorepawn@HardCorePC:~$ python pubkey_fun.py
Even Y uncompressed PubKey
Wanting to convert this [041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
------------------------
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
Odd Y uncompressed PubKey
Wanting to convert this [0408FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52520FAC06060EC7B3FEAE3F92EB840399B09E7E82AB332060D882ED4D4829D383] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 0308FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52
------------------------
CompressedAddress: 1NCasbMhu3gUjmN6nNmrX3Kqb2H6bzY6Lw
Compressed PubKey
Wanting to convert this [021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7] to address
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
hardcorepawn@HardCorePC:~$ cat pubkey_fun.py
import binascii
import hashlib
import codecs
def public_key_to_address(public_key):
print('Wanting to convert this [%s] to address'%public_key)
output = []; alphabet = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
var = hashlib.new('ripemd160')
if public_key[0:2] == "04":
print("------------------------")
print("Found UNcompressed PubKey, converting")
#break into x and y components
x = public_key[2:66]
y = public_key[66:]
#print('x: ' + x)
#print('y: ' + y)
#convert hex str to int
y = int(codecs.encode(binascii.unhexlify(y),'hex'),16)
#test if y is "odd" or "even" and assign prefix as appropriate
if (y % 2) == 1:
public_key = "03" + x
else:
public_key = "02" + x
print("Compressed PubKey: " + public_key)
print("------------------------")
try:
var.update(hashlib.sha256(binascii.unhexlify(public_key.encode())).digest())
var = '00' + var.hexdigest() + hashlib.sha256(hashlib.sha256(binascii.unhexlify(('00' + var.hexdigest()).encode())).digest()).hexdigest()[0:8]
count = [char != '0' for char in var].index(True) // 2
n = int(var, 16)
while n > 0:
n, remainder = divmod(n, 58)
output.append(alphabet[remainder])
for i in range(count): output.append(alphabet[0])
return ''.join(output[::-1])
except:
# Nothing
return -1
pubkey = '041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E'
print("Even Y uncompressed PubKey:")
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
pubkey = '0408FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52520FAC06060EC7B3FEAE3F92EB840399B09E7E82AB332060D882ED4D4829D383'
print("Odd Y uncompressed PubKey:")
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
pubkey = '021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7'
print("Compressed PubKey:")
print("CompressedAddress: " + public_key_to_address(pubkey) + "\n\n")
Output should be: Even Y uncompressed PubKey:
Wanting to convert this [041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
------------------------
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
Odd Y uncompressed PubKey:
Wanting to convert this [0408FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52520FAC06060EC7B3FEAE3F92EB840399B09E7E82AB332060D882ED4D4829D383] to address
------------------------
Found UNcompressed PubKey, converting
Compressed PubKey: 0308FD4E4E01356F3F0052E35FA186E54F736B209C025DFC5686FF98FF9A367A52
------------------------
CompressedAddress: 1NCasbMhu3gUjmN6nNmrX3Kqb2H6bzY6Lw
Compressed PubKey:
Wanting to convert this [021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7] to address
CompressedAddress: 1AYNNMBpXwV7kVveDmFALhCU8VTA3yTs88
|
|
|
|
Would be awesome if you could try it out. We keep working on improvements, so any feedback is important.
Is there a "TestNet" available? Or do we have to experiment using actual coins? |
|
|
|
I copy/pasted the files all together on a notepad..
What exactly do you mean by this? Did you open a bunch of different files in the Bitcoin Core datadir in a text editor... and then copy/paste all that data together into one file? If so, then you're probably S.O.L... the wallet.dat is a "binary" data file... it's not meant to be opened/manipulated in a text editor. |
|
|
|
I can't think of any that default to using uncompressed addresses.
Armory. Does it really? Well damn... I never actually noticed! Fairly obvious now that I think about it... all those WIFs starting with "5" in my screenshots!  |
|
|
|
If you're just trying to convert ONE uncompressed pubkey to compressed (or vice versa)... you can use this: https://iancoleman.io/bitcoin-key-compression/If you want to do it in code, then the algorithm is: 1. Starting with uncompressed Pubkey, drop the "04" prefix
041A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E
--> 1A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E
2. Split into X (1st 32 bytes) and Y (2nd 32 bytes)
1A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E
X -> 1A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
Y -> ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E
3. Determine if Y is "Even" or "Odd"
If Y = even, then compressed prefix = 02
If Y = odd, then compressed prefix = 03
ACCF8E941F95AE80B8F373229B7A3F83144160D8982E648F60C8E5CB968EC72E is an "Even" number, so Compressed Prefix = 02
4. "Compressed" Public Key = Compressed Prefix + X
Compressed Prefix == 02
X == 1A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
Compressed Pubkey -> 021A87E4688D8B9445B5B038CB3B34C186331F1AB4FC0822DCCA44192043EAB3B7
|
|
|
|
It seems suspicious how many new accounts have been trying to get help recovering wallet passwords. Seems that the sudden uptick in BTC value the last day or 2 is starting to bring all of the "get rich quick" folk out of the woodwork Not only is it "Help me recover password", there has been a number of "help me recover corrupt wallet.dat" (and also the usual "stuck transaction! help!1!!!!!!!!!!1111!!" ) posts... The scammers are likely doing a brisk trade. |
|
|
|
I have that same type of file (a little different/but same just older) and have been reading about going through the source code to retrieve the "redeem script" or the "derivation method" but first I wanted to ask .. what is that src/wallet/walletdb.cpp specifically? as I don't see any strings but I do see key all over..
It sounds like you have become very confused... I'm not sure what you hope to find by looking in the Bitcoin Core source... A wallet.dat is simply a "BerkeleyDB" database format file. You are NOT going to find any "redeem script" or "derivation method" for a wallet file that is as old as you claim by looking at C++ source code for Bitcoin Core. my python said "cannot import name 'generator_secp256k1' from 'pycoin.ecdsa" when trying to install bitwalletrecover. This means that you have not installed the appropriate Python library... specifically, this one: https://github.com/richardkiss/pycoinIn any case, I would suggest that you take a few steps backwards as you seem to be heading down the wrong path. Have you attempted to dump the contents of your wallet.dat using something like PyWallet ( https://bitcointalk.org/index.php?topic=34028.0)? One last tip... make a couple of copies of your wallet.dat and work on the copies, don't try and run scripts etc on the original version of your wallet.dat file. |
|
|
|
You seem to be forgetting the golden rule of "use cases"... which, as I was quite fond of telling my ex, is "Everyone is NOT you!" Simply because you don't see a need for X or you don't want to do Y with your device... doesn't mean nobody else does. I've travelled (internationally) with my ledger before... a small USB key like device barely gets a 2nd look from customs officials when you're travelling with a laptop and have 2 other similar looking USB keys in your bagetc... and having access to "emergency funds" when away from home for 3-4 weeks is useful... especially when your missus likes to shop up a storm! And I'm not sure why you seem to think that everyone here "worships" the Ledger... I like it, but as someone else mentioned, it's far from perfect... but then, so is my Trezor... and Electrum... and Mycelium... and Bitcoin Core for that matter... but I still use all of them and would be happy to recommend any of them depending on the use case. |
|
|
|
|
"odd" script types can be problematic on the forks... as often, most fork wallets and scripts don't provide facilities to use these opcodes etc...
If BCD actually supports OP_CHECKLOCKTIMEVERIFY, then you probably should be able to craft a transaction that would allow you to spend it, providing the locktime has actually been reached. You'd probably just need to do it manually.
|
|
|
|
In case this happens to someone, which tools are best to try brute force of key index - since user who is lost coins in combination Electrum+Nano S failed to find anything even though it generated millions of addresses? Probably just create a Python script that simply starts generating addresses from a specified index... given a seed or xpub. Could probably used parts of btcrecover (or the seedrecovery module in btcrecover) as a starting point. Then you'd start getting into complicated probability stuff that I don't really understand when it comes to the "generate sequential or random indexes?" argument... |
|
|
|
No, because once they are confirmed, they belong to an adress of which the private key belongs to bitpay, not you nor Chipmixer. so the key is the same but the owner changes ? No. As explained, if you send the bitcoins to Bitpay, once the transaction is confirmed, they will be assigned to the Bitpay Address (which will have a completely different private key to the one you received from ChipMixer. If there is any change from that transaction... ie. you withdrew a 0.1 BTC "chip" and only sent 0.08 BTC to Bitpay... then what happens with the 0.02 BTC change depends on what wallet you used to setup the transaction and/or how that wallet is setup to handle change. If the wallet creates a "new" change address, then the coins are now assigned to a new address (with a new private that neither Bitpay nor ChipMixer have any control over... only your wallet will have the private key. Transaction will look something like this: 0.1 BTC 1ChipMixerAddress -|-> 0.08 1BitPayAddress
|-> 0.02 1YourNewAddress <-- Only you have access to this
If the wallet does not create a change address, but sends the coins back to the original address created by ChipMixer, then you and ChipMixer still have access to the coins. Transaction will look like this: 0.1 BTC 1ChipMixerAddress -|-> 0.08 1BitPayAddress
|-> 0.02 1ChipMixerAddress <-- Both you AND ChipMixer have the private key for this
|
|
|
|
???it's not possible to stake BTC anymore
It never was possible to "stake" BTC... this thread is about "staking" your Bitcoin address... basically, post your address using a message signed with the private key of that address to prove "ownership". It can be useful later to prove your identity should your account become compromised (lost password/hacked etc) |
|
|
|
Is it possible to recover the wallet by just a wallet file alone? I am just curious because in order for me to access my electrum wallet, I need to input the wallet name and the password, and when I tried to import the wallet file, the password is also required. I'm a bit confuse as well here.
You need ONE of these: 1. The back seed mnemonic (aka 12/24 word recovery phrase) OR 2. The wallet file AND the correct password So, if you have just the wallet file, then you're out of luck... and your only hope is to try and bruteforce the password using something like hashcat or btcrecover |
|
|
|
|
Show Posts
