|
With increase in block size, it will become more difficult to run a full node. However, SPV nodes may still contribute by validating some, but not all blocks.
Based on my estimation with not-so-random sampling of blocks, I assume:
3 inputs per transaction on average
550 bytes per transaction on average
Also, 1kB = 1000 bytes, 1MB = 1000kB.
With 8MB block, that would be 14545 tx / block. To locate a tx with 14545 tx / block that would require 14 levels of Merkle hash, i.e. 14*256/8 = 448 bytes / input
So an SPV proof for each input would take 550 + 448 = 998 bytes. Lets round it to 1kB.
With 14545 tx / block, that means 43636 inputs / block. Therefore, for a partial validating node to validate a 8MB block (assuming inputs are valid), it has to download 8MB + 43.636MB = 51.636MB of data.
We currently have around 5900 full nodes. Since partial validating nodes does not need to store the block data permanently, we may have at least 10,000 partial validating nodes in the future. With each node validating only 1 block per day, each of the 144 blocks in a day will be independently validated by 69 nodes.
--------------------------------------
To further extend the idea, partial validating nodes may sign the validated blocks. With some kind of web-of-trust system people may validate the blockchain collaboratively
--------------------------------------
Even mobile devices may become partial validating nodes when they are connected to AC power and WIFI. It may take a few days for them to validate a single block but it still contributes to the network security as (hopefully) there will be many mobile devices with SPV wallets.
--------------------------------------
What happens if an invalid tx is found? A fraud warning system is tricky because that could become a DoS vector. We may require fraud warning to be signed by bitcoin address with a certain amount of deposit. This would be a different topic.
|
|
|
|
The proof of publication blocks would only need to be held for a short time, so they could have a higher size limit. This would allow miners to include more transactions than are necessary into the block and repeats would be automatically discarded as part of generating the bitcoin block.
What happens if there are too many valid txs and are unable to fit in a bitcoin block? |
|
|
|
If there's really such a case as 1 transaction per person per ten minutes in 20 years,
8GB is about 1.5 tx per person per day, assuming 250bytes/tx and 7 billion people |
|
|
|
5 largest mining pools in China, including 2 of the busiest exchanges in the world, release a joint declaration to support raising the MAX_BLOCK_SIZE to 8MB. They currently control 60% of the network hashrate. https://imgur.com/a/LlDRrChinese companies are operating under a very oppressive environment. All internet activities are strictly censored and outbound bandwidth is limited. They still agree to increase the block size. Although one may argue that on this issue merchants' view is more important than miners, the hardfork won't be successful without miners' support. And don't forget, this statement includes 2 major exchanges, BTCChina and Huobi. I hope this would conclude the debate around "raise block size or not" and "how much to raise". I hope we could focus on the pathway leading to 8MB. Should that be a simple raise or a step function? If a step function, how? Should we limit other parameters, e.g. sigop count and UTXO growth? The hard fork should also consider the pathway beyond 8MB if we don't want to repeat the debate (too early). |
|
|
|
  -1.95 is a 2-month high. It was the support in Feb and Mar. Now it seems become a resistance? |
