What happen if send BTC from legacy address to SegWit address?
The typical thing happens, your Bitcoin are transferred from a legacy address to a Segwit address. The address types really don't matter; the network doesn't care and such transactions are possible due to the soft forking nature of Segwit. You can even do it the other way around, segwit address to legacy address. It doesn't matter. |
|
|
|
|
Bitcoin Core does not store the address itself nor does it store the hash160 which is encoded by the address. Bitcoin Core stores the public key and its private key, but the address encodes the hash of the public key. You cannot compute the public key from the address, all you can really do is find public keys and compute their addresses to see if they match your address.
Luckily Bitcoin Core stores public keys in a fairly obvious form. They are prefixed with the letters "key" or "ckey" depending on whether your wallet is encrypted. Not that you cannot just search for these strings as there are other data in the wallet file that have the string "key" in them. Following the string will be a length prefix specifying 33 or 65 bytes and then the public key itself.
|
|
|
|
On one on our computers, on which we use Bitcoin Core, we are behind a NAT. Before 0.16, we had 8 incoming connections at most, but lately, we're seeing 16 incoming connections. Certainly speed things up. Thank you, I guess? Is this a documented new feature?
There was no such change that does that. Seeing your incoming connection count increase is normal behavior. |
|
|
|
i got a question, can i add 2 datapaths to the config so i could store 2 copies of the blockchain in 2 difference locations from 1 node thats running?
No, you cannot do that. |
|
|
|
the node accepts HTTP and RPC requests during regular operation, from other nodes in the network?
No, it does not. Connections from other nodes use the peer-to-peer network protocol which uses different ports and is not HTTP. |
|
|
|
1. What could be triggering this error?
RPC commands are being issued faster than they can be handled. 2. What can I do to avoid it? Settings recommended [ DO NOT POST SESC LINKS ]here[/url] fix it or just delay the problem?
You can set -rpcworkqueue to a number higher than 16. 3. Is there a log or a command that allows me to query and monitor the number and origin of RPC quests over time?
Start bitcoind with -debug=rpc and -debug=http. You will see information about the RPC commands and HTTP server stuff logged to the debug.log file. |
|
|
|
This issue is unrelated to hardware wallets or segwit entirely. It is solely related to the software that you are using (and yes, if you are using a hardware wallet, there is still a wallet software that you are using. Hardware wallets cannot operate completely standalone). Furthermore, the payment protocol is completely unrelated to segwit entirely; they only specify non-segwit in the guide because that is what they show for setting up Electrum. Unfortunately there is no known easy workaround for this problem. Bitpay has removed other methods of getting addresses from their website. The only method that I know of is to extract the address from the payment protocol data itself which requires other specialized software such as https://github.com/achow101/payment-proto-interface. |
|
|
|
|
addnode does not guarantee that a connection to the specified node will be attempted. If you want to guarantee that a connection will be attempted, then you need to use the -connect option.
|
|
|
|
While it's obvious that if the scammer saw this thread I'm trying to lay as low as possible in hopes to not cause him suspicion is there a way I could PM the video to you?
Sure |
|
|
|
Yes, that's one possibility I thought of. Maybe old TXOs that haven't been used in years.
But considering all the other files change at most every few days, and these haven't changed in months, it does seem odd.
cellard says all his chainstate files are with recent dates. Is it the same for you? And any 0-prefix files?
All of my chainstate files are fairly recent. No 0 prefix files. Since the database format has changed in recent versions, it's possible that those are old database files from previous versions. Are you able to check when those files were last accessed? |
|
|
|
This is a quote from Matt. "This needs to go into 0.3.24, so that users who downgrade don't mess up their wallet by adding unencrypted keys to an encrypted wallet, making all versions unable to use the wallet." It is my understanding that when using Cwallet that Matt changed the private key around 0.3.2.1- 0.3.2.3 and it would crash the wallet in 0.3.2.4. it was part of garzik code for encrypted keys that Matt worked on
Email me if you know the format of encrypted keys.
No, you understand completely incorrectly. As I said earlier, private key encryption was released in 0.4 and no earlier. Wallets prior to that were not encrypted. The problem here is that introducing encrypted keys changes the wallet format by adding things to the wallet that previous versions do not know. Thus the wallet will crash and become corrupted if you encrypted it with 0.4 and then downgraded to 0.3.x. The change for 0.3.24 was so that if someone downgraded from 0.4 to 0.3.24, the act of downgrading would not corrupt their wallet as it would with 0.3.23 and earlier. This has nothing to do with CWallet nor with 0.3.21-0.3.23. Encrypted private keys were not part of any 0.3.x version. |
|
|
|
Based on the low resolution (blurry) images, [1] is Bitcoin Core wallet?, [2] I have no idea, can't tell by the looks and I'm positive that [3] is Multibit, which are all made by different developers.
These are all Bitcoin Core wallets. The window that is screenshot is actually the Debug console which is a separate window that Bitcoin Core create when you go to Help > Debug Window > Console.
The icon is indeed supposed to change from closed to open when you unlock. This looks like a bug. Can you provide exact replication steps? |
|
|
|
Yup but that's what why I proposed a double lock system:
A double lock system does not get around the fact that it is still a UI/UX issue. Furthermore, you are asking users to remember yet another password. It seems that it is far more common for people to lose their coins by forgetting their password rather than having someone steal them. Even cases of stolen encrypted wallets seem to be quite low. By adding another password, you introduce yet another way for people to lose their coins. Forget one of two passwords and you are screwed. |
|
|
|
|
Just because the files have not been modified does not necessarily mean they are unused. Those database files are likely still accessed as they contain data that Bitcoin Core needs. However that does not mean that those file need to be modified. The data stored there does not always need to change.
|
|
|
|
|
If the wallet.dat file were fully encrypted, you would not be able to see your funds, get addresses, etc. without entering the password. This means that for the wallet to be useful, you have to prompt the user to unlock the wallet at start. Unfortunately this is not really easily done with bitcoind which does not have a GUI. Furthermore, it is not necessary for the entire wallet.dat to be encrypted because all that really matters are the private keys, and not anything else in the wallet file.
|
|
|
|
How can I spend money using createrawtransaction? I am not familiar with Segwit...
createrawtransaction is unrelated to this or to segwit. The problem is that the wallet assumes segwit is enabled by default, but segwit is not enabled according to your network rules. So you either have to enable segwit in the network rules, or change the wallet to assume segwit is disabled. How you do that you will need to figure out yourself. |
|
|
|
"txid": "551ba4bde3460bca6a6cae7da57ffd8b3f1baf18ad7a2e6d50f8d4f5b0a94e14",
"vout": 1,
"scriptSig": {
"asm": "0014620cfaeb631c99d45490cc6560a7258835c260f8",
"hex": "160014620cfaeb631c99d45490cc6560a7258835c260f8"
},
"txinwitness": [
"3045022100a1e4403c6327fb787ef498cfaf6c54f8372f2792c06a7156cad6cf15c729de2802201eb1b48e2443b04688091897caf0fc9afbfc002227c05441a5f1723be9a532e401",
"02533dc7b0e2d8f359fb235fd52bcda6135cfb0e39c6d9d93a10704457ff30e6ff"
],
"sequence": 4294967295
}
This is your problem, the input you are spending is a segwit input. You will need to figure out how to prevent your fork from creating segwit outputs that can be spent as inputs. |
|
|
|
Can you also post what your final signed transaction looks like? getrawchangeaddress shows this: 3PgBJaR5fCw9nBtij7THqfHbbENdCdFEuv
This will be a problem for you later because that is a segwit address and you do not have segwit enabled. |
|
|
|
I did not include any Segwit in any transaction. why does it show here?
Are you sure? If you forked from the latest Bitcoin Core, it uses segwit by default. Can you post what the changeaddress looks like and what the output of listunspent looks like? |
|
|
|
|
This error means that you are trying to spend from or create segwit outputs without segwit being activated yet. Is your node fully synced?
|
|
|
|
|
Show Posts
