|
They can't possibly be impossible. Software and projects already exist which use two way pegged sidechains.
|
|
|
|
If BIP148 is UASF (which doesnt require miners concensus) then why if some miners do not activate SegWit,there will be a split?
Because BIP 148 nodes and miners will enforce BIP 148 and reject any blocks which do not signal for segwit. If a miner is not signalling for segwit, then they will be producing blocks which are invalid under BIP 148 which the BIP 148 nodes and miners will reject. However those non-segwit miners and non-BIP 148 miners will still mine on top of the non-segwit block while the BIP 148 miners do not. This means that there will be one chain with a non-segwit block after BIP 148's activation and non-BIP148 miners will extend that chain. Meanwhile the BIp 148 miners will have rejected the non-segwit block and mined a segwit block at the same block height. They will then be extending on that block and thus mining on a forked chain. |
|
|
|
So this will become an issue mostly if either the BTC chain splits in 2 weeks or after the 2MB hard fork at the end of the year correct?
In 2 weeks if there is no splits, segwit gets activated we don't have to worry yet correct?
Yes. |
|
|
|
I wonder why Bitcoin Unlimited (BTU) team created Bitcoin Unlimited through hard-fork? is safe that they created Bitcoin Unlimited as new ALt coin?
This is absolutely nothing to do with Bitcoin Unlimited. So, Bitcoin Unlimited will be as Bitcoin, algo, protocol etc.. then why they make a split for? A chain split could happen because of BIP 91 or BIP 148. These two BIPs are completely unrelated to Bitcoin Unlimited. Bitcoin Unlimited is completely unrelated to this topic. What BIPs 91 and 148 specify is that all blocks after a certain mining threshold (BIP 91) or after a certain date (BIP 148) must signal for segwit or be invalid. Thus there can be a chain split of not everyone is signalling for segwit as they will produce a block that would be invalid under the BIP 91 or BIP 148 rules and if other miners build on that block (because of either spy mining or that they are not enforcing the activated rules), then there will be a chain split. |
|
|
|
Though i was aware of that theoretic solution - is that really possible with most wallets?
I saw some announcements recently from wallet providers, but i suspect not all wallets do even support this yet.
No, unfortunately many wallets do not give you the option to choose which nodes to use so you can't choose the blockchain that you want to use. Doesn't connecting to a "prefered" node open new attack vectors, like sybil and MITM attacks?
Yes. Because this is the development subforum:
Using the Hard Fork bit would fix this problem? (At least for 2 distinct chains)
Yes, although some software may need to upgrade to understand what to do if the hardfork bits are set. |
|
|
|
|
What site? Don't ask for permission to ask, just ask in a post.
If it sounds too good to be true, then it probably is a scam. If it is a "High Yield Investment Program", then it is most definitely a scam. If it is a cloud mining service, then it probably is a scam. Anything which promises returns which seem very high and unlikely to actually be possible in real life is a scam.
|
|
|
|
I have the private keys for multibit HD. Will that work out for me well?
Probably not. MultiBit HD does not allow you to choose which nodes you are connected to so you won't be able to choose which chain you want to use and transact on. It does not provide the (slightly) advanced functionality required to split your coins either. |
|
|
|
Private key.. ? I understand it's a wallet password?
Private keys are handled by your wallet. It is not the same thing as your wallet password. If you are using Bitcoin Core, then you are fine. If you are using any desktop wallet, then you will be fine. Any wallet where the wallet files are stored on your computer rather than with some online service is fine as you are in control of your private keys. |
|
|
|
|
Where did you hear that? In what way would running Bitcoin Core kill your hardware? AFAIK, Bitcoin Core won't kill your hardware. It just is a bit more intensive on it than other software so if there are hardware problems, you may notice them more obviously when running Core. It is recommended that you use an SSD as it will be significantly faster than an HDD.
|
|
|
|
I'm using a mining service that supports Segwit.
For the moment, that mining service sends me BTC each mouth on my "1example123" Bitcoin Core Wallet.
Let's say the fork happens and at the moment of the fork I have 0.5 BTC on my "1example123" Bitcoin Core Wallet.
Until I make a decision, I can have :
*0.5 BTC on my "1example123" Bitcoin Core Wallet
or
*0.5 BTC on my "1example123" Bitcoin SegWit Wallet
That mining service will start sending SegWit BTC after the 1st of August on my "1example123" address.
Lets say they send me, in August, 0.1 SegWit BTC.
Until I make a decision, I can :
*End up with 0.5 BTC on my "1example123" Bitcoin Core Wallet + 0.1 BTC on my "1example123" Bitcoin SegWit Wallet
or
*End up with 0.6 BTC on my "1example123" Bitcoin SegWit Wallet
Do I understand it right ?
First of all, this is not Bitcoin Core vs. Segwit. This is Segwit vs. non-Segwit. If the segwit chain is longer than the non-segwit chain, then Bitcoin Core will follow the segwit chain. To answer your question, you do not understand correctly. You can have both 0.5 BTC on your "1example123" Non-Segwit Wallet and 0.5 BTC on your "1example123" SegWit Wallet. If you are paid 0.1 to "1example123" on the segwit chain, then you can have 0.5 BTC on the non-segwit chain and 0.6 BTC on the segwit chain. There is no need to choose one or the other, you can use both. However using both does take a little bit of work to successfully separate your coins. |
|
|
|
Unfortunately neither of those two forks currently have any sort of reorg protection for lite clients. They both lack any actual specification and have been ignoring the advice of several Core developers (e.g set one of the BIP 9 hard fork bits in the version number so lite clients know that the chain is a hard fork). The only way to protect yourself from reorg is to make sure that you always connect to nodes which you know will be following the chain that you want to follow. How can this be intended design?
Both hard forks are designed by people who actively ignore those who have safely deployed consensus changes in the past; both are extremely rushed; both lack specification as to what they are doing; |
|
|
|
Unrelated to the functions as in not used, yes, but equal in strength is equal in strength. Again, I'm not talking decryption of public->private keys being a be-all solution to cracking wallets, but the level of strength is near or at the same levels, regardless of the protocols used. If you want to talk about ECDSA and cracking chains, let's talk hardwallets, going back to the original topic at hand. <snip>
You are completely misreading what OP asked about. What OP asked was: So, is there any added risk when one hardware wallet is used to access multiple different cryptocurrency wallets? For instance, is it possible that the Ethereum blockchain data could at some point be broken to obtain private keys/seeds and using this information also access the Bitcoin wallet, or vice versa?
He asked if there was any added risk with using the same hardware wallet on multiple coins. What you are talking about is risk that already exists with hardware wallets, BIP 39, ECDSA, etc. The only added risk comes from the blockchains used by the various coins, and the blockchain has nothing to do with your keys. |
|
|
|
If someone breaks SHA-256 they'll be able to break SHA-512 in short order, relatively speaking. The orders of magnitude beyond what's being done right now say it's so. All avenues for modern cracking point to quantum state side channel attacks being the most likely candidates. Deriving a means of bypassing locks isn't what I'm referring to. And since hardware wallets rely on ECDSA for the most part (512 bits in some cases, re: BIP39), breaking SHA-256 definitely does have bearing. Standard cryptographic models aren't going allow it to be broken, but novel ones will. The fact that entropic quantum entanglement and the entanglement measure is an NP-Complete measurement means that no one's been able to look at it, except in novel effects-related efforts. I'm currently looking at electromigration as a candidate for bearing said data as it's related directly to quantum discord. Call it irrelevant if you like, but the security-level for bitcoin is based upon standard models, not taking into account measures that are outside of the boundaries. We've seen that bitcoin blocks can be falsely generated with the initial genesis block, and derive from there. Yes, that's a straw man for now, but that fact doesn't negate the weak foundations. Again, call that irrelevant or also un-prove-able. If I had a working model I'd be sitting in Maui. So, "pics or it didn't happen" all you want, I'll just leave this here so someday when it occurs I can refer back to it.
I never said that SHA512 is unrelated to SHA256 nor did I claim that SHA-2 functions won't be broken in the future. What I said is that these hash functions are unrelated to private keys. Can you explain how you would get private keys from public keys if SHA-2 were broken? What data in the blockchain, other than public keys, private key for a public key? What data related to hashes in the blockchain can get you the private key to a public key? Getting the private key from a public key requires breaking ECDSA, not SHA-2. Even if you got a private key, you can't get the master private key or any other private keys in an HD wallet unless you also have the chaincode, but the chaincode is never put on the blockchain. |
|
|
|
Thank you! So Bitcoin Armory would allow me to access both coins after a potential split?
Armory uses Bitcoin Core to handle all of the blockchain stuff, so Armory will use whatever chain Bitcoin Core is following. You can have Bitcoin Core choose the blockchain to use, although switching blockchains may have some unintended consequences with Armory. |
|
|
|
Is it necessary to create the Watching Only Wallet? cause it is complicated, I don't really know how to do it?
No, you don't need to create a watching only wallet. How to import watch only? the pop up message says 'same name file'.
You can't import a watching only wallet for a wallet which is already in Armory. You already have the same wallet in Armory which is probably your non-watching only copy of it. That's fine and you can access and spend your Bitcoin. I always got this message says 'failed to spawn db', what is this means? should I do anything about it?
It means that ArmoryDB, the database backend process, is not starting. bitcoinarmory.com is not Armory's website anymore. There is no Armory contact email. If you want help, you will need to post here. What should we do if BIP48 introduced on 1 Aug? Is Armory supporting it? Is our Bitcoin saved in Armory wallet affected? Any action needed?
Armory will use whichever chain that your Bitcoin Core install uses. If that is BIP 148, then it will use BIP 148. If it is not, then it will not use BIP 148. |
|
|
|
You should use any desktop wallet listed here: https://bitcoin.org/en/choose-your-wallet that has "Full Validation" or "Simplified Validation" and "Control Over Your Money" listed in their descriptions. These wallets will give you the choice of blockchain to use (mostly) and full control over your private keys. |
|
|
|
|
Armory will use whichever blockchain that Bitcoin Core is using. So if there is a chain split, then you will need to set Bitcoin Core to use the blockchain that you want to use.
|
|
|
|
I'm using Xapo and coinbase, is safe to save bitcoin?
No. Your Bitcoin is at the whim of the service. They will choose which blockchain to use and you are subject to that. |
|
|
|
|
Why are you reindexing after changing wallets? There is no need to reindex as reindexing has nothing to do with wallets.
Anyways, 0.15 will be introducing multiwallet (for at least RPC I think) so you can use that once it is released.
|
|
|
|
At the beginning of this thread, it was stated that Bitcoin Core was able to handle both blockchains, and I quote: "The safest thing to do is to use Bitcoin Core as it is a full node and gives you control over which chain you want to use (via the invalidateblock and reconsiderblock RPC commands)."
I really thought that you would need 2 core nodes running now... one for the "original" blockchain and another for the "new" blockchain, but it makes sense the same program can run both just by an option on which one to use.
Can someone elaborate, or guide me to where I can find more information on how to select each blockchain? I thought that these commands were only to eliminate blockchain starting from the block indicated... but I can also see how that would make you to go form one fork to the other if you invalidating the block on the height of the fork. Still not sure I understand how that would "connect" you to the main blockchain, or to the alt blockchain.
After looking for 1 hour around for this, I think one of you might guide me since all explanations are not that clear.
Thanks in advance for the guidance!
You would need to perform these commands with the block at the height of the fork on each chain. For example, suppose that chain A has a block with the hash abcdef at the height of the fork. Suppose that chain B has a block with the hash 123456 at the height of the fork. To use chain A, you would do invalidateblock 123456
reconsiderblock abcdef
To use chain B, you would do invalidateblock abcdef
reconsiderblock 123456
You can use those commands to switch back and forth between blockchains. Note that switching back and forth may result in some undefined behavior and bugs. Since such a fork has not happened before, this method has not been tested in practice. Your mileage may vary. |
|
|
|
|
Show Posts
