|
Nice analogy.
But mining has one flaw there. As everyone can mine by simply buying hardware and investing electricity long term mining will always develop in the direction of a zero sum game. No matter how much fees are paid.
Therefore fees (long term) don't actually affect the profits of miners (very much) but only how much money is spend to secure the network.
Or in a analogy:
Just imagine in a community some guy shows up, offering to give 10,000 USD away every day. He will split this amount through everyone in this community that burns wood, depending on the amount of wood one burns.
What will happen? Everyone is going to buy more and more wood each day to burn it and get the biggest share of the 10,000 USD until closely to 10,000 USD worth of wood are burned each day.
|
|
|
|
|
Self adjusting algorithm like difficult. We don't know what the future brings (hardware and demand wise) changing it again might be even harder, so a solution that possibly fixed this once and for all.
|
|
|
|
Well, there is a more or less simple solution for that.
As "Big block" Nodes can also accept "small block" Blocks, I would include something that somehow "markes" a Block found by a "big Block" miner. Then as soon as at least say 80% of the last 2000 Blocks are "marked", the change activates and bigger blocks are allowed. It could also start a countdown of another 2000 Blocks to give the remaining 20% time to change their mind.
Which takes me right back to the fact that the blockchain will most likely split immediately as soon as the first "big block" is mined. There isn't likely to be a "small block" chain overtaking the "big block" chain once the first "big block" is mined if the change is implemented properly. OK, I agree here. But it wouldn't happen from one moment to the next like OP described due to No in order to raise the Block limit, pools would need to change their version, too.
They tend to not upgrade until a new version is considered save.
|
|
|
|
Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.
Yes, but these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks. Assuming the chain that accepts larger blocks has at least 49% of the hashing power, the blockchain would most likely split as soon as the first block larger than 1MB was mined (making it immediately the "longer" chain by one block). As long as the "small Block" Chain has more than 50% of the hashing power, wouldn't it eventually end up to be the longer chain again? As old Nodes wouldn't accept Blocks from "Big Block" Chain the split would occur as soon as this chain has the majority (>50%)? I might have my math messed up a bit here (it's early and I'm not much good at logical thinking in the morning), but if the "big block" chain has >49% of the hashing power and adds a block before the "small block" chain than there is roughly a 1% chance that the "small block" chain will add a block before the "big block" chain adds a second. At that point the chains will be equal length, but the "big block" chain will have already been working on its next block for the entire time that the "small block" chain was trying to catch up. The chance that the "small block" chain will add two blocks before the "big block" chain adds one block is something like 0.01% right? So yes, this means that "eventually" that 0.01% chance should add up over time and the "small block" chain would pass up the "big block" chain. However, how long is that likely to take? Is my math right if I estimate 5,000 blocks for a 50% chance of passing up the "big block" chain? Isn't that 34 days? If the "big block" chain stays longer for a month, how many people will "jump ship" from the "small block" chain to the "big block" chain during that time if the "big block" chain is starting to look like a permanent fork? Enough to increase the hashing percentage from >49% to >50%? If so then it becomes likely that the "small block" chain will not catch up. Of course, I suppose it is possible if the split stayed anywhere near 50% that the "big block" chain could remain only a few blocks ahead of the "small block" chain. Then 6 months later with a small run of luck the "small block" chain could suddenly overtake the "big block" chain and BAM 6 months of blocks orphaned on the "big block" chain. Since some of those inputs will have been spent elsewhere on the "small block" chain you'd have transactions lost to double-spends all over the place. What a mess. Seems like as soon as a "big block" was mined, a release would be quickly offered with a checkpoint to prevent something so devastating from happening, right? Well, there is a more or less simple solution for that. As "Big block" Nodes can also accept "small block" Blocks, I would include something that somehow "markes" a Block found by a "big Block" miner. Then as soon as at least say 80% of the last 2000 Blocks are "marked", the change activates and bigger blocks are allowed. It could also start a countdown of another 2000 Blocks to give the remaining 20% time to change their mind. |
|
|
|
I'm unhappy with either future.
Intuitively, a block size limit of 1MB seems wrong, but allowing blocks of arbitrary size seems wrong too.
I don't think this needs to be a dilemma. I think we can have it both ways: A network that handles thousands of transactions per section AND where a normal user can still contribute towards storing the blockchain.
Whether this will require blockchain pruning, swarm nodes, storage fees, or some other solution, I don't know, but in either case it's a major project that will take years to implement.
In the meantime, we need a stopgap solution, and the limit needs to be increased to some new value X. I trust the developers to decide what that X should be.
I also don't think just increasing the Blocksize to a new max would be a Solution. Then we would eventually end up to have this problem again. Also a free Blocksize would be dangerous. We have already a self adjusting process for the creation time of Blocks in place, that ensures, no matter how the technical development goes blocks are (on average) found on a constant rate. I'm sure a self adjusting Max Blocksize Function is possible, too. A function that ensures that transaction space always remains scarce and limited. But at the same time ensures that there will be enough space that it remains possible to do a transaction. F.E.: One that adjust the Blocksize in a way (possibly with each difficult adjustment), that during Peak (14 biggest Blocks of the last last 144?) hours not all transactions can be included immediately but eventually during the low traffic times (14 smallest Blocks of the last last 144?). Also include a limited increase / decrease at each change. |
|
|
|
Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.
Yes, but these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks. Assuming the chain that accepts larger blocks has at least 49% of the hashing power, the blockchain would most likely split as soon as the first block larger than 1MB was mined (making it immediately the "longer" chain by one block). As long as the "small Block" Chain has more than 50% of the hashing power, wouldn't it eventually end up to be the longer chain again? As old Nodes wouldn't accept Blocks from "Big Block" Chain the split would occur as soon as this chain has the majority (>50%)? |
|
|
|
Diese 8stellige Stückelung ist ja nicht in Stein gemeißelt, wenn´s nötigt ist kann das auch geändert werden.
Naja, hast du dir mal die Diskussionen zur max. Blocksize rein gezogen? z.B: https://bitcointalk.org/index.php?topic=145475.0;topicseenDas zu ändern würde wahrscheinlich noch komplizierter. |
|
|
|
|
Thank you for upgrading, theymos.
Good to see the Forums BTC finally getting used.
Thanks to Gox for providing us this forum for such a long time, but I'm glad to see that the forum is independent now.
|
|
|
|
Oh come on. Yes I agree this is an important issue. But do we really need 100 Threads about this? There are some interesting discussions going on about this topic and with more and more threads it gets impossible to keep track. Also you are paranoid (again): Whoever runs bitcoin.org runs bitcoin. Unfortunately bitcoin is not decentralized in this regard. At any moment, whoever runs that site can put up Bitcoin 0.9.0, call it an urgent release and dispose of the block limit.
No in order to raise the Block limit, pools would need to change their version, too. They tend to not upgrade until a new version is considered save. Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.
Yes, put these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks. I'm sorry. The war is lost. Unless one of you buys out bitcoin.org or defames it to the point that it drops off the front page of Google. There is too much lobbying pressure from Mt.Gox, SatoshiDice and others for the block limit to remain.
Which war? I don't see burning servers and dead Bitcoiners on the streets. And I have jet to see a single statement about this from SD or GOX. |
|
|
|
|
Das ist eigentlich nur das Aufbringen des Lötzins / der Kontaktkugeln auf den Chips, oder dem Gesamten Wafer und anschließendes "zerschneiden" in einzelne Chips.
|
|
|
|
|
So this is basically the third thread about the max. Blocksize?
So how would the Blockchain be some over System like the FED-Line not violate those principles (FINITENESS, TANGIBILITY, TRANSPARENCY, ANONYMITY, SECURITY, DECENTRALIZATION, SELF-OWNERSHIP, INTEGRITY, PRACTICALITY, RATIONALISM).
Like I already said, if there where 180 Mil. Bitcoin users, that would allow one Blockchain transaction per User per Year. Directly meaning, that the average User would need to Use some kind of (centralised, intransparent, unanonimous, etc.) Provider and never be able to validate his BTC ownership on the Blockchain.
That can't be a solution.
Also, Disk space is already cheap and will become cheaper. It will still be possible for many users to run full nodes for a long time, ever if the space and bad with requirements increase.
|
|
|
|
Right now, it's riding higher than it ever has and spiking upwards like crazy, and there's every chance you can still make money as a speculator – Welcome, welcome new "investors". I wondered when we see the first of those articles. If we break our all time high, I expect to see a lot of them. Then we will be bubbling like crazy (again). |
|
|
|
A large dump from a big holder is all that it takes.  I admit it looks good for BTC right now, but don't forget Bitcoin is the first of this kind and still experimental. There might be problems occurring that we can't even think about jet. Also, 30 B, do you really believe this? ~3000 USD / BTC. Bitcoin have to be a lot more useful to be worth that much. |
|
|
|
|
I still fail to see how this max Block chain limit could work longterm. The 1MB Limit allows for ~500K transaktions a day.
Now Imagine 180 Mil. People using Bitcoin. That would mean on average every User could make only one Blockchain transaction a Year.
If Bitcoin could still work that way thanks to off Blockchain services. It could possibly even work without the Blockchain at all.
If there are enough off Blockchain services that the average User never needs to make a Blockchain transaction, thus has the possibility to verify his BTC actually exits, where is the difference to the system we already use now?
And if maybe a few Transactions on the Blockchain per month for our off Blockchain BTC services are enough, why should this create high fees?
|
|
|
|
|
To make you profit is simply not the purpose of this sites.
If you would find a way to make a significant amount of money from this sites, you could be sure they would fix this.
|
|
|
|
Necroposte hier mal wieder Ein Bitcoin ist jetzt auf Gleichstand mit einer Unze Silber. Könnte man ja fast den Jungs im Silber.de-Forum unter die Nase reiben. |
|
|
|
|
Finally, thank you guys.
And right on time to the press attention Bitcoin currently receives.
Are there any changes made from the release candidate, or can I just keep it running?
|
|
|
|
Maybe some large specimen of Mycetozoa? We have them (rarely, seen one only twice in my live) where I live, but they don't get larger than a playing card. Amazing Creatures.  |
|
|
|
|
Again. Yesterday was a holiday in the US.
Besides, there is almost everyday someone acting like you about Bitinstant.
In the most cases the issue could be linked to a mistake on the site of the user.
In the (very) rare occasions this was actually a fault from Bitinstant they fixxed it ASAP every single time.
So why don't you stop fucking around and post in their support thread?
Unless you just a Troll.
|
|
|
|
|
Show Posts
