Bitcoin Forum
October 22, 2017, 03:15:58 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 »
  Print  
Author Topic: ...  (Read 59331 times)
Nybbas01
Newbie
*
Offline Offline

Activity: 9


View Profile
August 25, 2015, 12:27:37 AM
 #441

Hey, if it confuses people, it'll work.
1508642158
Hero Member
*
Offline Offline

Posts: 1508642158

View Profile Personal Message (Offline)

Ignore
1508642158
Reply with quote  #2

1508642158
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508642158
Hero Member
*
Offline Offline

Posts: 1508642158

View Profile Personal Message (Offline)

Ignore
1508642158
Reply with quote  #2

1508642158
Report to moderator
bitboy11
Hero Member
*****
Offline Offline

Activity: 533



View Profile
August 25, 2015, 03:28:32 AM
 #442

It has become quite obvious to me that Bitcoin Core developers have an agenda to keep the block size small and support Blockstream. The bitcoin core members who support this likely have a lot of BTC and can afford to pay an exorbitant miner's fee to have their transactions acknowledged on the ledger while "bit-peasants" will be forced to do their transactions off-chain with the help of a Bitcoin Bank a.k.a. Blockstream which includes their KYC bullshit!

These "banks" will then start controlling the Bitcoin network and then, at their discretion, will begin to blacklist "undesirable" people from using the network. What happens when these "banks" start requesting that you file your bitcoin tax form? Or that non-US users are being limited or are not being accepted at this time? LOL...just check PayPal or Coinbase to get an idea.

In my opinion, Bitcoin XT is the future of Bitcoin!




kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 25, 2015, 04:24:21 AM
 #443

Meanwhile Cheesy

https://bitcointalk.org/index.php?topic=1156489.msg12216919#msg12216919

A few have discussed flagging blocks with /BIP100/ in the last day or so
(yep my pool got one in the last day and flagged it also)

Results:

/BIP100/ already 10%

BIP101 ... about 1% after all this time

damn shame Cheesy

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2604


I support freedom of choice


View Profile WWW
August 25, 2015, 04:38:38 AM
 #444

@kano
You should pay someone to write the code of the BIP100, because now there isn't.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 25, 2015, 06:20:22 AM
 #445

@kano
You should pay someone to write the code of the BIP100, because now there isn't.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010621.html

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
sgbett
Legendary
*
Offline Offline

Activity: 1484



View Profile
August 25, 2015, 02:16:55 PM
 #446


Cartoons and graphics sometimes say more than thousand words.
Today I found the truth table in the cyberspace. Wink



paging icebreaker for immediate application of the MP-RDF. These truths cannot be left unFUDed in public!
That yes/no image is incorrect.
If core is the longest chain and someone is stupid enough to mine an XT block that core doesn't allow, then all XT nodes will follow the XT block fork.
Thus if core continues to be the longest chain (which it will) then XT clients will not follow the longest chain possibly until later.

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume the latter.

BIP101 activates *only* if XT has >75% of hashing power. So once a big block is mined then it doesn't matter if core ignores it, because core doesn't have the hash power to be able to orphan XT blocks by producing a longer chain.

At the point a big block is mined the probability of core being able to produce a longer chain quickly falls to zero. In the first 10 minutes there is a 25% chance, in 20 minutes 6% chance and so on... 1.5%, 0.4%,0.1%. After on hour of XT mining with 75% hashpower there is a 0.02% chance that core has a longer chain. Core is dead in an hour. Thats the real socio-economic incentive, regardless of how many anti-XTers try and claim there isn't one.

If XT doesn't have 75% of hashing power then BIP101 doesn't activate. So both XT and core both continue to mine small blocks and nothing changes.

The chart is quite correct.

