Pages:
Author

Topic: Hard fork, which road will you take? (poll) (Read 2186 times)

legendary
Activity: 3472
Merit: 4801
March 24, 2013, 03:03:32 PM
#21
If a BitCoin fork emerges with a sensical tx fee system (or no damn tx fee at all!) I'll jump on that whole heartedly!

I've had just about enough of tx fees. Been almost completely turned away from BitCoin several times now.

And dont even start telling me 'BTC is not for micro-transactions' It should be for whatever the hell we want it to be. What exactly do you think a Satoshi is ffs!!?

Bitcoin is completely voluntary:

You can choose not to pay fees on your transactions by using a wallet that does not enforce fees.

Keep in mind though that the peers you connect to can also choose to relay your transaction on the network (or not relay it) if they feel that it is is part of a DOS attack (or any other reason they may have for refusing to relay a transaction).  They may choose to make this determination however they like (including basing the decision on the size of the transaction and relative amount of fees).  They make their decision by running a wallet that enforces the transaction relaying rules that they choose. If you don't like these relay rules, you are welcome to find (or create) a wallet that will allow you to connect directly to the IP addresses of the recipient of your transaction and various miners or mining pools so that you don't have to rely on peers to relay it.

Keep in mind as well that the miners can choose to include your transaction in a block (or not include it) if they feel that it is not in their personal interest to do so (or any other reason they may have for refusing to include it).  They may choose to make this determination however they like (including basing the decision on the ratio between the fees included in the transaction and the size of the transaction).  If you don't like these mining rules, you are welcome to run a miner that will solve blocks with your transactions or find like-minded miners willing to do the same and ensure that your transactions get to them.
legendary
Activity: 1001
Merit: 1005
If a BitCoin fork emerges with a sensical tx fee system (or no damn tx fee at all!) I'll jump on that whole heartedly!

I've had just about enough of tx fees. Been almost completely turned away from BitCoin several times now.

And dont even start telling me 'BTC is not for micro-transactions' It should be for whatever the hell we want it to be. What exactly do you think a Satoshi is ffs!!?

I was also annoyed in the beginning about the tx fee but as I got to understand the bitcoin ecosystem, I realized how important it is. Also, there are ways to send coins without a fee. I'll let you figure that out yourself.

legendary
Activity: 1120
Merit: 1152
If a BitCoin fork emerges with a sensical tx fee system (or no damn tx fee at all!) I'll jump on that whole heartedly!

I've had just about enough of tx fees. Been almost completely turned away from BitCoin several times now.

And dont even start telling me 'BTC is not for micro-transactions' It should be for whatever the hell we want it to be. What exactly do you think a Satoshi is ffs!!?

Sacrificing the security of peoples' savings just so your customers can earn one hundredth of a penny by viewing an ad on the internet just isn't worth it.

You want something for nothing, and you aren't going to find it here.
full member
Activity: 196
Merit: 100
If a BitCoin fork emerges with a sensical tx fee system (or no damn tx fee at all!) I'll jump on that whole heartedly!

I've had just about enough of tx fees. Been almost completely turned away from BitCoin several times now.

And dont even start telling me 'BTC is not for micro-transactions' It should be for whatever the hell we want it to be. What exactly do you think a Satoshi is ffs!!?
legendary
Activity: 1120
Merit: 1152
For scaling, I favor alternate end-user solutions which are welcome to, and probably would by nature, derive their value by riding on Bitcoin.  That is, they would balance against one another regularly using Bitcoin as a means for doing so.

I strongly believe that the most important thing about Bitcoin is that it's a truly decentralized store of value. Everything else is secondary to that function, and as you can say, can always be implemented on top of the secure foundation Bitcoin provides.

When it comes to value, you have to ask yourself if Bitcoin hit $75USD because it is yet another way to pay someone over the internet, or because it's the first secure digital store of value that is independent of central authority? Frankly if I were a citizen of Cyprus or Argentina who had bought my first Bitcoins because I wanted to protect my savings I'd be downright pissed if that security was being sacrificed just so the whole world could make penny bets over the internet.

If we keep the blocksize small enough that everyone can participate in validation and mining, you can choose who you are going to trust to hold your spare change on your behalf to make those penny bets, and keep you savings secure. But if we let the blocksize grow without bound, fundamentally you don't have any choice but to trust the few validating nodes out there. At best they don't be able to lie to you, but they will be able to freeze your money just like PayPal and governments through blacklists and other censorship under the guise of "crimefighting", "anti-terrorism" and "tax evasion". At worst, if the community doesn't have the data comprising the blockchain, those few validating nodes can force any change they want.

