jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
|
August 22, 2015, 07:44:51 PM |
|
Would you care to elaborate? I think it is an interesting question and do not see this as trolling.
The vote on slush is, and I quote: Right now, every Slush Pool miner can vote for larger blocksize.Wrong. The vote is "do you support XT or Core". Other pools (AntPool, BW Pool, etc) are putting things in their coinbase sig (like "8MB") to show they support larger block sizes (BIP100). They have NOT altered their core clients to XT, which alters the block version number (core is "3", XT is "536870919"). If, come January of 2016, enough blocks are found using XT, a hard fork will occur. 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
- 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
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
pekatete
|
|
August 22, 2015, 07:53:54 PM |
|
Would you care to elaborate? I think it is an interesting question and do not see this as trolling.
The vote on slush is, and I quote: Right now, every Slush Pool miner can vote for larger blocksize.Wrong. The vote is "do you support XT or Core". YOU are wrong as the vote (which I quoted) clearly says otherwise. Other pools do not offer the vote, they just vote using (amongst others) others' hash. That XT offers a larger blocksize (as opposed to core) is sufficient for the vote to be about blocksize, notwithstanding (and irrelevant to the fact) that it'd also result in a hardfork. In any case, there is a vote so may the one who garners the highest blocks (at the core specified time) win. If it is XT, then we get the bigger blocksize that has been voted for.
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
|
August 22, 2015, 08:08:54 PM |
|
I am absolutely not wrong here. XT is the only client that implements BIP101. It changes the block version as I described. Therefore, Slush has XT running on one port, and Core running on the other.
If you use the port that is running XT, you not only vote to support BIP101, but you also vote to support the other things that I listed.
There's a very distinct difference between saying "I want larger block sizes" and "I'm using XT".
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
pekatete
|
|
August 22, 2015, 08:20:59 PM |
|
Those so called distinct differences are what belong to (and should have) another thread. Bottom line is, the vote is for larger blocksizes as I have repeatedly quoted (however much you may scream to the contrary). It is secondary that slush is actually both running XT (which offers larger blocksizes as opposed to core) and core, the important point being there is an option to easily "vote" either way. (I wonder, does the pool you mine at offer even a choice to vote for 100?)
|
|
|
|
VeritasSapere
|
|
August 22, 2015, 09:17:03 PM Last edit: August 22, 2015, 09:46:56 PM by VeritasSapere |
|
I am absolutely not wrong here. XT is the only client that implements BIP101. It changes the block version as I described. Therefore, Slush has XT running on one port, and Core running on the other.
If you use the port that is running XT, you not only vote to support BIP101, but you also vote to support the other things that I listed.
There's a very distinct difference between saying "I want larger block sizes" and "I'm using XT".
Actually there is an alternative version of XT that only changes the block size, or you could even run a patched version of Core that implements BIP101. The block size increase is the only fundamental change to the protocol, the other features within XT are all optional. Therefore if you use the port that is listed it is essentially just a vote to support BIP101 and not the other features that are within XT.
|
|
|
|
chiguireitor
Legendary
Offline
Activity: 872
Merit: 1010
Coins, Games & Miners
|
|
August 22, 2015, 09:58:11 PM |
|
[...] 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.
|
|
|
|
chiguireitor
Legendary
Offline
Activity: 872
Merit: 1010
Coins, Games & Miners
|
|
August 22, 2015, 10:01:04 PM |
|
[...] Actually there is an alternative version of XT that only changes the block size [...]
What version is that? I would really like a Non-XT BIP 101 toting client for my full node, as i'm real busy atm and can't modify my own core for that.
|
|
|
|
|
KNK
|
|
August 23, 2015, 10:30:08 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?
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
VeritasSapere
|
|
August 23, 2015, 10:00:54 PM Last edit: August 28, 2015, 05:07:40 PM by VeritasSapere |
|
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
|
|
|
|
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
|
|
|
|
|