Full Node: http://46.51.193.129 (BU) || http://haschinabannedbitcoin.com
"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution" - Satoshi Nakamoto
kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 25, 2015, 02:31:52 PM
 #447

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things:
1) blocks can be anywhere from a second to well over an hour, so no, your stats are only theoretical expectations.
2) XT being 75% doesn't mean it can't lose - there's a reason why core uses higher than 75% ...
3) 'XT' have stated they will use block markers to force people to stay on XT and not switch to Core, if however, Core is above 50% and gets ahead of XT, everyone on XT will be royally screwed Smiley
4) It only takes one 'XT only' block to be mined to keep everyone using XT off Core

but more importantly, XT wont happen.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 25, 2015, 06:15:20 PM
 #448

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things: [ ... ] but more importantly, XT wont happen.

It is irrelevant which version of the software is being used (Core, XT, or other).  What happens after the first big block is mined depends only on how many miners accept big blocks.  ("Small block" = at most 1 MB; "big block" = more than 1 MB but not more than 8 MB.  See below for BIP100, BIP102, and other complications.)  Note that even the Core version is trivially patched to accept 8 MB blocks.

The chain will (theoretically) split once the first big block B(N) gets mined.  There will be a "big-block" branch that grows on top of that block, containg perhaps other big blocks; and a "small-block" branch that starts with an alternative small block C(N) with the same block number and contains only small blocks.

If, at that moment, more than 50% of the miners accept big blocks, the big-block branch (mined by them) will eventually grow faster than the small-block branch (mined by the rest of the miners).  The split will be permanent and the big-block branch will grow faster.

If, at that moment, less than 50% of the miners accept big blocks, the small-block branch will eventually grow longer.  Then the big-block miners will stop mining their branch, which will be orphaned, and they will start mining the small-block branch too.  If someone mines another big block, the chain will split again.  This situation will repeat over and over, as long as some miner happens to mine a big block.  There will be a single small-block chain with recurrent big-block side branches that are orphaned sooner or later.

Sane bitcoiners should want the first case to happen, and as cleanly as possible: namely, with almost all the miners accepting big blocks.  Then if someone mines a big block, the few stubborn miners who refuse to accept big blocks will be left mining a slow chain with a huge and growing backlog.   In this case, clients who accept big blocks will be fine, while clients who reject them will not be able to use bitcoin until they upgrade.

Blockstream fans who are not totally stupid will want the second case to happen, but also as cleanly as possible: namely, with almost all miners rejecting big blocks.  Then, if someone mines a big block, the few miners who accept it will waste time mining on top of it, only to have that branch orphaned right away.   In this case, all clients will be fine, except that clients who accept big blocks will see occasional big orphans.

Bitcoiners who are stupid, or are into financial sado-masochism (like those who are planning to sabotage the blockchain voting), will try to get some intermediate situation when the miners who accept bitcoin are neither the vast majority nor a small minority.  In this case, the situation will be highly confusing either to the clients who accept big blocks, or tho those who reject them, or possibly for both.

The competing BIPs with other notions of "big block" will make the situation more confusing.  Unless Jeff is into sado-masochism too, he should retract his "compromise" 2 MB proposal.  It is obvious by now that the Blockstream devs will never accept any compromise solution.

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 25, 2015, 09:41:40 PM
 #449

So you completely missed the entire point of what I said ... the issue is they are using a too low 75% ...

...
BIP101 activates *only* if XT has >75% of hashing power.
...
False.

Bitcoin mining is random statistics.
It's not 10 minutes per block, every block.

Edit: and to give an example:
My pool mined 17 blocks at under 30% difficulty - yep luck was on a roll when that happened.
At the time, if there was any voting happening, for that period of time my pool would have effectively voted at over 300% of it's hash power.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
tvbcof
Legendary
*
Offline Offline

Activity: 2296


View Profile
August 25, 2015, 10:05:00 PM
 #450

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things: [ ... ] but more importantly, XT wont happen.