I'll admit, I'll be rich too if Bitcoin does a quick exponential rise to VISA scales at the cost of centralization, but long-term freedom is more important to me than quick riches.
legendary
Activity: 4690
Merit: 1276
Regardless of who had what in mind when, I favor retaining the existing processing rate, or keeping it well within what is feasible to maintain under a situation where commercial network providers are antagonistic to the Bitcoin system.

Bitcoin is currently simple and has proven fairly robust in part because of this.  I favor focusing on hardening what we have and making it a backing-store type solution which can be realistically relied upon in the face of widespread attack by infrastructure providers.  To me this means keeping the solution limited enough to make a broad segment of the community and the world capable of participating as _full peers_ without great expense.  Hopefully being a 'peer' would require only an expenditure which one could realistically walk away from if one is put under pressure.

For scaling, I favor alternate end-user solutions which are welcome to, and probably would by nature, derive their value by riding on Bitcoin.  That is, they would balance against one another regularly using Bitcoin as a means for doing so.

I believe that such a solution would promote trust in the reliability of Bitcoin (it certainly would in my mind) as well as provide better end-user experiences faster, and which could also scale to meet the demands of the entire world's economic activity if need be.

---

On the other hand, if Bitcoin attempts to scale to be 'as big as Visa' there will probably be a window where it will work enough to make me fairly wealthy.  My biggest complaint is that it could be nowhere near enough to be 'as big as Visa'.  Then what?  We are right back to where we are today except that there are only a small number of very expensive 'peers' who are making the system work.  At that point Bitcoin is, in my mind, pretty vulnerable to the most significant form of attacks.  (Namely legal attacks sponsored by state bodies.)

edit: s/bit/big/g
full member
Activity: 154
Merit: 100

Also, stating it is a bug fix is a) objective

No.  It is a bug.  For the most part the devs recognize it as a bug as well as most of the community.  It is software not behaving to the specification and failing, and there is a fix. 

0.7.2 clients do not recognize valid blocks that while large are within the size limits.

Telltale signs of a bug:

  • The client will actually create blocks it rejects.
  • Nobody knows about the behaviour.
  • We still don't have a simple formula that can determine a block's validity perfectly.

The block size limit is not raised by this May 15 fix. Blocks of the maximum size (1 MB) are already possible. The bug fix simply allows the client to parse some specially constructed blocks with a large number of txins or txouts, which it should always have been able to.


I thought the 0.8v removes the "soft limit" of 250kb or whatever, is this correct?


I sent a small transaction with a high priority (because of age and confirmations of inputs etc) and it took 4-6 hours to be confirmed, As we are seeing more bitcoin downloads we should be preparing for more traffic, and these confirm times are too long, especially when bitcoin is often wrongly described as fast free transactions, new users may be put off by this.


I think we should be removing the block size limit in he next update, as the incident of the last fork is still fresh in peoples minds and they might upgrade a little faster this time. If we don't do something we could run up on the hard limit and it would be disastrous PR "Bitcoin experiment fails, transaction blockage"

legendary
Activity: 1246
Merit: 1077

Also, stating it is a bug fix is a) objective

No.  It is a bug.  For the most part the devs recognize it as a bug as well as most of the community.  It is software not behaving to the specification and failing, and there is a fix. 

0.7.2 clients do not recognize valid blocks that while large are within the size limits.

Telltale signs of a bug:

  • The client will actually create blocks it rejects.
  • Nobody knows about the behaviour.
  • We still don't have a simple formula that can determine a block's validity perfectly.

The block size limit is not raised by this May 15 fix. Blocks of the maximum size (1 MB) are already possible. The bug fix simply allows the client to parse some specially constructed blocks with a large number of txins or txouts, which it should always have been able to.
legendary
Activity: 1386
Merit: 1004

Also, stating it is a bug fix is a) objective

No.  It is a bug.  For the most part the devs recognize it as a bug as well as most of the community.  It is software not behaving to the specification and failing, and there is a fix. 

0.7.2 clients do not recognize valid blocks that while large are within the size limits.
hero member
Activity: 533
Merit: 500
^Bitcoin Library of Congress.
The limit will be raised, of course. But why now OR in years? What about "in some months"?

0 < X < infinity.  So it can be less than one year.  Will change poll to reflect that.
hero member
Activity: 533
Merit: 500
^Bitcoin Library of Congress.
I state, "From what I've read", "I wanted to see what the common thought was", and "Please post your thoughts".  And then get accused of spreading FUD? Huh Tongue

