Topic: Bitcoin 20MB Fork - page 111. (Read 154790 times)

Mining with less competition.

how would anyone who has no coins now have coins after the hard fork ?

A hard fork would be a good opportunity for new players to get a foothold to replace those left behind.

Do you people seriously think this will result in some sort of war? I think you are exaggerating everything.

Hopefully for all our sake's, never.

Probably that is the main focus of the private Jekyll Island type meeting.  The content is supposed to be secret, but with 50 people or so on the invite list it's a fair bet that info will leak out.  How accurate and comprehensive the info/dis-info is will be an unknown.

  http://www.coindesk.com/bitcoin-elite-meet-secret-island-bilderberg-style-retreat/

The think almost sounds like an April fools joke to me, but I wouldn't rule it out.

so the answer is never. let' close this thread then. it is useless

when "consensus" is reached which will be never ...........no way 100% of people are ever going to agree
especially with trolls and fudsters who are just shouting for their own reasons ........

i guess we will have to go with the majority rather because a 100% agreement  is impossible


if this is implemented in the next version of bitcoin core and people are still using the old version will there effectively be two chains being mined at the same time ?

what happens to people who dont follow btc  everyday and leave their coins on the old chain which maybe orphaned after the new chain gains momentum ?

is there any possibility to lose coins that have been in stored on the "old" chain ?or any  risk of transcations being rejected from orphaned  to new dominant chain ?

when will this "fork" is going to happen?

There are actually a few considerations here which probably should not be co-mingled.

  1) What/how/why does your Multibit (or other SPV) client decide what chain to follow?

  2) No matter what the client, how are spends constructed.

2)
With respect to 2) I would recommend that everyone obtain a decent understanding of what transactions are, what a wallet is, and how transactions are constructed.  Here's a decent introduction for those who need to and would like to brush up:  https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/

Let's put it this way:  In times of internecine blockchain fork warfare, if you don't know how your transactions are being rolled, you will likely end up being rolled.  Gaining an overview of what is happening behind the scenes will make it possible to make good decisions about who is full of shit, who's code to use, and who might be fucking you over with undesirable or inflexible Unspent T(X)ransaction Outputs.  Specifically, ones which are polluted with post-fork coinbase and therefor locked to a fork which may or may not end up being the winner.

As the document above mentions, the wallet software normally makes it's decisions about which of the UTXOs belonging to the user it will choose to roll up into a spend.  The doc says:  "A sane wallet policy is to use older UTXOs first, wherever possible, but implementations differ."  This may or may not be the best policy in various circumstances.  I remember reading a little bit about alternate logic to formulate more tuned transactions in association with the immutability hassles (IIRC) but I don't recall why, exactly, that was worth doing.

Lastly on the subject, it could be handy to have certain kinds of options WRT UTXO's.  For instance, my cold-storage wallets were loaded with one large (by today's standards) transaction.  When I do a spend from one of these wallets, the whole amount is spent then change comes back.  I like the fact that my deep storage is deep in the blockchain, but it could be decidedly more handy to have a lot of more small UTXO's as options to formulate a transaction.  As we get nearer to  open warfare I'll re-visit this potential issue and see if I should undergo the hassle of digging out my deep storage wallets and re-structuring them.

1)
Falling back to 1) for a moment and looking at your suggestion about 'most hash-power', I would not expect things to necessarily be so simple.  If it is, it will be a short war.  I would expect various patches to be applied to full nodes which would not necessarily honor the longest chain.  This would happen naturally insofar as 'mpcoin' (aka legacy Bitcoin) would simply consider the 'gavicoin' chain invalid no matter it's length, but I could imagine it happening artificially as well for other reason.

I don't know the architecture of the client/server model in Multibit style SPV-land.  The things I do (think I) know is that a) any SPV client can sort hook up to any server it chooses, but I don't know how it makes the choice, and b) the client can autonomously verify that it has not been cheated by the server...at least down to the first {n} blocks deep.  I'm pretty unclear on the technical details of how these things work though (in part since I have little interest in using an SPV client.)  On presumes that the server's notion of the appropriate chain factors in to the results that the client achieves.  If a preponderance of qualified SPV servers favored one chain fork (through update to 'gavincoin' or some other patch applied) I would like to know more about what the end result for Joe Multibit might look like.

---

Again, I would expect there to be more than just Gavin and Mircea involved in a war.  I would anticipate a lot of other parties will see potential opportunities to capitalize on the confusion.  Most people who are savvy enough to end up winners are also perfectly capable of applying a patch to their own source code and having a new node (or 1000 new nodes) in operation in less than a minute of time.  A user who intents to be active during such an adventure really want to have the ability to understand at some level at least what is going on.