It is irrelevant which version of the software is being used (Core, XT, or other).  What happens after the first big block is mined depends only on how many miners accept big blocks.  ("Small block" = at most 1 MB; "big block" = more than 1 MB but not more than 8 MB.  See below for BIP100, BIP102, and other complications.)  Note that even the Core version is trivially patched to accept 8 MB blocks.

The chain will (theoretically) split once the first big block B(N) gets mined.  There will be a "big-block" branch that grows on top of that block, containg perhaps other big blocks; and a "small-block" branch that starts with an alternative small block C(N) with the same block number and contains only small blocks.

If, at that moment, more than 50% of the miners accept big blocks, the big-block branch (mined by them) will eventually grow faster than the small-block branch (mined by the rest of the miners).  The split will be permanent and the big-block branch will grow faster.

If, at that moment, less than 50% of the miners accept big blocks, the small-block branch will eventually grow longer.  Then the big-block miners will stop mining their branch, which will be orphaned, and they will start mining the small-block branch too.  If someone mines another big block, the chain will split again.  This situation will repeat over and over, as long as some miner happens to mine a big block.  There will be a single small-block chain with recurrent big-block side branches that are orphaned sooner or later.

Sane bitcoiners should want the first case to happen, and as cleanly as possible: namely, with almost all the miners accepting big blocks.  Then if someone mines a big block, the few stubborn miners who refuse to accept big blocks will be left mining a slow chain with a huge and growing backlog.   In this case, clients who accept big blocks will be fine, while clients who reject them will not be able to use bitcoin until they upgrade.

Blockstream fans who are not totally stupid will want the second case to happen, but also as cleanly as possible: namely, with almost all miners rejecting big blocks.  Then, if someone mines a big block, the few miners who accept it will waste time mining on top of it, only to have that branch orphaned right away.   In this case, all clients will be fine, except that clients who accept big blocks will see occasional big orphans.

Bitcoiners who are stupid, or are into financial sado-masochism (like those who are planning to sabotage the blockchain voting), will try to get some intermediate situation when the miners who accept bitcoin are neither the vast majority nor a small minority.  In this case, the situation will be highly confusing either to the clients who accept big blocks, or tho those who reject them, or possibly for both.

The competing BIPs with other notions of "big block" will make the situation more confusing.  Unless Jeff is into sado-masochism too, he should retract his "compromise" 2 MB proposal.  It is obvious by now that the Blockstream devs will never accept any compromise solution.

Weren't you supposed to be some sort of a comp-sci professor?  I don't know how to be kind about it, but your students are getting screwed...your whole post is chock-full-o'-fail.

Note that to a satoshi-based cyrpto-currency solution the proper terminology is 'longest valid chain'.  Bloat-blocks or any other illegality is simply ignored.  It doens't matter if the chain stretches from here to China.  What this means is that Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

As for mining, I supposed and Meni Rosenfeld (who, unlike you, actually does understand Bitcoin and algorithms generally) confirmed that the mining effort will be primarily driven by the market value of the product.  I would add that when transaction fees become a factor (hopefully some time before the earth stops cooling on core) they would be added to 'market value.'  Thus, the trajectory of any XT-like alt forked off the Bitcoin blockchain would have to command a high market value relative to Bitcoin in order to attract mining.  It's actually no different than any other sha256 alt (if there are any which still survive.)

The best hope the XT attackers have would be to subsidize the shit out of XT (and probably attack Bitcoin as well) in order to try to get the flame started on mopping up sha256 hashes.  I hope like hell they do because I plan to split my coins and sell XT like hell when the opportunity arises.  With luck it IS the govt spooks who are behind XT and Gavin's various malfeasance because they have deep pockets to do this subsidization and it would be an opportunity to get some of my tax dollars back.


sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 25, 2015, 10:41:14 PM
 #451

So you completely missed the entire point of what I said ... the issue is they are using a too low 75% ...

...
BIP101 activates *only* if XT has >75% of hashing power.
...
False.

