MultiSig is a P2SH... it's not just a simple "attach a signature" like a "normal" transaction, so while it's true that only one sig is needed to spend for a 1-of-2... you still need to include the full redeemscript, which will need to be provable for BOTH sigs, so will require you to provide TWO pubkeys... Have a play with the calculator here: https://jlopp.github.io/bitcoin-transaction-size-calculator/Noting that for a P2PKH transaction, #sig=1, #pubkeys=1, but for a 1-of-2 P2SH, #sig=1 and #pubkeys=2... if we are creating a single P2PKH output, it'll gives transaction sizes of 192 bytes v 231 bytes respectively. This gives a good breakdown of it: https://bitcoinops.org/en/tools/calc-size/You can see how in P2PKH: 1 sig + 1 pubkey, whereas in the 2-of-3 you need 2 sig + 3 pubkey... likewise with 1-of-2, you need to have 1 sig + 2 pubkey
|
|
|
oh... duh... the addresses were listed there! hahaha
Yeah, likely an altcoin wallet.dat... if you open that wallet.dat with a text editor and do a search for "name" you should find the addresses listed in their "native" format... the first character should hopefully give some indication of what coin it actually is
|
|
|
Hard to tell really... Until you've synced the blocks past the transaction date, it won't properly show as confirmed in the wallet. Like we've said, goto the "Transactions" tab... right click on one of the Transactions... "Copy Transaction ID"... then search for that TransactionID in a blockexplorer like blockchair.com, blockcypher.com, btc.com, blockchain.com If the transaction is found, then chances are they will turn out to be real in your wallet! Then it's just a matter of whether or not any other transactions have occurred since 2013 that have spent those funds.
|
|
|
You'll have to show your full script... there is obviously something elsewhere in your script which is overriding your chance setting that is done in the if (< 3 or > 97) block...
There is no way it should have reset to 97% unless there is another code branch setting the chance somwhere.
|
|
|
Yeah... I'm an idiot... but, in my defense, I've been doing mostly Python programming lately!! The correct the syntax for "combining" multiple outputs for a print() statement in LUA is ".." not "," Try: function dobet() print("Roll: " .. lastBet.Roll) if (lastBet.Roll < 3.3 or lastBet.Roll > 96.7) then chance = 49.1089 end ...
|
|
|
My concern is that the transaction is "grey" and in [ ]'s which generally means that while the transaction is stored in the wallet.dat's history, it doesn't actually exist in the blockchain itself. This could be because the transaction was actually in an "orphaned" block and/or it was invalidated by a "doublespend" etc... in which case, you probably won't have access to those funds. I would suggest that you go into the transaction list tab, right click that 300+BTC transaction and then copy the "TransactionID" and then check that transaction on a block explorer like blockchair.com. If the transaction exists on the BTC chain, and those coins haven't been spent in any transaction after the date shown (25th Oct 2014), then there is a chance you may have 300 BTC. Congrats! If that Transaction does NOT appear on a BTC explorer, then there is a chance that the wallet.dat is actually an altcoin wallet.dat (ie. Litecoin or Dogecoin etc)... or it was an orphan block/doublespend situation.
|
|
|
Tried that and it wouldn't read the print fuction, even after fixing the "lasbetBet" mis-type
As in, it created a syntax error and the script didn't run or it just didn't print anything out into the console window? Also, my bad with the typo!
|
|
|
Wouldn't it be better for him to create 1-of-2 multisig wallet involving both desktiop and mobile?
No, a 1-of-2 MultiSig is relatively pointless... It introduces unnecessary complexity and increases transaction size... additionally, it can make recovering funds into different wallet apps very difficult/impossible. Either use the same seed on both devices... and have the wallet "mirrored" or "cloned" (or whatever you want to call it.) and both devices will have identical addresses/transactions/balances and you can spend your funds from either. OR create 2 completely separate wallets on the 2 devices and operate them as independent wallets... in which case, if you want to get funds to the Electrum app on your phone, you would need to create and broadcast a transaction from the desktop wallet on the laptop (and pay the transaction fee etc).
|
|
|
It sounds like your Armory might have been configured to use a different type of "Change" address... What are your settings under: "File -> Settings -> Fee and Address Types": Is it set to "Auto Change" or is "Force a script type" set? If "Force Type", what is the "type" that it is set to? "Auto" will create change outputs that will try to match the recipient type in an effort to increase privacy (it makes it harder to determine what the change output is)... so it's possible that while your "receive" address types were "Legacy", your change outputs were going to "P2SH-P2PK" addresses or "Nested SegWit" (P2SH-P2WPKH) addresses. Goto "Wallet Properties"... and check the listings for your "Change Addresses"... it will show you exactly which addresses your change outputs are in:
|
|
|
What is the number of blocks being reported in Armory in the bottom right corner? It should say "Connected" (in green) and if both Bitcoin Core and Armory are fully synced, working correctly and communicating properly, that number should be >= 644757 (which is the current block height as at the time of writing this message). NOTE: If your number is less that 644757, it means either Bitcoin Core is not fully synced, or Armory has not fully processed all of the blocks from Bitcoin Core. The transaction to your "1BMgrV..." address was included in Block "545368", so if the number of blocks in either Bitcoin Core or Armory is less than this number, then Armory will not be able to "see" it, so it won't display. If you're "desperate" and just want access to your coins, and don't wish to use Armory going forward... then I would recommend you export your private keys and import them into another wallet. You can refer to my guide here on how to export your private keys (you only need the private key that matches the "1BMgrV..." address): https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691
|
|
|
ETH you'll want something like MyEtherWallet or MyCryptoBe careful when trying to use these websites... there are a LOT of scam "clones" designed to steal private keys. So take your time, double (or triple) check URLs and don't rush. As for wallet.dats, Bitcoin Core (and it's derivatives like Bitcoin Knots) are the only wallet applications compatible with "wallet.dat"... So, if you have a BTC "wallet.dat", then your only real wallet software option is Bitcoin Core. Likewise, if you have a "wallet.dat" for an altcoin like litecoin, or dogecoin etc... then you'll need to download the appropriate "Core" wallet for that particular coin. Generally, you don't need to download the full blockchain, you can export the private keys and then import those keys into a lightweight (SPV) wallet like Electrum etc... There are also ways to extract the keys from a "wallet.dat" without needing to use the wallet software (ie. Python scripts like PyWallet etc), but they're arguably more complex to use and can be problematic to use if you're not overly familiar with Python and running scripts from the command line.
|
|
|
I don't see anything obviously wrong with the code. The only thing I can think of is that the site you're using the bot with is setting the roll value to some bizarre value? Maybe add a "print" statement in to debug what the value of lastBet.Roll actually is. It should output to the Bot's console window. function dobet() print("Roll: ", lastBet.Roll) if (lastBet.Roll < 3.3 or lastBet.Roll > 96.7) then chance = 49.1089 end ...
|
|
|
Question. Are, the compiled files of bitcoin core on my ubuntu, also usable on a windows system too? If not, is it possible to compile the source files from ubuntu and create the executables for windows?
No, the binaries are not cross-platform... Linux and Windows executables are fundamentally different. So you cannot simply copy the "bitcoin-qt" to windows and rename it "bitcoin-qt.exe". Instead, you would need to follow the "build-windows.md" guide to cross-compile the Windows binaries using your Linux setup... this will build the Windows compatible ".exe" versions.
|
|
|
Theoretically it's possible if you continue generate address from the seed until you find prefix that match your needs. But you need to remember the index.
It's not quite the same thing... but someone already created an "HD" vanitygen... https://bitcointalk.org/index.php?topic=5243577.0Theoretically, one could run this on an airgapped machine, then restore the discovered seed mnemonic to a hardware wallet... et voila... "vanity HW"™ Of course, it's fairly obvious that the "security" implications of doing something like this are fairly horrendous.
|
|
|
... I know my pass phrase and password and I tried installing another up to date Electrum version(4.0.2) for the existing wallet on another computer. I've done this but no balance now shows under history tab in the new wallet version. What now?
Is the new Electrum just showing a zero balance but still shows transactions in/out? Or is the transaction tab completely empty? If it is showing some history but the balance is zero, then you'll want to check what address(es) your bitcoins are assigned to in the old version of Electrum... Then check those addresses on a block explorer. It's possible that your old version isn't syncing properly... and your coins have been already "moved"
|
|
|
This is still one of my pet peeves regarding Electrum... that it defaults to mBTC as the unit to display the balance I know it's easy enough to change, but it still seems to regularly catch out new users who end up getting "dust" errors when trying to send a transaction for 0.001 "BTC" not realising they're actually using mBTC and trying to send 0.00000100 BTC etc... or, like OP here, send less than the desired amount to the recipient and wonder where the rest of their coins went... It's still an excellent wallet tho!
|
|
|
Like I said, you'll probably need to capture all of the make output and then hunt through that to see if there are any obvious errors relating to building of "bitcoin-qt". You should be able to use a command like: That will redirect the output from the screen to the file make_output.txt... you can then copy/paste the output to pastebin.com or something like that. Can you also do a directory listing of the "./src" directory with "bitcoind" is located? Would prefer the text listing, rather than a screenshot of the file browser window.
|
|
|
Impossible to tell from that screenshot... What have you already tried to confirm whether it is working or not?
You'd need to check what your CPU load is, and whether or not the number of blocks in your blockchain are increasing etc...
It's possible that it's mining, but you don't see new blocks because the difficulty is too high for a CPU to mine "successfully"... it's also possible that modifications you have made have not been successful and that it isn't doing anything.
|
|
|
Yeah... you can't just pay any higher amount... there is a certain minimum threshold that you have to cross to get it accepted. Unfortunately, it's not a "fixed" amount as such... it depends on transaction sizes and fee rate used for the original transaction etc. So, trying to do this manually can require a bit of calculating (and/or experimenting) to make it work. I believe it is done this way to prevent a possible DoS attack scenario, by making it "expensive". I did a manual RBF about 2 weeks ago during the previous price pump... and do know that I was able to pay a lot less than the "minimum" that Bitcoin Core was trying to use... from memory it was still 5-6x the original fee... ~400 sats vs. ~2500 sats... for a transaction that was around 400 vbytes (~1600 WU)... Bitcoin Core wanted me to pay like ~50000 sats as the "bump fee" But I suspect it was also doing confirmation time calcs and trying to get within 25 blocks etc.
|
|
|
|