Ignoring the potential split for a moment, it would be a smart move for Bitcoin to be merge-minable.  I believe that I've amply demonstrated that mining will always approach being iffy from an economic perspective no matter what the coinbase reward, fees, transaction rate, etc.  Many times it will drop below, and I've heard reports of miners shutting down since they cannot operate in the black at this time.  Same thing happened a few years ago IIRC (though that was probably somewhat associated with the GPU -> ASIC transition as much as a price drop.)

So, Bitcoin's best hope to retain a safe percentage of potential sha256 hashing power is probably to hope that people mine Bitcoin as a side operation in order to pull in some extra bucks.  With a healthy sidechains ecosystem miners would probably be incented to support a given sidechain with a variety of rewards.  I would think that most sidechains would be designed to induce miners (and other support infrastructure like transfer nodes) to also support native Bitcoin since the sidechain relies on a healthy native Bitcoin for it's value proposition against other monetary alternatives.

your decision making process is a failure

Not too sure but I think the reason we can't just do 2mb instead of 1 is because we would need to fork again
Throwing it at 20mb should resolve the issue for quite some time.
Less I guess hosting capacity as others mentioned in the short run.

A 2MB fork would be easier for people to swallow.
 If everyone is so gung ho to fork Bitcoin lets fork the shit out of it. We could have a new Fork every fucking weekend, we could call it Forking Friday!
The media will tear Bitcoin apart after this.

For merged mining, the relevant coin has to accept that having a parent header is "just as good" as being the parent. I doubt either MPcoin or Gavincoin will be modified to be merge-mineable.

Edit: it would be interesting if they were both modified to be merge-minable.

Theymos (aka, Thermos) has so far run a remarkably censorship free forum, and with some minor exceptions all of the mods he selects are good about this.  Several who have abused their mod bit seem to be no longer among us.  I am sure that a fair bit of the content drives Thermos and his mods nuts but they can be commended for sticking to the laize-faire principles that Theymos, at least, seems to profess.  I give him slack for tolerating some individuals who are pretty scammy because I appreciate consistency in this regard.  I would be surprise to see Theymos run the forum with a significant tilt toward promoting one fork or another should internecine warfare break out.

anyone took or is tempted to take that bet actually?

If you buy up Bitcoin before the fork, then don't move it (keeping it in cold-storage (ie: off-exchange)), you get to "bet" on both forks at once.

The risk comes when you take up mircea_popescu on his "buy gavincoin at 25% off" offer. Edit: no takers so far.

Presumably, if you need to spend Bitcoin while waiting on the sidelines, You can buy some at an exchange, then spend immediately: assuming both your exchanger and retailer are using the same fork.

Edit: tvbcof has been bringing up an interesting question: how will SPV wallets react to all this. I think it is worth investigation. I suspect SPV clients will try to look at the block the transaction is included in, which means size is important. If a forking block is buried and not examined, the SPV client will probably side with the fork with the most hash-power.

Incidentally, that is how consensus is achieved in Bitcoin: the fork with the most hash-power wins.

This poll is irrelevant. As I've previously stated, under no circumstances should all of the votes be taken into consideration due to the nature of 'some' people.
The question is: how have we achieved consensus in the past?

maybe there is something I don't understand.


However I can't see why anyone would have a problem with an increased block size.


Now unless I am mistaken...

Let's say the pretend the current average of blocks is 780kb 

If the max size was increased to -100MB- tommorow then  the average block size will STILL be 780kb..


the only thing that has changed is the maximum size that the blocks can be.

For my calculation above, I was assuming the blocks would be about 20x larger. Since the current blocks are about 35% full, we are talking about 5-7MB blocks in the above scenario. I don't claim to know exactly how long it would take for blocks to get to that size. However, a rule of thumb is that information expands to fill the available space. That is to say, making the block-size larger does encourage more transaction. If I had to guess, I would say we can expect the first full 20MB block within 5 years.

I also would not be surprised if Bitcoin transaction growth grows faster than common Internet bandwidth: at least in the near term.

• About 15 years ago, I was on 56Kbps down, 30kbps up dial-up. (~10GB bandwidth cap, with less than 1-3GB of usage expected) (not really comparable).
• About 10 years ago I was on 3Mbps down, 640kbps up ADSL. 70GB cap.
• About 5 years ago, I was on 6Mbps down, 1Mbps up ADSL/VDSL. 100GB cap
• Now I am on 25Mbps down, 2.5Mbps up Cable. 250GB cap.
• If the rough trend continues, I will be on 50Mbps down and 5Mbps up in 5 years. 500-750GB cap.

Disclaimer: those numbers are not terribly consistent. The underlying technology and even price has changed over the years.