|
The first four bytes are the version bytes.
The magic bytes are only for networking and they prepend every single message sent over the network. Those are just identifier bytes to identify that the message is for bitcoin.
You should consider reading all of the documentation on bitcoin.org.
|
|
|
|
Then the transactions get only checked against the merkle tree, which can contain all segwit transactions too, as long as the basetransaction is in there too.
But the transactions or the merkle tree plays no role in the calculation of the block hash?
The merkle root is part of the block header and the block header is what determines the block hash. |
|
|
|
Can anyone explain the major difference between a soft fork and a hard fork? And why is everyone afraid of soft fork?
Soft forks are backwards compatible meaning that people running old nodes do not need to upgrade. Hard forks are not so everyone will need to upgrade their software in order to remain compatible. People are not afraid of soft forks, they are actually the preferred method of the devs to deploy new features. It is just that people don't like SegWit which will be deployed as a soft fork. |
|
|
|
Why should soft forks deploy with 95% but hard forks deploy with 75%?
Why do you claim that soft forks deploy with 95%? Because they do. Just read the BIPs for soft forks .... Some specific soft fork proposals are set at 95%. Not endemic to soft forks generally. Got it. What is the soft fork threshold for the SegWit Omnibus? Anyone? It is the same as the other previous soft forks. Try actually reading the post I made because I stated that very clearly with references. |
|
|
|
So the actual transactions are not needed to calculate the block hash? And the transactions normally are only checked to see if they are valid but if they are valid then no checksum or something like that is created to calculate that the actual hash is correct?
They are. The merkle root is a field in the header that is the hash of all of the transactions. To check the validity of the merkle root and thus the entire block header, all of the transactions are hashed together to see if the resulting hash matches the merkle root. I wonder how i should react on this. I mean let's assume segwit nodes start with 10% of the hashrate. As an escrow i receive coins. But either these coins only moved on the core mining nodes or only moved on the segwit nodes. The end is i can't be sure if i actually received something of value or which chain will win at the end. When i trust segwit wins then actually core nodes might win and vice versa.
The only way to handle this might be to check that i received the coins on both chains, right?
Well this really is stupid when this is enforced this way. A soft fork with 95%, like it was done before it seems, would be way safer because you know the new thing won so far and it is very unlikely that it will lose then.
Soft fork deployment of 95% will happen. No fork deployed by developers will ever deploy without some sort of block majority. Oh that actually sounds like the soft fork is implemented similarly like previous softforks? I thought segwit nodes will start to generate segwit blocks right away. So even when segwit nodes would be sure that the miner rewards for their blocks will be safe even on the other chain, they won't create segwit blocks at all until they reached majority?
SegWit will deploy just as previous soft forks have. There is no point to immediately start creating segwit blocks as that is also dangerous. |
|
|
|
the consensus threshold is 75% and the grace period is 4 weeks (IIRC). This means, that they expect that the whole industry to upgrade in a very short amount of time. This is ridiculous; we can't even get the miners to agree on a single soft fork in that matter of time.
Would it help if I point out that, if the 75% threshold is reached, then 75% of miners (+/-) would have already upgraded? The 75% threshold is too low. Why should soft forks deploy with 95% but hard forks deploy with 75%? It is too low and there are too many miners still mining the old chain who would be able to keep that chain alive while the new one kept going. It is not proper deployment of a change in the consensus, which should require consensus (realistically the supermajority) to change. |
|
|
|
but then the flip side is that the whole second doomsday scenario lauda and ciyam suggest, which is that bigger blocks take longer to process.
(yep im using their own disaster theories against them)
and so the smaller miners would by default produce more blocks and so they would gain the blockheight, just by having less data to validate.
2mb miners would need to be ALOT more powerful than 1mb to gain the lead if there was not consensus
so as you said its all about the consensus and hashing power. and not a simple "2mb are evil doomsday".
I don't think 2 Mb blocks will require any significant increase in processing time. There will be an increase, but it will probably be negligible. Any ways, most miners are SPV mining so that doesn't affect them at all. exactly only in a change to the 'forking mechanism'(your words) to ignore older clients. and where the new 2mb miners have sufficiently more hash power to get ahead of the other miners with less processing time... and enough of the community of nodes not orphaning it. would we see the 2mb blocks win..
Well that mechanism (marking all older versioned blocks as invalid) is the current standard way to deploy soft forks. I think it will be the same for hard forks as well. so as i said its not a doomsday event as soon as 2mb blocks hit the network. it requires extra things to occur, some nefarious some involving dominance in hashing power and some involving enough node acceptance..
Right, but the split is not going to be 50/50. There will be a skew towards one side, and that skew will be enough to cause one fork to grow faster than the other. That is enough to cause a fork to two blockchains. If the big blocks blockchain is longer, then two chains will exist. If the small blocks blockchain is longer, then there may be a blockchain reorg in big blocks nodes that will force them down to the small blocks blockchain, but, for some period of time in between, it is in fact likely that two blockchains will coexist for some time. otherwise miners are just wasting more than 10 minutes making blocks that get orphaned if they basically dont get consensus or have enough power to stay ahead of the other miners every time.
i do see exchanges halting their service because orphans can make so called 1confirmed transactions suddenly become unconfirmed again. so they wont want to risk it.. or atleast raise the threshold to a higher number of confirmations before crediting customers with funds.
(sidenote: which is another reason not to trust 0 confirms or 1 confirms if your buying a porsche or a house. the risk of that exact block being an orphan today is about 2%(3 orphans a day(144 blocks) at the moment) the risk of orphans during a blocksize battle could be as much as <insert high number here>)
and lastly.. i think that if we ignore the nefarious miner doomsday scenario's..
and stick with logic and greed, miners wont be making 1.005mb blocks until they know consensus has been reached, to protect their revenues from becoming unspendable. .. which is another factor to take into account that its not a doomsday scenario. but more like paranoid hypothesis of nefarious factors all colluding into one targetted agenda
Generally waiting for a few confirmations is a good idea anyways. |
|
|
|
|
AFAIK They all do due to AML and KYC laws.
|
|
|
|
|
I think I can be of help here. Could you please let us know what the details are for this?
|
|
|
|
|
I'm not so sure about that. Although Bitcoin is not anonymous, it is still pseudonymous. If you are looking at transactions, you don't know who exactly is behind an address and where those Bitcoins in that address came from. You don't know whether the money is from fraud or from legitimate business. And with mixing services and through other methods of anonymization like CoinJoin, it can make tracing Bitcoin extremely difficulty such that it is impossible to know who actually committed a crime and used Bitcoin to launder the money.
|
|
|
|
|
First of all, private keys don't work like that. The private key that you are generating is a private key in Wallet Import Format (WIF). Any key that attempt to generate as you are will, in most cases, result in an invalid private key due to the way that WIF private keys work. They are a raw 256-bit private key encoded in a way that includes a checksum, and if that checksum doesn't match, then the key is invalid.
Secondly, you aren't going to get any coins from doing this. It is a waste of time. There are so many possible addresses out there that the probability of finding an address that has coins on it is incredibly low. If you did find an address with coins on it, it probably won't happen again.
The problem you are having probably has to do with the way you generated the WIF key. The key itself was most likely invalid, but depending on the software you generated an address from it with, it probably mapped to some address that had some small amount of coins in it but the invalid key means that you cannot import and spend.
|
|
|
|
Lauda and Ciyam. are forgetting that Orphans will happen to rejoin any differing chains. thus no long term hard fork. the only time there would be consistant 2 competing chains that never recombine. is if the implementations hand pick the miners they relay from and ignore the other miners. EG Core only connects to miners that produce 1mb blocks.. classic only connects to 2mb miners and ignores 1mb miners. (which is the doomsday scenario lauda and ciyam are pushing.. intensionally) otherwise if they do get blocks from any random miner.. the orphaning part of the block game will sort out forks and re-align the chain. also 2mb implementations are able to accept 1mb blocks because the rule is not >1mb <2mb... its just 0 to 2mb (anything in between) so dont fall for the crap that 2mb implementations wont see blocks from 1mb miners. again that would only happen if 2mb implementations naferiously ignored 1mb completely. (which is not the case in a simple 2mb increase clean code) the only losers will be the miners that jumped the gun and made bigger blocks before consensus was reached. and so their orphaned blocks become unspendable. easy explanation without waffle..(A and B=1mb miners, C=2mb miners, all implementations read blocks from all miners)  so lauda and ciyam. try your fear mongering again.. but add in the context of orphaning.. to show its not as disastrous as you seem to want to make it appear Not necessarily. While that could happen if there was a roughly even split of the hash power, if one side of the fork has more than the other e.g. 75% vs. 25%, then that scenario is no likely to happen. The fork with the greater hash power will extend their chain to become longer than the fork with less hash power. Since their blockchain would be longer, it is considered valid over the other blockchain. However, for not upgraded nodes, that longer chain would be invalid since it would contain blocks larger than 1 Mb. Furthermore, depending on the forking mechanism, this may not be possible at all. If they use the forking mechanism which invalidates older versioned blocks (as is used now with soft forks), then any blocks produced by the old miners will be invalid because their version numbers are too old. If checkpointing is also used, then this scenario is not possible since one fork would have a history that the other fork does not. Due to the checkpoints, the upgraded miners would not be able to go back to the other fork which is what you are saying would happen. |
|
|
|
I initiated a transfer of 0.49 BTC at 2010 hours (GMT) on 01/02/2016 to 1AjFVtmaGSg3rwoSiRRVR6RzQzytyQVWDi I clicked the recommended transaction fee:  I was not trying to be cheap but the recommended fee for a fast transfer came out as 0.00001130 BTC and I was not able to choose a higher fee and so I sent the BTC. TxID: 410be500d42a2e8e57bfbc8ed6da06858cd7d81f6218581eaded0f35cd98d78d Now it's 2 hours later and numerous blocks and the transaction is still unconfirmed. Well, as you can see in that picture, it says "Smart fee not initialized yet". That means that the estimated fee is not very accurate so you should have set the fee manually. Since the fee for the transaction is low, it won't be confirmed soon. You have a few options. You can attempt an RBF transaction which simply sends the transaction again but with a higher fee. Or you can try a CPFP transaction where you send another transaction that spends from one of the outputs of this transaction. That new transaction will have a high fee, high enough to cover both transactions. Or you can just wait for it to either become confirmed or drop from the network. If it drops from the network, you can send again with a higher fee. Is there any way to estimate how long it will take for it to be confirmed? A transaction "matures" right? in the sense that it gains a higher priority as times goes on. Is there a way to monitor this or is there a way to cancel the transaction as it is still unconfirmed?
Nope and nope. There is no way to estimate how long it will take as there are many different variables. There is nothing that makes a transaction "gain priority" the longer it is unconfirmed. There is nothing that does that and that idea is completely false. |
|
|
|
|
You can only earn 14 activity every two week period. you have already earned add much activity that you can have and must wait for the next period.
|
|
|
|
it's on the offline computer so screen shot annoying to do, but also unnecessary because if I deselect 'paper backup root' (looking for only the private keys), the only information provided looks like this:
Created: YYYY-MM 05:45pm
Wallet ID: XXXX
Wallet Name: XXXX
If paper backup root is included the only difference is now I get the root key and chain code which represents the backup of the entire wallet.
Are you sure that you used that wallet? Does the option for "Include Unused (address pool)" exist? If it does, try checking that. |
|
|
|
Updated but now I can't even get in. I type in my pin and it says unexpected error please try again later.
Honestly, I don't know why that would happen. The best thing for you to do would be to contact their support and get help from the service directly. |
|
|
|
Android blockchain app. Not sure what version.
It is under Settings > About Us. The latest version is 5.1.6. If your version is not that, upgrade and then try again. |
|
|
|
When I hit send I get
invalid response non-canonical signature
Thoughts? The btc were deposited just 8 days ago to the address.
That would be due to the app producing High S signatures which are now non-canonical. What app are you using and what version is it? |
|
|
|
Ok so this is close to what I was able to do right away with wallet 1 of 2. With this wallet I got a ton of addresses, and so far I've been able to sweep 6 of them, but 3 were empty and the other 3 had smallish amounts.
However, I didn't see the *exact* option "back up this wallet," instead I was able to choose from "make paper backup" or "backup individual keys" - assuming this is due to it being an older version of armory on an offline computer.
That is probably the case. I am basing these instructions off of the latest armory, 0.93.3 But now the main issue is that my 2nd wallet on there isn't providing me any individual keys when I select this option.
Strange. Screenshot? At the moment working hard at manually deleting spaces and checking the various addresses for coins, but only from wallet 1.
In my version of armory, there was a checkbox to omit the spaces. Check to see if you have that in yours. It will make copying much easier. |
|
|
|
|
Show Posts