|
|
|
one more thing - doesn't this 1443 byte stack element violate the MAX_SCRIPT_ELEMENT_SIZE criteria? shouldn't this mean that the script would fail and so should not be included in the blockchain?
validity of scriptPubKey is not verified until someone tries to spent it |
|
|
|
If you have a device with a radio, a gyroscope, a wifi-antenna, a java-random-number generator (that was recently hardened for use with crypto) and then you decide to make a call to a website to get a random number, that seems nuts.
I have always used a blockchain.info wallet and was quite satisfied with it. Their sloppy coding is not giving me confidence to use them anymore. It's money at stake here and some users, quite unwisely, have their life savings in bitcoin stored on their wallets. I have been postponing my purchase of a hardware wallet long enough. It is time to give it more thought. HW wallets are not mature and may not be as secure as you think: https://bitcointalk.org/index.php?topic=1022815.0;topicseen |
|
|
|
This would explain all of those threads about the 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F address which people were claiming that their bitcoins were stolen.
Not just could, it does explain those threads. @Cryddit, you're right, it's quite mind-boggling that a site as reputable as blockchain.info screwed this up so completely. Reputable? In terms of their track record of fucking up? |
|
|
|
Hello all, So for a while I had been away and came back to find a wallet emptied. You can see how quickly it happened here: http://106.187.103.143/address/1LNFx7QQkpmam9jLjpyd52QqiVfahix9gQI move some Bitcoin in. 20 minutes later is off to Germany (I assume a VPN, etc.). I see it then splits off to a bunch of wallets. I then see it goes on a bit of a journey of fragmentation. OK, I am no fool. It is lost. However, is there any way for me to at least understand the nature of such an attack. To your eyes is this some lone wolf or something more sophisticated. Frankly I think this means I am done with Bitcoin. I've been super safe for years, but then in 20 minutes someone manages to relieve me of roughly 500e in Bitcoin. I use electrum. The computer with your private key is compromised. Period. If you are not using offline wallet function of Electrum, you are not super safe. Cheers, I expected as much. Ugh. But yes, it is the only way they could do it right? They would not even have needed the private key, but simple a RAT to execute the transaction. Lesson learned. So you paid 500e to learn that your machine is compromised. Not a bad deal if you could afford it. |
|
|
|
Hello all, So for a while I had been away and came back to find a wallet emptied. You can see how quickly it happened here: http://106.187.103.143/address/1LNFx7QQkpmam9jLjpyd52QqiVfahix9gQI move some Bitcoin in. 20 minutes later is off to Germany (I assume a VPN, etc.). I see it then splits off to a bunch of wallets. I then see it goes on a bit of a journey of fragmentation. OK, I am no fool. It is lost. However, is there any way for me to at least understand the nature of such an attack. To your eyes is this some lone wolf or something more sophisticated. Frankly I think this means I am done with Bitcoin. I've been super safe for years, but then in 20 minutes someone manages to relieve me of roughly 500e in Bitcoin. I use electrum. The computer with your private key is compromised. Period. If you are not using offline wallet function of Electrum, you are not super safe. |
|
|
|
New version out in ffreeze, please test away. There's a wealth of robustness changes and it should also be a bit faster. However no one at Armory has experienced the issues Carlton Banks and btcchris ran into, so most of these changes were speculative. It's possible these bugs will still be there partially or in full.
As usual, looking forward to your bug reports and logs, and again thank you for the time and effort you put in helping us to test things out =)
Have you made any big change re supernode? In the previous ffreeze it did not complete even with a week. In this version it took only a few hours to complete. I made changes to some stuff that makes supernode faster (some weird opts I should have rolled but figured it could wait for fear it would be unstable). The other issue, with pulling block data and the object lifespan remains. It's a rare occurrence but common enough to trip certain setup quite often (2 out of my 3 testers T_T). I ended rolled the optimization with the stability changes (it didn't cost that much more to add the opts at that stage) Now I'm also convinced that the code speeding up supernode is not responsible for the instability. That gives me room to add some more optimizations (again supernode only) without fear of making bugs more convoluted (and thus harder to isolated). Not having a clue what the issue was, I ended up fixing what you were suffering from (which was a lot more obvious than the remaining issue) in an attempt to fix the bug they are experiencing. In grand scheme of things it doesn't matter what order I fix these, since I have to go after both anyways. In the current scope, it doesn't speak so good of me since I thought I was fixing one thing and got the other instead =P I can now get the details of a random tx with "armoryd.py gettransaction txid". I guess this means the supernode in running properly?
Not really, that just means you are using supernode indeed (which is the only the DB format now that support random txhash resolution), but that doesn't mean supernode is working per se. What you need to do to test it is to add a random bitcoin address to a wallet and getledger on the wallet, which will display that random address history along with the rest. You can also verify this in the UI by importing some publicly known private keys to a wallet (kind of an oxymoron I know) and verify they get imported quasi instantly and that their history shows up in the main ledger. It fails again. This is what I did and saw: 1. I compiled the latest ffreeze. Removed previous databases folder. 2. I started armoryd in supernode mode. It finished "Reading raw blocks finished at file xxx offset xxxxx" in a few hours 3. At this time, I can get the details of a random tx with "armoryd.py gettransaction txid". However, I didn't tested by importing private key. 4. At block 360206, and armoryd says "BDM thread failed: The scanning process interrupted unexpectedly" and asks me to rebuild and rescan. I killed armoryd by Control-C. 5. I started armory-qt. I didn't request a rescan but it seems doing that automatically. 6. The console started to show "Finished applying blocks up to xxxxxx". This message did not show up before the crash. The progress became slower and slower. I knew it will never complete and closed armory-qt. 7. I restored the previous databased folder by last ffreeze. It was incomplete and I stopped it at about block 300,000 after more than a week of scanning 8. I started armory-qt. No re-scan. 9. I imported this private key: 5JdeC9P7Pbd1uGdFVEsJ41EkEnADbbHGq6p1BwFxm6txNBsQnsw (SHA256 of "1") for the address 12AKRNHpFhDSBDD9rSn74VAzZSL3774PxQ. It only shows the 2 txs in 2014 but not the latest ones of 2015. So I guess both databases are somehow corrupted? |
|
|
|
|
OP updated. 757 XBT bought in May 2015
|
|
|
|
|
Although in the readme says it's not, I can't see why this is not an altcoin --- a pre-mined altcoin (indirectly) controlled by a group of functionaries, who guarantee to exchange the altcoin with real bitcoin in an exchange rate of 1:1. So it's a bitcoin bank like Coinbase, with much more functions and much better transparency, while still nothing could stop the functionaries to run with the real bitcoin.
There is a big difference between being a Bitcoin miner and an Elements functionary. In the latter case, you actively safekeep and distribute clients' money, just like a real bank. Functionaries, unless completely anonymous, may be accused of assisting money laundering. Who would like to be the next DPR or Charlie?
I think the project is really interesting but I can't see how it could work in mainnet due to the aforementioned reasons.
|
|
|
|
New version out in ffreeze, please test away. There's a wealth of robustness changes and it should also be a bit faster. However no one at Armory has experienced the issues Carlton Banks and btcchris ran into, so most of these changes were speculative. It's possible these bugs will still be there partially or in full.
As usual, looking forward to your bug reports and logs, and again thank you for the time and effort you put in helping us to test things out =)
Have you made any big change re supernode? In the previous ffreeze it did not complete even with a week. In this version it took only a few hours to complete. I can now get the details of a random tx with "armoryd.py gettransaction txid". I guess this means the supernode in running properly? |
|
|
|
2. Some wallets, e.g. Electrum, do not consider an address as "used" until it is associated with a transaction with a certain number of confirmations. If a wallet user asks for a new receive address, they will be presented with the same address as previously displayed until it is considered "used" by the above criterion. (In the Electrum case, they can manually choose an address which they believe has not yet been given out, but they must keep track of this themselves.)
Isn't this the case with every Bitcoin wallet out there? I mean, which wallet keeps track of the already generated addresses? If they could, how will the concept of a completely secure cold storage work? Every time you request a new address from Aromry, it gives you a new one. |
|
|
|
If fork like this happens again in the future, care should be taken to ensure all legitimate transactions in the buggy chain are moved to the repaired chain.
Would this be possible, without the consent of people who had sent money in the buggy chain? They would of course have a financial incentive to NOT have the transactions moved. You only need miners' consent |
|
|
|
|
It is not difficult to see that -1.75 is a major resistant (now $304). If we would follow the 2011-12 pattern, breaking -1.75 would lead us to the next resistant level of -1.5 to -1.25 (now $390-$500)
|
|
|
|
If smething big happens that could "break" Bitcoin, transfer to Litecoin, the safe haven coin.
If something big happens and breaks Bitcoin, then Litecoin will follow. Besides, how do you transfer broken Bitcoins to Litecoins? the only way is by dumping them before the bug occur, or if you can catch the news about it, you just dump your stash, but if then bitcoin recover you might lose more in the end... better to dump for fiat in that case, or a better coin than litecoin.... Bitcoin has never been hacked.
That's not the point. The 90 billion coins was not a hack, but an exploit of a bug. Although unlikely, we can't rule out another bug like that from happening again. It's a bug of MtGox, not a bug of Bitcoin. are you sure, we are talking about this https://en.bitcoin.it/wiki/Value_overflow_incidentThanks, no one explicitly mentioned this in this thread. A similar incident happened in 2013 but Bitcoin has survived: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawikiIf fork like this happens again in the future, care should be taken to ensure all legitimate transactions in the buggy chain are moved to the repaired chain. |
|
|
|
Bitcoin has never been hacked.
That's not the point. The 90 billion coins was not a hack, but an exploit of a bug. Although unlikely, we can't rule out another bug like that from happening again. It's a bug of MtGox, not a bug of Bitcoin. |
|
|
|
|
Show Posts
