|
Interesting. It doesn't show up in blockchain.info either but I see it in blocktrail. According to blocktrail, its priority is too low for it to be considered high priority and be confirmed.
|
|
|
|
i opened it again, it took a while reindexing but it's working now.
it happened right after an incoming payment, during the update.
What update? am I ok?, should I do something?, is this a bug (should I report it?)
I have the screencap if it is of any use.
thank you!
indkt.
You should be ok. I believe that the issue is caused by a mismatch between the block databases and block index. Reindexing everything should fix the problem. |
|
|
|
|
You can also CoinJoin transactions to anonymize your Bitcoin. It utilizes a function of transactions where there are multiple inputs and multiple outputs. The idea is that if all of the outputs are the same amount, then no one can know who owns what output address. The only problem is getting all of the users to sign them and it can a bit of a hassle. I'm sure if you poke around in the service section you will find people offering to do CoinJoins.
|
|
|
|
|
There is purse.io which you can things from Amazon at a discounted rate, but not anywhere on the net.
|
|
|
|
I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution.
That is a pretty bad assumption. You should assume that miners are in it for the money. Sure there are some miners that mine to help the network, but really, right now the largest miners exist because of the financial incentives. They do everything they can to make the most money, which includes cutting corners. And sometimes cutting corners has big risks and can cause problems for other people. |
|
|
|
|
It is possible, but not recommended. You can use as many machines as you want, but it is possible that your machines will be working on duplicate work, thus reducing your full mining power. It is recommended that you use a new worker for each machine.
|
|
|
|
There are many programs that can brute force things, and when run on a distributed system or a cluster, they can brute force passwords very quickly. Given wordlists of potential password candidates and word mangling rules, it can be relatively easy to brute force a password. I have actually known about wallet recovery services, and you don't need to send them the full wallet, just parts of it which can be dumped using pywallet. They require the part regarding the password and 1 or 2 addresses from the wallet that can be empty. This safeguards your coins if they should try to steal them. The info about this is here: http://www.walletrecoveryservices.com/information.html |
|
|
|
|
A watch only wallet does not contain any private keys. It only has the addresses there so you can monitor those addresses and create transactions, but cannot sign and broadcast said transactions. To get the private keys, you must find the wallet where those addresses came from.
|
|
|
|
Is it conceivable to add a service network which announces "block XYZ was invalid"?
A service that miners could subscribe to; or organize themselves, even on one of their machines only?
...
Could that approach reduce the harm that SPV miners are causing?
Well such as service shouldn't have to exist. SPV Miners should be validating blocks that they receive while they are mining. Let us hope they do. A "should" is a "could" plus some ethics. *lol* The "... validating blocks that they receive while they are ..." is exactly what I was suggesting, indeed. F2Pool apparently had stopped simultaneous validation after they lost an orphan race, but since the fork they have reimplemented the validation. That means that during the fork, they did not validate the incoming blocks at all. The issue with these validations is what happens if they mined the block before they finish validating the previous?
I see a question mark there. What were the blocktimes between those 6 invalid blocks? And the last of those 6 blocks, how many seconds after the 1st invalid block was that? I don't know the blocktimes. However, since F2Pool wasn't validating, those times don't matter. I guess we can assume that AntPool wasn't validating either or they had seen that F2Pool's chain was the longest, assumed it was the right one, and saw that F2Pool was creating valid v3 blocks. The problem with simultaneous validation and a service alerting miners of invalid blocks is that there is nothing forcing miners to use the service or validate. The only way that they are forced to do any of these is if there are financial incentives. |
|
|
|
|
Either someone likes to help the miners, or they are making transactions incorrectly.
|
|
|
|
3) Checked address and txid https://www.blocktrail.com/tBTC/address/2MvDgSTXGEbi9nm4UhP1B6Wvi7LMJ9MAdmu/transactions
30a9e645c8e6c4bedfa10cfb23d6d6448557796181082218504ad252b595bacd If you look up this transaction in the blockexplorer, you will see that there are 2 outputs from this transaction. The first one is to mwNenFE8gFfjz2p2osbsYXAcPt6gnGGKSk and the second to 2MvDgSTXGEbi9nm4UhP1B6Wvi7LMJ9MAdmu. The second one is to your address. These outputs go in an array, with the first having an index of 0, second has an index of 1, and so on. Now lets look at your raw transactions. 4) Created rawTX createrawtransaction '''
[
{
"txid": "'30a9e645c8e6c4bedfa10cfb23d6d6448557796181082218504ad252b595bacd'",
"vout": '0'
}
]
''' '''
{
"motbFuaf7Q7xWqBbo7zFu83sdNBspvYkFY": 1.9999
}'''
0100000001cdba95b552d24a50182208816179578544d6d623fb0ca1dfbec4e6c845e6a9300000000000ffffffff01f09aeb0b000000001976a9145bd898bbe4a000cda4418c1fd28178ec99cd653e88ac00000000 In your vins, you specify the txid and the index of the output you wish to spend. In this case, the index of the output is 1, not 0 because the output is the second in the array. Therefore, instead of you should have Your error is coming from not having the private key to spend the first output. |
|
|
|
Is it conceivable to add a service network which announces "block XYZ was invalid"?
A service that miners could subscribe to;
or organize themselves, even on one of their machines only?
Could make sense if those instances are rare.
Then SPV miners start hashing with what they assume (but not check) is a valid block,
and when a few seconds later an "invalid block" alert is broadcast, they simply restart.
Possible? Wrong approach? Then sorry - I do not understand enough of this yet.
But the other thing ... miners deliberately mining empty blocks, that sounds ruthless, no?
No answer. So I am probably wrong? What I was thinking is: This "two-phases SPV / full" mining could give them their headstart for the first seconds phase after they receive a block on top of which they want to build. Then in "phase 2": If this questionable block is really valid, they just continue. If invalid, they immediately drop it, and restart. Could that approach reduce the harm that SPV miners are causing? Well such as service shouldn't have to exist. SPV Miners should be validating blocks that they receive while they are mining. The issue with these validations is what happens if they mined the block before they finish validating the previous? |
|
|
|
In understand that clients don't need to update if a soft fork only makes the rules for blocks more restrictive. However, if it makes the rules for transactions more restrictive too, then the clients must update anyway, otherwise their transactions will be rejected (except by nodes and miners who are still running the old version, which may cause those transactions to be confirmed and then unconfirmed). isn't that so? Isn't that the case of BIP66?
This was considered by the developers when they wrote the BIP. Essentially, these transactions have been around since version 0.8.0 and this soft-fork simply makes said transactions a protocol rule. From the BIP itself: Compatibility
The requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0, and very few transactions violating it are being added to the chain as of January 2015. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability (see BIP 62). |
|
|
|
So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come.  At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now. Can anyone explain why a miner wouldn't simply verify the last block in parallel with their mining computations? Let their ASICS hash while another machine double checks the last block. What's wrong with that? This is what I'm wondering too. The client probably isn't optimised for mining, but surely with custom software it would be possible to save state when a block is received from a peer, then immediately begin work on the new block. At the same time, verify the block that has just been received; if it turns out to be invalid, restore state and continue work on the "old" block. This way you still get the speed advantage, but with the added safety of consistency checks. It appears that F2Pool did, but had it disabled when the fork happened due to a bug from losing an orphan race a few months ago. It seems that they implemented a fix for that bug, but the code is not refined yet. Source: First, we are not a pure SPV mining operation. We only do that within seconds after a new block is found on the network. We did have a safe guard in the beginning which falls back to the verified block template if after one or two minutes the local bitcoind still not able to catch up with the udp notification. But the safe guard was disabled due to bug when we lost an orphan race a few months ago. We have already implemented a quick fix. It should be ok now. And we will further refine the code in the next few days.
|
|
|
|
|
The hex part that you bolded is actually the asm encoded in hex. OP_DUP is 0x76, OP_HASH160 is 0xa9, OP_EQUALVERIFY is 0x88 and OP_CHECKSIG is 0xac. Immediately following OP_HASH160 is the hex of the RIPEMD-160 hash of the SHA-256 hash of the public key. Therefore, the actual public key part is 2e2a8d353ea825de6bc2b081324f412764e53e57 found immediately after a9 and immediately before 88. You perform the base58 encoding on this hash.
|
|
|
|
did anyone LOSE BITCOINS as a result of this issue ?? That's what really matters ..
I don't think so besides BTCNuggets, F2Pool, and Antpool for 6 block rewards and wasted time and effort. There were no transactions in the fork except for the first invalid block from BTCNuggets which I believe got confirmed in the correct chain. |
|
|
|
Thanks for the replies, @knightdk. You write: The devs deserve a fat slice of the blame for not programming a reasonable delay (say, 2 weeks) between the "95% majority" event and the activation of the BIP66 rule. That delay would have given a chance for the remaining v2 miners and nodes, as well as more v2 clients, to upgrade to v3. (Using blockchain voting to trigger protocol changes also seems a terrible idea, but that is another discussion.)
I don't think that a delay would have made a difference. BIP66 has been public for months, and so has the clients supporting it. Really the only way I think that the remaining miners would switch is after they realize that their v2 blocks are no longer being accepted because who likes change? I doubt that 1% of the bitcoiners out there know what a BIP is. I doubt that 0.1% of the bitcoiners out there knew that a soft fork due to BIP66 was due to happen this year. A 2-week delay would have allowed the devs to send an alert to all nodes and miners still runing v2 to upgrade immediately or risk being cut off from the network and having their feet eaten by the boogeyman while they sleep. A 2-week delay would also allow any v3 nodes that were turned off to catch up with the blockchain, and determine whether BIP66 was already in force of not. Well forcing everyone to upgrade defeats the purpose of a soft-fork. The idea behind a soft-fork is that the new rules are still valid under the old rules. This makes soft-forks much easier to carry out and they are backwards compatible. What you are suggesting would be to make every soft-fork a hard-fork, which requires that everyone must upgrade otherwise they will be left off of the network. This is much more difficulty to carry out and I think such hard-forks have and will have the delay, alerts sent out, and monitoring of the situation before and after the fork. Also, I would assume that all of the developers of Bitcoin stuff would be on the Bitcoin Development Mailing List (pretty big assumption). This mailing list discusses all of these changes when they come out and anyone following it would know that the BIP66 soft-fork was coming soon. The core devs or F2Pool's own devs may also deserve another fat slice of the blame, for the v3 software allowing v3 miners and nodes to receive blocks from v2-running miners and nodes after BIP66 was activated.
Can't really stop the reception of blocks, but F2Pool's own devs do deserve a lot of the blame for having SPV Mining that did not validate the blocks at all. After BIP66 became active, any v3-running miner, node, or client should have ignored (or have disconnected from) any nodes that it knew were still running version v2. As I said above, this makes it a hard-fork, which is much more dangerous than a soft-fork and much more difficult to do. Also, disconnecting and alienating all nodes running v2 would disconnect more than 1/6 of the network. According to getaddr.bitnodes.io, it appears that more than 1000 nodes out of 6000-ish nodes are running old software, be it Core 0.9.5 or earlier or other old software. This would lose a significant portion of the network, and probably break Bitcoin's credibility. More generally, the core devs approach to protocol changes seems to be like that of an airline that lets a plane take off with a know engine malfunction, and tries to fix it during flight -- because it does not want to alarm or inconvenience the passengers, or get bad exposure in the news...
Maybe... They want to avoid hard-forks because those can more negatively affect Bitcoin than soft-forks do. In situations where a soft-fork is not required, then a soft-fork will be done. And, AFAIK, "SPV mining" is only the most likely theory, not confirmed or proved yet.
I believe that it has been both confirmed and proved by F2Pool and AntPool. |
|
|
|
I am still trying to understand what actually happened.
What I have read is that BTCNuggets, a miner that was still running v2 software, mined a block B'(N) that was valid by v2 criteria but invalid by v3 criteria. Somehow F2Pool, a miner that was running v3 software, received the header of this block and successfully mined a block B'(N+1) that was valid under v3 rules (empty, in fact) except for having an invalid parent. As luck would have it, they also mined another (empty) block B'(N+2) with B'(N+1) as parent. Then AntPool, who was running v3 software too, mined B'(N+3) on top of B'(N+2). And so on; this was the 'bad' branch.
Meanwhile, other miners running v3 software either did not see block B'(N), or saw it and detected that it was not v3-valid; so they ignored it and eventually mined a block B''(N) that was v3-valid. Several v3 miners solved additional v3-valid blocks B''(N+1), B''(N+2), etc. on top B''(N). This was the 'good' branch.
For a while, the bad branch was ahead of the good one, in terms of total work. Fortunately the devs and other bitcoin hackers were watching the blockchain to monitor the onset of BIP66, spotted the problem immediately, alerted F2Pool and AntPool that they were mining a v3-invalid chain, and sent out an alert recommending a 30-confirmation (5 hour) wait for important transactions.
Is this a correct summary of the events?
Pretty much. Some of the many questions that remain:
* How many blocks were actually mined on the bad branch (starting form B'(N)) before it was abandoned?
6 or 7 * Were F2Pool, AntPool, and the other pools that mined on the bad chain running modified versions of the v3 core? If so, what were the modifications?
I believe that they were using custom software for SPV Mining. SPV Mining means that the miner does not validate the block before beginning to mine on it. Thus, when F2Pool and AntPool received the v2 block, they did not verify the block but simply assumed that it was valid. * Did F2Pool realize that the BIP66 rules had already started to apply when they received B'(N) from BTCNuggets? (Say, perhaps it had counted only 949 v3 blocks, or had its counter reset recently, etc.)
Yes, However, as I said above, they were SPV Mining so they did not validate the block which was in fact invalid by the new rules. * How did F2Pool get the header of the invalid block B'(N): directly from BTCNuggets, from a v2-running relay node, or from a v3-running relay node?
Probably from a node that still considered v2 valid such as Core 0.9.3 or lower. * In the standard version of the v3 core software, do miners get the whole parent node and verify its validity?
Yes * Could there be an off-by-one bug in the v3 core software, that would have resulted in F2Pool verifying B'(N) with pre-BIP66 rules instead of BIP66 rules? (Note that a v3-valid node *can* have a v3-invalid parent, if the parent was mined before BIP66 went into effect.)
* If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v2-running miner or node: why was it still accepting transactions, blocks, and block headers from v2-running players, without checking whether such data was v3-valid?
SPV Mining * If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v3-running node: which node was that, and why did it forward the v3-invalid node B'(N) to F2Pool?
It most likely did not come from a v3 node. * If a miner receives a block B(M), how many blocks B(M), B(M-1), B(M-2) etc. should it validate on its own before daring to mine B(M+1) on top of it?
I think it is B(M-6) because that is what the hard fork detection in Bitcoin Core looks for (I think, could be wrong) * Suppose that a miner receives block B(M) and starts validating it, while in parallel mining a new block B(M+1) on top of it; and happens to solve B(M+1) before the validation of B(M) is complete. Should it broadcast B(M+1), or wait until the verification of B(M) is complete?
Ideally they should wait for the verification of B(M), but, we all know that miners are greedy little bastards, and they will most likely not wait for the verification to complete because it could mean the difference between having their block win or having it lose. The devs deserve a fat slice of the blame for not programming a reasonable delay (say, 2 weeks) between the "95% majority" event and the activation of the BIP66 rule. That delay would have given a chance for the remaining v2 miners and nodes, as well as more v2 clients, to upgrade to v3. (Using blockchain voting to trigger protocol changes also seems a terrible idea, but that is another discussion.)
I don't think that a delay would have made a difference. BIP66 has been public for months, and so has the clients supporting it. Really the only way I think that the remaining miners would switch is after they realize that their v2 blocks are no longer being accepted because who likes change? The core devs or F2Pool's own devs may also deserve another fat slice of the blame, for the v3 software allowing v3 miners and nodes to receive blocks from v2-running miners and nodes after BIP66 was activated.
Can't really stop the reception of blocks, but F2Pool's own devs do deserve a lot of the blame for having SPV Mining that did not validate the blocks at all. |
|
|
|
I went to the link for their store, and it is selling all their miners for really cheap. Seems super scammy. Another thing I noticed, Raspberry Pi B+ normally sold for $25 is being sold for $39! What a great deal  |
|
|
|
This is completely right, the whole point of mining is verifying transactions, that it was possible for even some of the miners to circumvent that requirement and then reap the rewards is a tremendous fail of the bitcoin software and as such it's developers.
It is not the Bitcoin Core devs' faults, rather it is the developer who wrote the pool's own software. It is the pool and their developer's faults and their fail because they were selfish and did not write their code to validate the blocks before mining on it began. This is made possible due to the open source nature of Bitcoin. The pool developers are free to write whatever software they want and as long as it conforms to the Bitcoin protocol. |
|
|
|
|
Show Posts