Bitcoin mining is random statistics.
It's not 10 minutes per block, every block.

Edit: and to give an example:
My pool mined 17 blocks at under 30% difficulty - yep luck was on a roll when that happened.
At the time, if there was any voting happening, for that period of time my pool would have effectively voted at over 300% of it's hash power.

But that's possible, isn't it? I mean hashing rate is probabilistic.  If you take a narrow sample you can easily find boundary cases proliferate. But then if you take the sample as a whole, then the 'averages' will dominate. While your pool did well for that run of blocks, there had to be another n blocks where the difficulty was over 200%.

So its not random overall.  But any sample will appear to be.

We must make money worse as a commodity if we wish to make it better as a medium of exchange
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 26, 2015, 12:30:09 AM
 #452

Weren't you supposed to be some sort of a comp-sci professor?  I don't know how to be kind about it, but your students are getting screwed...

Indeed. Students who are used to uncritically memorize and repeat what the textbooks say often get screwed in my courses.

Quote
Note that to a satoshi-based cyrpto-currency solution the proper terminology is 'longest valid chain'.  Bloat-blocks or any other illegality is simply ignored.

No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Quote
Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

Quote
the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2408



View Profile
August 26, 2015, 12:40:16 AM
 #453

^^^ "Very skeptical of bitcoin's long term success" ^^^ (i.e. actively trolling for it's demise since learning of bitcoin)

... pushing for divisive XT, nuf said.

kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 26, 2015, 12:44:19 AM
 #454

...
Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.
...
Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income contrary to the design of Bitcoin.

Bitcoin is designed to shift from block reward to transaction fee reward.
Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.
The solution is to simply not apply such changes to start with.

The BIP101 hard coded block size growth is also based on an invalid extrapolation, due to insufficient data.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
erik777
Sr. Member
****
Offline Offline

Activity: 286


View Profile
August 26, 2015, 01:36:14 AM
 #455

Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Considering it may be a proxy used by legitimate users, you only temporarily lower its priority to permit the misbehaving source to possibly drop off, permitting healthy traffic to be prioritized again once the malicious source drops off.  

We do not need to trust blacklists, whitelists, or any other list in order to combat DDos.  Bitcoin is and must remain a trustless network.

 
madjules007
Sr. Member
****
Offline Offline

Activity: 402



View Profile
August 26, 2015, 01:52:56 AM
 #456

Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Spot on. That's what I see -- there is nothing wrong with deprioritizing traffic that is mounting a DDOS attack. There is something wrong with coding a centralized blacklist into the protocol. Play with semantics all you want, and rationalize how its intent may be noble -- it is a blacklist.

I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Pardon my ignorance if I am being foolish......

██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
RISE
erik777
Sr. Member
****
Offline Offline

Activity: 286


View Profile
August 26, 2015, 02:14:08 AM
 #457

I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Even in the best case scenario, if it were used only for DDos, it would effectively shut down shared IPs including Tor exit nodes and proxy servers, impairing innocent users from being able to use them.  

The attraction to TRY to use this to shut down dark markets would be very tempting by those trying to do so, creating an incentive to use DDos to blacklist Tor IPs.  Ironically, this incentive would INCREASE DDos attempts, rather than reduce them.  

To the extent that these parties desire to remove anonymity from Bitcoin, this is a very enabling capability. 

While blacklists might appear on the surface to protect miners from DDos, they create a new avenue of DDos where the target becomes shared IP addresses. 
tvbcof
Legendary
*
Offline Offline

Activity: 2296


View Profile
August 26, 2015, 02:55:22 AM
 #458


No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Ya, clear that you selectively editing and are talking nonsense to cover up your mistake (or lack of understanding.)

Quote
Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

Miners will mine where they can make money.  The effort and hence the difficulties will be less on less valuable forks (or core) so they can mine more per unit time.

Your wishful thinking about how 'miners better follow a lead' is nothing more than that and has no basis in reason and no predictive power of future reality.

I suggest that you consult with someone who knows a little about crypto-currencies and try to pick up some clues.  This might allow you to take a position and maybe you will not always be nervous and uptight about your state sponsored mainstream-land pension.  It may help uncloud your analytical abilities.  Even that might not be enough though.  Frankly speaking, I don't really see that you have the mental horsepower to do well in anything which is at all abstract or requires anticipating the future accurately.

Quote
the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.


"economic majority" is simply a throw-away buzzword invented to impress the mouth-breathers (but it works on comp-sci proffesors also it looks like.)

I will tell you that my own gauge of the value of core Bitcoins will _increase_ if/when the XT drones are led away by some pied piper.  I doubt that I am alone among hodlers in this.  If so, the value of core Bitcoins might hold up surprisingly well and any miners who had been throwing hashes at XT (or some other similar alt fork) will come rapidly back.


JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 26, 2015, 03:46:20 AM
 #459

Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income

Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.  Then adoption will drop, public image will be in sambles, and the price will probably crash.  Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived. 

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size.  (The five largest Chinese miners already did.)

"Big blocks" does not mean unlimited block size.  For practical programming and resource planning reasons, the block size limit must be fairly constant and not too big.  At present, 2 MB would be sufficient to avoid congestion for another year or two, but would offer little protection against spam attacks.  The popular 8 MB limit would be good for several years.

Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time. 

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB.  Until 2018 they will be in agreement, and until then they may change their software again.

Quote
[ ... ] contrary to the design of Bitcoin.  Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.  The solution is to simply not apply such changes to start with.

Amazing how one can turn the facts so completely upside down. 

The design of bitcoin did not have a significant block size limit.  Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays.   This assumption was so obvious that it did not even have to be stated explicitly.  Only a fool would design a network to be operated in congestion mode.

Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin.  Some transactions would be delayed for hours or more, no matter what fees they pay.

Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years. 

Quote
Bitcoin is designed to shift from block reward to transaction fee reward.

Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
kano
Legendary
*
Offline Offline

Activity: 2240


Linux since 1997 RedHat 4


View Profile
August 26, 2015, 05:24:00 AM
 #460

Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income
Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.
Well at least whoever paid for those SPAM attacks got their money worth with you: believing in the dire straights the XT goons want people to think are already here Smiley

Quote
Then adoption will drop, public image will be in sambles, and the price will probably crash.
Nah, that's what XT has done to BTC already ...

Quote
Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived. 

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size.  (The five largest Chinese miners already did.)
They were approached directly by the XT goons and their response?
To use a non-XT voting method to vote for a block size ...
We don't need a bigger block size now.
We do need to have in place shortly the ability to increase the block size so that some time down the track when the pools/miners believe it would be ideal to increase it, that will be possible without the crap that is going on now.

Quote
Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time. 

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB.  Until 2018 they will be in agreement, and until then they may change their software again.
Read BIP100 ... seems you didn't bother to do that ...


Quote
Quote
[ ... ] contrary to the design of Bitcoin.  Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.  The solution is to simply not apply such changes to start with.

Amazing how one can turn the facts so completely upside down. 

The design of bitcoin did not have a significant block size limit.  Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays.   This assumption was so obvious that it did not even have to be stated explicitly.  Only a fool would design a network to be operated in congestion mode.
Only a fool would believe it is already in "congestion mode"
and
Only a fool would look at a design and ignore the implementation.

Quote
Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin.  Some transactions would be delayed for hours or more, no matter what fees they pay.
Your problem is your lack of temporal relevance.

Quote
Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years. 
Sorry, that '6' you are trying to use as hyperbole fails.
Halving only occurs every ~4 yours ... (210,000 blocks)

Quote
Quote
Bitcoin is designed to shift from block reward to transaction fee reward.

Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.
No it can't.
Nothing controls the fees that pools/miners will accept but each pool/miner themselves.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!