If I am not mistaken, then if [malicious pool hashrate] + [non-SW hashrate] >51% of the network hashrate, then the malicious pool can trivially execute a 51% attack.
The malicious pool could find a valid SW block (block "n", block height "x"), release the valid block with invalid signature data (but would retain valid signature data). The SW miners would think the block is invalid and ignore the block, while the non-SW miners would ignore the signature data and build on top of the block. If a non-SW miner find a valid non-SW block, then the non-SW miners and the malicious miner would build on top of this n+1 block, and the rest of the SW miners would be still building on top of the n - 1 block. If another SW miner were to find a valid block (block "b"), and release the block with valid signature data, then the SW miners (less the malicious SW miner) would build on top of block b, which has a height of x, however the rest of the network would be building on top of a block height of x+1. This would continue until the chain containing block n has some positive number of blocks greater than the chain containing block x, and the malicious SW miner would release the valid signature data for his block n, along with the blocks already on top of his chain, causing a re-org.
That shouldn't be possible. The chain split could happen, but not the re-org, I think. This is because the SW miners and nodes will have received the block with invalid signatures, saved it to disk, and marked it as invalid. It should remember that a block with the hash of the invalid block was invalid. Then when the malicious miner tries to broadcast it again with valid signature data, the SW miners and nodes will see the block, see that the block hash is that of one it marked invalid, and ignore the block. |
|
|
|
You will need to copy the blocks and chainstate folders.
Okay. Am i need to copy database folder? No. |
|
|
|
|
You will need to copy the blocks and chainstate folders.
|
|
|
|
now here is where i get confused. can we use a real example. lets take this transaction that i got from blockchain.info 010000000118d68350c1dcda804cc1cf5d9137fea5ea90a2ec3ffee63c47881b42043197d301000 0006b483045022100b4004f6cc5fe81527b62b090a9c5cf0343e8d7e0092b749f797a0363cd1f8b9d022 03440e3f4dc6dc29f095b0a93eccf66b3fd9ac88713695bd71dc8ee61cc89776a012103424bf6a8 1b8b327631f044e11f18eb8fc665288739c5e72377614d3e7580721bffffffff0240933402000000001976a9140177884fc893f5264be7e424781f7574c7b3a6b788ac4 d3ed118000000001976a9141595049c14d3b94e24069e33480f9d182c518fea88ac00000000 i have made the scriptsig into bold. i am assuming this is what you call "the witness" correct? No. The scriptsig and witness are two separate things. The data that goes in the witness is the data that would go in the scriptsig if a witness output were a normal p2pkh or p2sh output. In this example transaction, if the output it is spending from was a pay-to-witness-pubkey-hash (p2wpkh), then the data that is in the scriptsig would be found in the witness. However, since the output is p2pkh, the data currently in the scriptsig would remain where it is even after segwit activates. my confussion is about where is this "field" really located. is it still inside the transaction?
Yes. It is still part of the transaction. The transaction format has been extended for segwit. if so then how will it look and how is it different?
Suppose that the example transaction you posted were spending from a p2wpkh output instead of a p2pkh output. The transaction would look like this: 0100000000010118d68350c1dcda804cc1cf5d9137fea5ea90a2ec3ffee63c47881b42043197d3010000006b00ffffffff0240933402000000001976a9140177884fc893f5264be7e424781f7574c7b3a6b788ac4 d3ed118000000001976a9141595049c14d3b94e24069e33480f9d182c518fea88ac02483045022100b4004f6cc5fe81527b62b090a9c5cf0343e8d7e0092b749f797a0363cd1f8b9d0 2203440e3f4dc6dc29f095b0a93eccf66b3fd9ac88713695bd71dc8ee61cc89776a012103424bf6 a81b8b327631f044e11f18eb8fc665288739c5e72377614d3e7580721b00000000 I have bolded the parts that have changed. The scriptsig is now empty, and what was in the scriptsig is now placed after the outputs. That field after the outputs is the witness. There is also a 0x0001 after the version number which lets us know that there is a witness field after the outputs. and also by "not counted" do you mean it is not included in the 1 MB block if so how can you verify the transaction later on?
The data in the witness is not counted as part of the 1 MB block. The transaction is still verified as it normally would be since any node that can understand segwit will require that the transactions it receives are in the segwit serialization format. This means that it must receive the witnesses or the transaction will be considered invalid. The same goes with blocks; all transactions in a block that have witnesses must be in the segwit serialization format otherwise the block will be considered invalid. so how will the new blocks look like?
They will look like they do now, but transactions that have witnesses will be in the segwit serialization format. will they take a larger space on the whole blockchain
Yes. After segwit activates, the amount of space that a block can take up is 4 MB. sorry if the questions are too newbish. i recently started getting a better technical understanding of bitcoin and reading the bitcoin wiki, ... i can easily understand things but when it comes to segwit, everything becomes complicated probably because i have not found anything as well written as the wiki and also there is no examples helping me "visualize it"  The BIPs contain all of this information with some examples too. Segwit is specified by BIPs 141, 143, and 144 |
|
|
|
So could it take less time, if I do a transaction just before a block is finished and my transaction is one of the last to take place in this block, right?
But if I am unlucky I make a transaction when the miner starts a new block so that have to wait till this block with my transaction is finished.
(In both scenarios I pay enough fee to be in the first block after transaction)
Yes. If there is no comparing, how do the miner validate the transaction? Why do they know that the transaction is legit?
All nodes (and miners are a subset of nodes) validate transactions according to the consensus rules. They check that the transactions that a transaction spends from exists in the blockchain. They also check that the transaction is allowed to spend the outputs that it is spending. Nodes will check that a transaction is not attempting to spend from a transaction which was already spent from before (i.e. a double spend). The blockchain has nothing to do with the validity or legitimacy of transactions (besides that all transactions in the blockchain must be valid). A transactions validity is determined by what outputs a transaction is spending from and whether it is allowed to spend those outputs. And if the blockchain is not for comparing or checking if the transactions are valid, for what is it then there?
The blockchain is for resolving double spends. When there are two or more transactions which spend from the same output, only one of them is allowed in the blockchain. The blockchain is for letting everyone on the network know which of those conflicting transactions is the "real" one. All of the conflicting transactions are valid transactions until one of them confirms. |
|
|
|
|
Post the debug.log file. The apple crash logs are meaningless and useless.
|
|
|
|
Open the terminal and go to the folder where the .deb file is downlaoded. Then run where <filename> is the filename of the Armory .deb file. |
|
|
|
|
Segwit creates a new type of output which moves the signature out of the scriptsig into a new field, the witness. The witness is not included in calculating the transaction id and it is also not counted as part of the 1 MB block size. This effectively reduces the size of a transaction (the part counted for the 1 MB) so that more transactions can be included. With witnesses, a block is now allowed to be 4 MB. Removing the witnesses from the transaction id calculation also makes transactions that spend from segwit outputs non-malleable.
Regarding the block size, technically segwit defines a new limit which supersedes the block size limit, a block weight limit. The block weight is defined as 3 * non-witness data + all data in a block. The maximum block weight is then 4 million weight units (basically bytes).
|
|
|
|
It predicts a few hours until the end of "Building Databases", although I'm not sure what this means... what databases is Armory building? Doesn't it use the same blockchain as in the .bitcoin directory?
Yes it uses the same blockchain, but the blockchain is not the database. The blockchain is just a bunch of data which has to be interpreted. In order to know where blocks and transactions are in the blockchain, Armory and Core must build separate (they can't share databases) databases to keep track of where everything is in the blockchain. |
|
|
|
1. PoW: Every transaction that is encrypted and send to the miners.
No. Nothing in the Bitcoin protocol is encrypted. The miners put all transaction in a block and check by comparing to the blockchain if the transaction is valide.
No, miners do not compare blocks to the blockchain. They build blocks which become part of the blockchain. However the block that they build must be valid blocks (by the consensus rules) and valid blocks must contain valid transactions. Every 10 min (for BTC) a block is made/mined (terms equal?) and added to the blockchain (something like a order book that contains all blocks full of transactions ever made).
So does it take at least 10 min till a transaction is confirmed?
Not necessarily. Do you need for the process of creating the block so much hashpower or for comparing?
There is no comparing. The hashpower is for creating a valid block. The hashpower is only for the Proof of Work, and the PoW must be valid for a block to be valid. 2. How does PoS confirm transactions? Here you just need to stake/hold in a open wallet(terms equal?) coins to confirm a transaction.
But why is someone who stakes more coins is rewarded higher for confirming transactions?
Proof of stake works by deterministically choosing a person to create a block. The people who are staking must essentially lock up their coins in order to have a chance of being chosen to create the next block. With most PoS systems, the staker selection algorithm is weighted by the number of coins a staker has, so those that have more coins are more likely to be chosen to make the next block. |
|
|
|
Thank you I will use this from now on; Can someone please checkout this image and possibly explain to me what is happening? Is it some sort of setting I need to change to be able to see my images on threads? https://i.imgur.com/Qflzkf3.pngNo. Images posted by newbies will be converted to links. When you become a Jr. Member, those will go back to being images. |
|
|
|
I see this being the only 'help' section labeled so I turn to you.
The technical support section is for help with Bitcoin and Bitcoin wallets, not with the forum or any altcoins. For your issue, your thread should be in Meta, which is where I have moved it. Images are not allowed in signatures. |
|
|
|
|
You should let Bitcoin Core sync by itself before starting Armory. That way you will actually know when you are synced as Armory doesn't really show that information.
|
|
|
|
|
Start Armory and Core separately. First start Bitcoin Core. Then start Armory. In Armory, you will have to go to File > Settings and uncheck the box labeled "Let Armory start Bitcoin Core automatically". Then restart Armory.
Can you also post your log files (armorylog.txt and dbLog.txt)?
|
|
|
|
|
Make sure that your user has permissions to read and write data to D:\bitcoin. Ideally you should have the "full control" permission.
|
|
|
|
Actually, before I post entire debug file, I have a couple of questions.
1) Should I post the whole thing? It's very long and covers about a month of transactions. Should I only post the time covering the occurrence of the problem?
Post as much as you can as an error from before could be causing the problem now. 2) I stripped out any reference to my desktop; but, I see IP addresses. Is this something I should also remove? Anything else? I mean, should I post all this in a public forum, or does it not matter?
The debug.log file does not risk your Bitcoin. It may risk some privacy and leak information such as file paths and IP addresses. You can remove those if you want. The whole point of the debug.log file is so that it can be posted publicly for others to analyze and tell you what is wrong. |
|
|
|
|
This thread is being locked. OP has not responded and the thread is becoming a place for spammers now.
|
|
|
|
If you do not remember any of your password, there isn't much that anyone can do to recover your wallet. If you remember some of your password, then you can use a tool like btcrecover to attempt to brute force your password. But for that to have any possibility of success, you need to have some idea what your password is or could be. That requirement goes with every other wallet password recovery tool or service. |
|
|
|
|
Try reindexing.
Also, you are using a development version of Core, and one that has your own modifications, so that may also be the cause of your problems.
|
|
|
|
|
Show Posts
