Bitcoin Forum
December 15, 2024, 07:19:08 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 [1055] 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 ... 1154 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4382727 times)
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1024


Mine at Jonny's Pool


View Profile WWW
August 22, 2015, 07:44:51 PM
 #21081

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
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile WWW
August 22, 2015, 07:53:54 PM
 #21082

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 Offline

Activity: 1344
Merit: 1024


Mine at Jonny's Pool


View Profile WWW
August 22, 2015, 08:08:54 PM
 #21083

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
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile WWW
August 22, 2015, 08:20:59 PM
 #21084

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
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
August 22, 2015, 09:17:03 PM
Last edit: August 22, 2015, 09:46:56 PM by VeritasSapere
 #21085

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 Offline

Activity: 872
Merit: 1010


Coins, Games & Miners


View Profile WWW
August 22, 2015, 09:58:11 PM
 #21086

[...] 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 Offline

Activity: 872
Merit: 1010


Coins, Games & Miners


View Profile WWW
August 22, 2015, 10:01:04 PM
 #21087

[...] 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.

VeritasSapere
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
August 22, 2015, 11:07:19 PM
 #21088

[...] 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.
Here you go:
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/

KNK
Hero Member
*****
Offline Offline

Activity: 692
Merit: 502


View Profile
August 23, 2015, 10:30:08 AM
 #21089

[...] 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?

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
VeritasSapere
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
August 23, 2015, 11:17:27 AM
 #21090

[...] 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
Hero Member
*****
Offline Offline

Activity: 692
Merit: 502


View Profile
August 23, 2015, 12:15:28 PM
 #21091

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.

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
VeritasSapere
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
August 23, 2015, 10:00:54 PM
Last edit: August 28, 2015, 05:07:40 PM by VeritasSapere
 #21092

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1003



View Profile
August 24, 2015, 01:09:01 AM
 #21093

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.

Quote
  • 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
Hero Member
*****
Offline Offline

Activity: 692
Merit: 502


View Profile
August 24, 2015, 07:15:02 AM
 #21094

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

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
August 24, 2015, 11:55:52 AM
 #21095

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
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile WWW
August 24, 2015, 11:58:51 AM
 #21096

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
August 24, 2015, 12:06:58 PM
 #21097

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
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile WWW
August 24, 2015, 12:17:18 PM
 #21098

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
Hero Member
*****
Offline Offline

Activity: 818
Merit: 508



View Profile
August 24, 2015, 12:22:11 PM
 #21099

New miners coming online?

Damn that was a huge jump...

            ▄▄████▄▄
        ▄▄██████████████▄▄
      ███████████████████████▄▄
      ▀▀█████████████████████████
██▄▄       ▀▀█████████████████████
██████▄▄        ▀█████████████████
███████████▄▄       ▀▀████████████
███████████████▄▄        ▀████████
████████████████████▄▄       ▀▀███
 ▀▀██████████████████████▄▄
     ▀▀██████████████████████▄▄
▄▄        ▀██████████████████████▄
████▄▄        ▀▀██████████████████
█████████▄▄        ▀▀█████████████
█████████████▄▄        ▀▀█████████
██████████████████▄▄        ▀▀████
▀██████████████████████▄▄
  ▀▀████████████████████████
      ▀▀█████████████████▀▀
           ▀▀███████▀▀



.SEMUX
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
  Semux uses .100% original codebase.
  Superfast with .30 seconds instant finality.
  Tested .5000 tx per block. on open network
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
KNK
Hero Member
*****
Offline Offline

Activity: 692
Merit: 502


View Profile
August 24, 2015, 12:24:55 PM
 #21100

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

Mega Crypto Polis - www.MegaCryptoPolis.com
BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
Pages: « 1 ... 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 [1055] 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 ... 1154 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!