The goal is to apply the concept of Defense in depth, so in case the security controls for address 1D2xxxxxx fail, I want to be sure that bitcoin can only be sent to address 1Ji2xxxxxx. The idea is implemented, in Squares Subzero ( https://developer.squareup.com/blog/open-sourcing-subzero/). "One specific customization we implemented is the ability to enforce that cold wallets can only send funds to a Square-owned hot wallet. Such layering provides defense in depth; forcing an attacker to compromise multiple systems in order to extract funds. It is also possible to build additional layers, where each layer can tradeoff convenience with the amount of funds being stored (onion model)." The scheme that they described is implemented on the hardware itself; the hardware is designed such that it only signs transactions that spends to specific addresses. It is totally possible to do something like this, just that as long as you are able to extract the private keys, you will still be able to make a valid transaction and spend it. Something like this is easily bypassed, as mentioned with the private keys/seeds. We're more concerned about making it impossible to spend funds to other address, which would be marginally more useful though probably not necessary. I don't see the need for something like this as it'll just complicate the entire process even more, if the addresses that the hardware was coded to send to were also compromised. |
|
|
|
As far as I know, bitcoin supply can be manipulated but it wouldn't be the same because bitcoin supply is already set in stone and any further changes has to happen when it was still in development.
Yes. You can fork Bitcoin Core to increase the block subsidy logic or it's block intervals. It is never really set in stone; any changes to the consensus rules which is incompatible with other clients results in a hard fork. This means that someone can create a new Bitcoin with a larger block rewards. If you're going to generate a block with a larger block reward, it won't be accepted by the nodes running this current version of Bitcoin and thus both chain inevitably deviates. |
|
|
|
I've created a transaction at the end of January with 5.3 sat/byte and it went through in something like 30 minutes. The fees seem to have increased since then.
Sure did. The trouble is I have no idea when (even if) that will be possible
Even if Schnorr and Taproot, that would be fairly far in the future. Activation logic hasn't even been integrated yet.
I don't expect 1sat/vbyte to be viable in the near future. Electrum does automatically rebroadcast transactions if it isn't included in the server and if it doesn't violate the min fee (someone please CMIIW). Just creating a transaction with a fee that you're willing to pay would be sufficient. Don't worry about mempool min fee, if your transaction can't meet that criteria, it would almost certainly not get confirmed anytime soon anyways; there's 100vMB worth of transaction before you. |
|
|
|
Press on your wallet name on the top left. You should be directed to a page which says master public key and the other is the seeds which is censored.   |
|
|
|
|
Unfortunately I didn't really make a graph of minmempool fees but from my experience, the minimum fees tends to fluctuate at about 5 to 6 sat/vbyte.
The lowest transaction which I have confirmed so far is about 8sat/vbyte. On weekends, I use 10sat/vbyte for a fairly high probability. Would it be better to use mempool.space and see if you can find a suitable compromise?
** I don't exactly recommend people to switch servers for the sole purpose of getting lower transactions broadcasted. Reason being, even if you're able to push the TX through, it doesn't guarantee good propagation.
|
|
|
|
The signature isn't verified, OP has imported the public key before. It should still show the RSA key without knowledge of the PGP key, instead of a signature mismatch. As said, changing the file extension to something other than .asc can make it unusable for validation. Make sure that the file name of your .asc matches your .dmg as well. |
|
|
|
it's related to the blockchain technology. if you modify one block, then this block won't be accepted by others and discarded at last. you're definitely not the first who thought about this, the designer had already figured the solution  It's not about modifying the block. The sole reason why this doesn't work is due to the fact that the Bitcoin nodes enforces the rules individually. Any deviation from the rules will not be accepted, even if the block is valid for the most part. Modifying any block would make it invalid regardless. |
|
|
|
|
Anyone can crack the code. Just modify the block interval or the block rewards and you'll be able to increase the max supply. Problem is, due to your different block intervals (and as a result of the difficulty) and/or your different block rewards, you'll either reject the blocks generated by the network sooner or later. Effectively, you're forking Bitcoin. As a result, you're running a different Bitcoin with different rules that no one follow excepts you.
If you persuade everyone to follow your fork and replace the current Bitcoin, the effectively max cap would be raised. If no one wants to follow, nothing happens for everyone else.
|
|
|
|
|
It is enough. Tails doesn't save any data within the USB that lasts beyond a reboot. This means that if you don't save the seeds, your Electrum will be gone without the seeds. Enabing persistence will allow you to use Electrum across reboots without having to restore everytime.
|
|
|
|
There IS a standard for signing messages from any address type available, and it has been around for many years now and is recognized by major bitcoin implementations. If one software doesn't have the feature then it is that software's flaw and you should complain to their developers about why they haven't implemented such an old feature.
I don't think Bitcoin Core implemented either of the BIP? Or I can't find any of sign of the two being implemented. Yes, it's possible to sign a message with the private key but you cannot refer to the bech32 address directly in doing so; exporting key-> sign message. You have to access the console to call signmessagewithprivkey and use your private key to do so. |
|
|
|
Segwit usages begin with non custodial wallet usage and then choose a good non-custodial wallet that support Segwit address. Two first acceptances need to be done before other things can be done.
People can not control what exchanges do and accept but they can always save fees on their activities. They always have options to choose and Segwit is one of such. If they reject their control, they can not blame it on exchanges.
Custodial wallets can also support Segwit and save on the fees, so I'll argue that usage of non-custodial wallet is out of the equation. From what I've seen, most people actually don't bother to move their funds from legacy addresses after they receive it from their exchange. Mostly due to the fact that people hardly use Bitcoin for their normal payment and thus don't usually face an issue. If you're not going to give the user an option to use segwit addresses, then the user might be less motivated to use Segwit from the on-start and exchange might be contributing to network congestion as well. I personally wouldn't support them as the costs are usually borne by the user in one way or another. |
|
|
|
|
You've gotten the error, perhaps google it first?
How are you sending the transaction? Is the transaction for which you're spending the funds from unconfirmed?
|
|
|
|
You can send from one address to another, if you want to send to segwit from exchanges, it is possible irrespective of the bitcoin address you are using. There are some exchanges that only support legacy addresses, there are some that only support only compatible (3) addresses, there are some that support segwit (bc1) addresses, but segwit or legacy, the withdrawal fee are constant on exchanges. I will still also prefer segwit (bc1) addresses than compatible (3) addresees on wallets because of low fee.
If they don't support P2SH addresses, then it's probably poor implementation and I would rather people not support them. P2SH has been around since 2012, which is probably earlier than what most services were established. Withdrawal fees are usually the same for all address types when using exchange. The problem arises when you're trying to spend it. No matter what happens, you're going to have to spend more when you're spending your Bitcoins. As most wallets only support generating one of the three address type in the a single wallet, it's entirely possible that the user will end up never using Segwit addresses. |
|
|
|
Transactions with Segwit addresses can help you to save fees. You need to check platforms you are using that they support Segwit or not support it.
You can use your Legacy or Segwit address to send your bitcoin to any type of address.
If you want to withdraw your bitcoin from exchange to a Segwit address, the requirement is that exchange support Segwit for withdrawals.
Supporting P2SH (which they obviously should) is probably sufficient. Using nested Segwit will allow for still a significant savings as compared to legacy addresses. I can't really see any disadvantages of using it, though there isn't a current standards for message signatures but that isn't exactly a dealbreaker either. |
|
|
|
Use walletpassphrase PASSWORD 600 to unlock it for 10 minutes. Use to list the addresses. |
|
|
|
|
Generating your seeds offline has no effect whatsoever. You're still going to be exposed to threats if your computer has ever been online or will be connected to the internet in the future.
If you're talking about generating seeds offline via the use of a clean air-gapped computer, that reduces the attack vectors available for adversary as the main method is through the internet. It should be possible with any wallets. If your wallet needs an internet connection to just generate wallets, then I'll be wary.
|
|
|
|
Having written this, I probably want to explain not the technical, but the political and economic problem of bitcoin.
Bitcoin cannot be integrated into the existing centralized government system because governments cannot rely on third-party hardware and software, and people in government cannot trust each other.
Bitcoin can only survive in an anarchic environment or die.
Every government functions differently. It should be sufficient for them to engage someone to audit it regularly. If anything, SolarWinds just proves how easy it is to do something like this, if it gets to Bitcoin. Having government adopting Bitcoin is an unrealistic expectation, defeats the purpose of fiat in an economy and probably isn't desirable given that capital flows can't be controlled any longer. Technological barrier and security is honestly not their main concern. Bitcoin can survive in its current stage, you can't create vulnerabilities out of thin air; if you can sufficiently minimize the attack vectors, then there wouldn't be a big issue. |
|
|
|
Are you absolutely confident in the security of bitcoin client that you use? Are you absolutely sure in the security of OS that you use for the bitcoin client?
Are you always confident that the binaries you download do not contain a backdoor?
Are you absolutely confident that when you download a repository from a github, you download the original code? Do you check the hash every time?
Are you absolutely confident that open source guarantees no backdoors inside? You probably read it all after downloading from github?
Are you absolutely confident re that your compiler does not have a backdoor built in to embed a backdoor? Are you confident that the compiler that built your compiler does not have a built-in backdoor?
Are you absolutely confident in your hardware?
One hole anywhere is enough to lose all your money. You cannot check everything. Organizations that will use cryptocurrencies will not be able to verify everything. Bitcoins are very easy to steal due to the human factor.
If bitcoin becomes widespread there will be a great interest in finding and creating such vulnerabilities
I'm almost certain that most people would be answering no for the most parts. Reading the source codes line by line is not feasible; Windows is not open source and reading the codes of any Linux distribution is tedious to say the least. If you are that paranoid, then it would be difficult for you to feel safe. That is unfortunately how Bitcoin actually works and the truth is that you can probably never be fully secure. The only thing that most people can do is to try to reduce the attack vectors and its possible surfaces; cold wallets isolates itself and preventing communication to the outside world. Generating sufficient entropy yourself puts RNG problems out of the equation, though you'll have to trust that the process to convert it to a private key isn't compromised. If you are actually that paranoid, then you can probably take some time trying to learn and read it. Not going to comment on how many people would actually do this, but it is a way to eliminate most doubts. |
|
|
|
Only if the derivation path doesn't contain any hardened index.
Yep. Hardened derivation paths doesn't have master public keys, or am I wrong? |
|
|
|
I share my public key with a lot of untrusted third parties or unprotected devices. And the following questions arise in my mind:
If you share your master public key, the BIP32 one, it can be compromised when an attacker has both that and one of the child private key generated from its corresponding master private key. If my computer contains viruses, is there a risk of modifying watch-only data and inserting a suspicious public key? I mean, scammer adds their address when I click deposit.
Incorrect new transaction sign request created. scammer will change my sign data request.
I'm assuming you're talking about an air-gapped wallet setup? There is a reason why most hardware wallets also have a screen on the device itself so the user can check the address again to see if it has been changed. Otherwise, there is no real risk of exposing your addresses (or public keys), they are pretty much available publicly when you spend the coins anyways. You cannot change the address of a signed raw transaction without invalidating it. |
|
|
|
|
Show Posts