Also, stating it is a bug fix is a) objective, and b) does not change the fact that with the 0.8 clients there eventually WILL be a hard fork.  Not that this is necessarily bad, but there still will be a hard fork.
legendary
Activity: 1386
Merit: 1004
From what I've read it seems the devs decided this without a really big community consensus Undecided and I wanted to see what the common thought was.  Please post your thoughts and discussion on the miner compensation is encouraged.

upgrade info: http://bitcoin.org/may15.html
compensation info: https://bitcointalksearch.org/topic/compensating-miners-on-the-wrong-side-of-the-big-fork-156641

Please do not spread FUD. I don't think you really know what's happening. The May 15 upgrade is just a bug fix, not rule change.

+1

This is about replacing errant software not about changing the rules. 
If you have a broken client, fix it or don't complain when it fails.

Outright replacement and parimater changed are both offered as options.

legendary
Activity: 1148
Merit: 1008
If you want to walk on water, get out of the boat
The limit will be raised, of course. But why now OR in years? What about "in some months"?
legendary
Activity: 1792
Merit: 1111
From what I've read it seems the devs decided this without a really big community consensus Undecided and I wanted to see what the common thought was.  Please post your thoughts and discussion on the miner compensation is encouraged.

upgrade info: http://bitcoin.org/may15.html
compensation info: https://bitcointalksearch.org/topic/compensating-miners-on-the-wrong-side-of-the-big-fork-156641

Please do not spread FUD. I don't think you really know what's happening. The May 15 upgrade is just a bug fix, not rule change.
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
Another poll that sucks goat balls... Few critically important missing options.
sr. member
Activity: 322
Merit: 250


I've PM'ed this idea to some in high places that have just ignored it.  Maybe for very good reasons.  *shrugs*  I'll put it out there again.


variable block frequency.  what I can imagine to be a big refactoring of the algorithms.


When the old telecom people found they had problems with data transport, rarely was the data unit size increased, but rather decreased and the frequency increased.
You know why:  propagation delay - latency.


Now that the telecoms have copious amounts of fiber for transport - the paradigm has shifted - and now they just throw bandwidth at all their problems.

But keep in mind - all this fiber is for the backbone, and PoPs, of the internet.  We don't have that luxury.


I'd like to see a variable block frequency algorithm that a) maintains 21 million b) uses TX mem pool pressure as a factor and c) maintains scarcity in the volume of TX allowed in order to continue encouraging fees for competition for access to the block chain.

The obvious problem being c.  Mem pool pressure stats are not synchronized across nodes





legendary
Activity: 1512
Merit: 1049
Death to enemies!
I'm not against rising the limit for my own profit. I don't gain from it in any way. I'm against it because of 1. the transitional period is too short and 2. the network is still very small compared to future use potential and some people (not me) already encounter blockchain size problems.

Many probably don't know that early Bitcoin versions had artificial tx limits to prevent early blockchain spam. And how many of transactions today can be considered "spam"? I know some people (not me) consider Satoshi Dick a spam and attack on Bitcoin.

If the problem is tx volume in 10 min average not fitting in current block size limit, then raise the block limit. Give enough time for upgrade, like http://bitcoin.org/feb20 did. 1.5 years to not force users to run new and potentially bad software version. If problem is blockchain size, implement ultraprune.
legendary
Activity: 1540
Merit: 1000
If the infrastructure cannot even handle a few million people how do we expect to ever hope to have global trade and take on the USD? The people who are against raising the limit and fixing things seem pretty short sighted and greedy in my opinion, Bitcoin was designed to be a currency, not a way to get rich quickly.
legendary
Activity: 1176
Merit: 1015
From what I learned in another thread by a long term Bitcoin user, the max block size was a addition to fight spam and some miners wanna keep it small so the transaction fees go up and up.

However Satoshi envisioned the block size being hundreds of megabytes in size and powering a world changing network (Bitcoin)

If the limit is kept at 1mb, I fail to see how Satoshi's vision will ever be realised.

7tx/sec is not enough, Bitcoin's value comes from its ability to be used, If there are more than 7tx/sec being pushed through the network we will get a back log of transactions and this will be the end of Bitcoin (once it takes 100 days for your transfer to go through because people are pushing a million transactions a day through the network, or even a billion is not unreasonable)
legendary
Activity: 1512
Merit: 1049
Death to enemies!
If hard fork is required it must be done in X years with preparation. For now it is unnecessary move IMHO
Pages:
Jump to: