|
VeritasSapere
|
 |
August 23, 2015, 11:17:27 AM |
|
[...] You need your own full node or you need to trust someone's else full node [...]
Wrong, Electrum and SPV wallets keep their private keys, and they still are reliable as you can tell from the current state of affairs. The only thing needed for controlling your bitcoin is having the private key for them. Full nodes are just for maintaining the network's infrastructure (which is kinda a big deal). However, web wallets that rely on servers to "keep" the private keys are the real cancer here, people need to stop using them asap. You are right - there are clients with which you have your private key, but you still depend (and need to trust) on someone's full node to confirm you have your funds or even worse that the transaction you just received (as a merchant for example) is not a double spend. The fee is not the only expense for sending or receiving Bitcoins - you need to trust someone to confirm it is not a double spend or run your own full node for that. As a merchant will you spend thousands for high speed connection and powerful servers? If you need to use some of the few (centralized) full nodes on the network, what is it different than using Visa, Master Card or Pay Pal? I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all. However I would argue that it would still be more decentralized then being "forced" to use third party payment processors instead of being able to use the main chain directly since that is what would happen if we do not increase the block size and adoption also increased. |
|
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
|
|
|
|
|
|
|
|
KNK
|
|
August 23, 2015, 12:15:28 PM |
|
I agree that block size should increase at some point in time, when the adoption is increased and there is demand for that, but just not yet, not with fixed steps (ignoring the tech limits) and blindly 'just because we should' Bitcoin was designed as self-tuning system in terms of difficulty and that when the reward is reduced the fees would cover the mining expenses, but Satoshi had single software as both wallet and miner, the wallet contained the whole blockchain, so being a full node at the same time. Now we have wallets, pools, miners and full nodes separated - by putting the burden on some of them and providing the fees (that should cover the expenses) to others just forces centralisation - wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all. 8MB blocks 6 times per hour is 1GB+ per day, so 1TB is enough for just a bit less than 3 years ... if doubled after 2 years its just a bit over 2 years and for the next year you need another 1TB and then double triple (to include the old data) that space every two years. Storage space is expensive in a data center and bandwidth is expensive at merchant's location in both cases you also need CPU power to scan that whole data (for confirming a transaction) and to do it fast and for several transactions on each block not just your own - thousands is not that far as a figure.
|
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
|
|
|
|
VeritasSapere
|
|
August 23, 2015, 10:00:54 PM |
|
I agree that block size should increase at some point in time, when the adoption is increased and there is demand for that, but just not yet, not with fixed steps (ignoring the tech limits) and blindly 'just because we should' Bitcoin was designed as self-tuning system in terms of difficulty and that when the reward is reduced the fees would cover the mining expenses, but Satoshi had single software as both wallet and miner, the wallet contained the whole blockchain, so being a full node at the same time. Now we have wallets, pools, miners and full nodes separated - by putting the burden on some of them and providing the fees (that should cover the expenses) to others just forces centralisation - wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later I do not necessary think that it will cost thousands to host a full node, it is not that expensive to hire a server within a data center after all. 8MB blocks 6 times per hour is 1GB+ per day, so 1TB is enough for just a bit less than 3 years ... if doubled after 2 years its just a bit over 2 years and for the next year you need another 1TB and then double triple (to include the old data) that space every two years. Storage space is expensive in a data center and bandwidth is expensive at merchant's location in both cases you also need CPU power to scan that whole data (for confirming a transaction) and to do it fast and for several transactions on each block not just your own - thousands is not that far as a figure. "wallet providers and pools will remain the only full nodes, which gives them the power to force their own rules later" I do not think that the people that benefit from Bitcoin would attempt to undermine it, not because I trust them but because of how peoples incentives are aligned and game theory, that is how Bitcoin mining works after all. "thousands is not that far as a figure." Even if I was running a full node with full twenty megabyte blocks for instance it would still only be in the hundreds not in the thousands per year. https://www.vultr.com/pricing/I am glad that you do think that the block size must be increased, what concerns me is that if we did have a spike in adoption possibly after some global event, then the network would become overloaded. the consequences of this would seriously hamper adoption and public perception. Some of the Core developers like Peter Todd literally do not want the block size increased at all, so that a "fee market" can develop. They think that this would "incentive" third party payment processors which we would then all have to rely on, since transacting on the main chain directly would be to expensive for a normal person and the Bitcoin blockchain will be used primarily as a clearing house for banks, large corporations and payment processors. This is a fundamentally different vision then what Bitcoin was initially intended to be. We should stay true with the original vision of Bitcoin, and if we do really want something different, then it should be implemented as an alt coin and then the market can decide. I do not think that Core will ever increase the block size, that is why if we want bigger blocks we must fork away from the Core development team. That the majority of users would eventually not be able to run full nodes was part of the original design of Bitcoin, quoting Satoshi Nakamoto: "The eventual solution will be to not care how big it gets." "But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore." "The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users." https://bitcointalk.org/index.php?topic=1164464.msg12267335#msg12267335 |
|
|
|
|
|
JorgeStolfi
|
|
August 24, 2015, 01:09:01 AM |
|
Using XT means more than just "I support larger block sizes". It also means you support everything else that comes with XT. Things like: - Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code
That has been talked about, but, AFAIK, it is not in the released BitcoinXT yet. - Tor nodes are deprioritised from connection as an anti-DOS measure
- Permitted Tor exit nodes are, at present, hard coded into the XT client
- Altered methods of tracking potential double spend transactions
People should check what the XT authors say about these. However, there is a fork of XT that has only the block size limit increase patch, not the other controversial ones. (Since these are node/client policy changes, not protocol changes, they will not cause a fork of the chain, not even a soft one.) And anyone could make a clone of BitcoinCore with the increased block size limit. Such a version too would be compatible with the other BitcoinXT options. |
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
|
KNK
|
|
August 24, 2015, 07:15:02 AM |
|
I am glad that you do think that the block size must be increased, what concerns me is that if we did have a spike in adoption possibly after some global event, then the network would become overloaded. the consequences of this would seriously hamper adoption and public perception. Some of the Core developers like Peter Todd literally do not want the block size increased at all, so that a "fee market" can develop. ... at some point in time, when the adoption is increased and there is demand for that, but just not yet The network/protocol should be ready for that and react accordingly, but blindly bumping the size is a bad idea. Please read my proposal at the link provided - it allows for the fee market to develop without much pressure by keeping the blocks almost full. By adding the option for a soft limit from the miners it is even possible to amend it at some degree by mining smaller blocks and shrinking the block size to force more fees, but for that to happen it would require consensus from more than half of the miners, because empty blocks are ignored from the algorithm one can't mine only empty blocks to alter the size (not to mention he will also loose the fees he wants) EDIT: Ooh and Slush provided the best option for each miner to vote - on another port ... let's say we have the default port 'supporting full size', then we have port 3001 'mine 50% full blocks' and few more for every 10% or 15% steps ... then each miner have the choice for the next block size direction, not only the pools |
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
|
|
|
|
Lucko
|
|
August 24, 2015, 11:55:52 AM |
|
Is it just me or did hashrate go up by 8 Ph since XT or QT vote can be made on Slush? It was 14 right? Now it is 22...
EDIT: would be nice to know % of the votes...
|
|
|
|
|
|
pekatete
|
|
August 24, 2015, 11:58:51 AM |
|
Is it just me or did hashrate go up by 8 Ph since XT or QT vote can be made on Slush? It was 14 right? Now it is 22...
EDIT: would be nice to know % of the votes...
Yep ... hash rate just shot up +8PH in the last couple of hours ..... hope that comes hand inglove with improved luck to boot! |
|
|
|
|
Lucko
|
|
August 24, 2015, 12:06:58 PM |
|
Is it just me or did hashrate go up by 8 Ph since XT or QT vote can be made on Slush? It was 14 right? Now it is 22...
EDIT: would be nice to know % of the votes...
Yep ... hash rate just shot up +8PH in the last couple of hours ..... hope that comes hand inglove with improved luck to boot! Well it was 16PH. So +6PH. It was going up from 14PH ever since first XT block was mined... |
|
|
|
|
|
pekatete
|
|
August 24, 2015, 12:17:18 PM |
|
Yep ... hash rate just shot up +8PH in the last couple of hours ..... hope that comes hand inglove with improved luck to boot!
Well it was 16PH. So +6PH. It was going up from 14PH ever since first XT block was mined... Its probably trivial, but it was a tad under 15PH (14.86PH and now 23PH+)   EDIT: Seems to be dropping though ..... |
|
|
|
|
Darthswan
|
|
August 24, 2015, 12:22:11 PM |
|
New miners coming online?
Damn that was a huge jump...
|
|
|
|
|
KNK
|
|
August 24, 2015, 12:24:55 PM |
|
If you look at the 'hash rate per location' graph both US zones have increased, so it is most likely they have switched to the backup pool ... soon they will go back and away
|
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
|
|
|
|
Lucko
|
|
August 24, 2015, 12:37:59 PM |
|
Is there a way to know XT QT based on this graphs? What is cat? mining.bitcoin.cz without location specific setting? Or is this XT  |
|
|
|
|
edonkey
Legendary
 Offline
Activity: 1134
Merit: 1000
|
|
August 25, 2015, 03:31:30 AM |
|
Yep ... hash rate just shot up +8PH in the last couple of hours ..... hope that comes hand inglove with improved luck to boot!
Well it was 16PH. So +6PH. It was going up from 14PH ever since first XT block was mined... Its probably trivial, but it was a tad under 15PH (14.86PH and now 23PH+) EDIT: Seems to be dropping though ..... It's still at almost 24PH at the time of this writing. That's a huge increase from yesterday. This is not trivial. The question is it new hash rate, or just shifted from another pool? |
Was I helpful? BTC: 18wQtEDmhur2xAd3oE8qgrZbpCDeuMsdQW LTC: LbqLtkZ6wTSpwHHuv1tG4J7tHajGdH5QFB DOGE: D9R5ySAP2DARpxuNKd7hN7ANmqFiGwB9G6
|
|
|
|
KNK
|
|
August 25, 2015, 06:56:21 AM |
|
EDIT: would be nice to know % of the votes...
Slush have added that to the 'hash rate per location' graph. Right now it's around 3PH from 24 total |
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
|
|
|
|
|
|
JorgeStolfi
|
|
August 25, 2015, 10:53:24 AM |
|
1000 blocks is almost exactly 7 days. The first block mined just fell out of the window. |
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
|
Lucko
|
|
August 25, 2015, 10:57:59 AM |
|
EDIT: would be nice to know % of the votes...
Slush have added that to the 'hash rate per location' graph. Right now it's around 3PH from 24 total So it is a location cat? I see that has changed... Anyway I think the problem is also that there are no instructions at https://mining.bitcoin.cz/help/#!/get-started/getting_started so I guess some of new hashpower is mining on wrong port... Something showing in a dashboard would help a lot... EDIT: I had 2 of the miners on wrong port and I know about that... I guess this is a bigger issue as I thought... |
|
|
|
|
edonkey
Legendary
Offline
Activity: 1134
Merit: 1000
|
|
August 26, 2015, 02:35:06 AM |
|
Now the pool is 30 Ph/s.
Can't be Bitmain testing S7s because they would point at their own pool.
Maybe it's a whale come to enjoy the 0% fee?
|
Was I helpful? BTC: 18wQtEDmhur2xAd3oE8qgrZbpCDeuMsdQW LTC: LbqLtkZ6wTSpwHHuv1tG4J7tHajGdH5QFB DOGE: D9R5ySAP2DARpxuNKd7hN7ANmqFiGwB9G6
|
|
|
wlefever
Legendary
Offline
Activity: 1131
Merit: 1000
|
|
August 26, 2015, 02:59:04 AM |
|
Now the pool is 30 Ph/s.
Can't be Bitmain testing S7s because they would point at their own pool.
Maybe it's a whale come to enjoy the 0% fee?
If it's a whale coming to enjoy the 0% fee I'm surprised it took them so long, and wonder how fast they will leave once the normal fee returns? Maybe the hashrate will stay in the 25-30 Ph/s range which would work for me! |
|
|
|
|
|
Lucko
|
|
August 26, 2015, 06:34:08 AM |
|
Now the pool is 30 Ph/s.
Can't be Bitmain testing S7s because they would point at their own pool.
Maybe it's a whale come to enjoy the 0% fee?
If it's a whale coming to enjoy the 0% fee I'm surprised it took them so long, and wonder how fast they will leave once the normal fee returns? Maybe the hashrate will stay in the 25-30 Ph/s range which would work for me! My guess it that it is ether block withholding attack since we support BIP101(based only on attacks on my XT node not pool data) or new miners coming to mine BIP101 but lack of instruction on pool site put them at wrong port... It started with first XT block. And I moved my miners because of that. But it could also be some miner in US bought a lot of S6+... |
|
|
|
|
|
Poll
