Bitcoin Forum
April 23, 2024, 06:13:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 [All]
  Print  
Author Topic: Oh god, I see a chance for lifting the 1M block size limit !!!  (Read 3615 times)
johnyj (OP)
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
March 12, 2013, 06:39:40 AM
 #1

Before I thought that's the most troublesome topic in bitcoin, but now this bug in BDB opened a window to lift that limit, Gavin you are so lucky!  Wink

1713895988
Hero Member
*
Offline Offline

Posts: 1713895988

View Profile Personal Message (Offline)

Ignore
1713895988
Reply with quote  #2

1713895988
Report to moderator
1713895988
Hero Member
*
Offline Offline

Posts: 1713895988

View Profile Personal Message (Offline)

Ignore
1713895988
Reply with quote  #2

1713895988
Report to moderator
1713895988
Hero Member
*
Offline Offline

Posts: 1713895988

View Profile Personal Message (Offline)

Ignore
1713895988
Reply with quote  #2

1713895988
Report to moderator
"You Asked For Change, We Gave You Coins" -- casascius
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713895988
Hero Member
*
Offline Offline

Posts: 1713895988

View Profile Personal Message (Offline)

Ignore
1713895988
Reply with quote  #2

1713895988
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1002


100 satoshis -> ISO code


View Profile
March 12, 2013, 09:53:10 AM
Last edit: March 12, 2013, 10:03:13 AM by solex
 #2

Before I thought that's the most troublesome topic in bitcoin, but now this bug in BDB opened a window to lift that limit, Gavin you are so lucky!  Wink

Would you propose to your fiance while standing in an elevator? Because this thread is showing similar impeccable skills at timing.

Anyone reading my posts will know that I have been all for raising the 1Mb limit at the right time, and in the right way. However, after today's events, that time is further away than previously imagined. A lot of reflection and thoughtful planning needs to go into any future change of this nature. More than we might have guessed 24 hours ago.

The first lesson of today is how to get people to accept the necessity of an upgrade path. Then how to get people to use it in a reasonable timeframe. Bitcoin can't reach its full potential being backwards compatible with every ancient version previously released. This is a real challenge.

Gyrsur
Legendary
*
Offline Offline

Activity: 2856
Merit: 1518


Bitcoin Legal Tender Countries: 2 of 206


View Profile WWW
March 12, 2013, 10:22:11 AM
 #3

start to use testnet coins as silver and prodnet coins as gold. start now. forget altchains!

EDIT: who want to buy testnet coins for testing their applications. pm me!

Lethn
Legendary
*
Offline Offline

Activity: 1540
Merit: 1000



View Profile WWW
March 12, 2013, 12:18:57 PM
 #4

Mining was always going to be a temporary way of earning Bitcoins, from what I understand, I think people have underestimated quite badly how popular Bitcoin is getting, either way, the currency should never be dictated by special interest groups, that's how Bitcoin ended up being made in the first place to attack paper money. If I see Bitcoin being messed with in such a way by greedy people I'll probably switch over to Litecoin.
benjamindees
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
March 12, 2013, 12:24:37 PM
 #5

There was not ever any scenario in which the limit would not eventually be lifted.

Civil Liberty Through Complex Mathematics
Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
March 12, 2013, 01:19:31 PM
 #6

Related:
When a majority of miners realise that lifting the 1MB block capacity will hit their pocket, they'll never let it happen unless the adjustment is done in such a way as to give them more control (e.g.: direct voting power) over the scarcity. Note: I'm not talking about the database fiasco, but allowing actual "block height" to be bigger than 1MB.

tl;dr from earlier thread I started:
  • Every 1kB of new block space = "my precious"
  • so-called 'fees' are really bids for that precious resource
  • more block space = less precious.
  • therefore, maybe miners should have a voice.

aka: supply and demand.
More space=more transactions=more fees. Yes, fees will be lower per transaction, but this will be countered by the increased number of transactions.


WiW
Sr. Member
****
Offline Offline

Activity: 277
Merit: 250


"The public is stupid, hence the public will pay"


View Profile
March 12, 2013, 01:24:33 PM
 #7

Anyone reading my posts will know that I have been all for raising the 1Mb limit at the right time, and in the right way. However, after today's events, that time is further away than previously imagined. A lot of reflection and thoughtful planning needs to go into any future change of this nature. More than we might have guessed 24 hours ago.

The first lesson of today is how to get people to accept the necessity of an upgrade path. Then how to get people to use it in a reasonable timeframe. Bitcoin can't reach its full potential being backwards compatible with every ancient version previously released. This is a real challenge.

I too am all in favor of lifting the limit, but these events have nothing to do with it. This event was unplanned.

If you plan it it's really not such a challenge. Starting now and with every future update, simply implement code that says "starting precisely at this date [six months from now] the limit will be raised". If you're running a full node that's older than six months and haven't heard the news for six months, well... You'll just be part of the tiny minority who's out of the loop. Someone may be holding on to obsolete coins and not know they're busted, but that's just what happens if you're out of the loop for so long.

The challenge is not getting everyone on board at once, it's getting everyone's consensus.
benjamindees
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
March 12, 2013, 04:06:39 PM
 #8

But it's directly messing with the Velocity controls. I didn't sign-up for "Inflatacoin".

The magic of Bitcoin is that higher velocity leads to deflation.  As soon as it doesn't, velocity will fall.  It is self-regulating.  "Velocity controls" are unnecessary.  Progressive taxes are unnecessary.  Tobin taxes are unnecessary.  "Windfall profits" taxes are unnecessary.  These are all relics of the fiat-money paradigm that is defective by design.

The block size limit has no bearing on the Bitcoin economy.  It is a technical failsafe designed to protect the Bitcoin network.  Once it is no longer needed, it will be discarded.

Civil Liberty Through Complex Mathematics
johnyj (OP)
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
March 12, 2013, 04:30:43 PM
 #9


More space=more transactions=more fees. Yes, fees will be lower per transaction, but this will be countered by the increased number of transactions.


I guess you mean "More pay-to-use space = more fees". People always can select free transaction first before they pay fees, currently the free transaction limit is set at 27KB, if the block size limit were raised to 1MB, then this free transaction capaticy will likely become 128KB, so that more transactions become free

justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1009



View Profile
March 12, 2013, 04:40:36 PM
 #10

if the block size limit were raised to 1MB, then this free transaction capaticy will likely become 128KB, so that more transactions become free
The capacity will become whatever the miners are willing to set it at, no more. If they want more fees nobody is forcing them to accept free transactions.
johnyj (OP)
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
March 12, 2013, 04:53:45 PM
 #11

There was not ever any scenario in which the limit would not eventually be lifted.

Deepbit are still running 0.3 nodes, they have never upgraded for almost 2 years and never had any problem so far.

Vista killed windows, so windows 7 falled back to windows XP architecture. The longer you are in software business, the more you will be uncertain that upgrade is a good thing. When a system has reached certain level of functionality, complexity and acceptance, any major change will impact existing users in an unforseeable way, and will result in much higher resistance than you originally expected

In my work that weekly delivery is a norm, there are many occasions that we have to call back upgrades and roll back to previous version. And there are many customers who don't like upgrade at all, they are still running some software we delivered 5 years ago and they are happy with it since that give them peace of mind

Anyway, this BDB bug created some consensus that a hard fork is needed even with today's block size limit. Before, this consensus is just not there, and many people include me do not think a hard fork is a good idea unless it is absolutely necessary and absolutely coordinated


justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1009



View Profile
March 12, 2013, 05:24:19 PM
 #12

Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!
...and his block promptly gets orphaned because most of the network is only including the transactions that make economic sense so theirs propagate faster. The single rogue miner doesn't find blocks fast enough to make a significant impact on the network unless he controls 50% of the hashing power, in which case it's game over anyway regardless of the block size limit.
BadBear
v2.0
Legendary
*
Offline Offline

Activity: 1652
Merit: 1127



View Profile WWW
March 12, 2013, 05:36:02 PM
 #13

Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!
...and his block promptly gets orphaned because most of the network is only including the transactions that make economic sense so theirs propagate faster. The single rogue miner doesn't find blocks fast enough to make a significant impact on the network unless he controls 50% of the hashing power, in which case it's game over anyway regardless of the block size limit.

How? S/he's got the latest block, i.e.: they've got the longest blockchain. Attempting to orphan them would effectively be a 51% attack orchestrated by a cartel.

No it wouldn't. People find the same block all the time, whoever pushes it through the fastest wins. Including more transactions means you will be slower and may lose.

1Kz25jm6pjNTaz8bFezEYUeBYfEtpjuKRG | PGP: B5797C4F

Tired of annoying signature ads? Ad block for signatures
benjamindees
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
March 12, 2013, 05:57:06 PM
Last edit: March 12, 2013, 06:11:30 PM by benjamindees
 #14

It would be self-regulating if there were a negative feedback loop. Could you try identifying one?

Rational self-interest.  No one would exchange Bitcoins if they didn't end up better off because of it.

Quote
However, if well-meaning developers and enthusiasts want the blocks to basically have "no scarcity" (a near-infinite maximum height per block), it basically breaks the market. Any small miner can come along and hijack the market by signing everyone else's rejected TX requests. I feel like I'm going round in circles explaining this over and over.

Perhaps "discarded" was a hasty way to put it, if you're going to argue about what happens far in the future.  Remember that, at that point, simply running a node will be an expensive proposition.  So there will always be some scarcity.  But, yes, you're right.  Some limit will be necessary in order to protect the incentives to secure the network.  I'm just saying, that's what it's there for.  It will be increased as necessary to accommodate growth in transactions without sacrificing network security.  It's not there to prevent price inflation.

Civil Liberty Through Complex Mathematics
bullioner
Full Member
***
Offline Offline

Activity: 166
Merit: 101


View Profile
March 12, 2013, 06:13:18 PM
 #15


However, if well-meaning developers and enthusiasts want the blocks to basically have "no scarcity" (a near-infinite maximum height per block), it basically breaks the market. Any small miner can come along and hijack the market by signing everyone else's rejected TX requests. I feel like I'm going round in circles explaining this over and over.

It's sometimes said that one of the impressive things about the Bitcoin design is the synthesis between several fields: it displays expertness in computer programming and cryptography, but also in economics.  It's pretty clear that no one currently at the helm gets the economics.
dayfall
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile
March 12, 2013, 06:28:39 PM
 #16

What would happen if I patched my node to accept only "noble" blocks or ones that are deeper than, say, 3 from my current height?  Miners might not have incentive to keep the blockchain reasonable, but as a node I do.  What if nodes propagated some blocks faster?
dayfall
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile
March 12, 2013, 10:51:01 PM
 #17

This is probably more naivete on my part, but: don't free transactions also increase block height? I recall Gavin once described on his blog some kind of "proof of stake patch" that could be applied, but that hasn't been done yet, right?

And what if a rogue miner is already happy to comply with the usual "etiquette" and prioritise old coins, and high bids, but on top of that they also sign the spam?

Transactions increase block size, not height. 

If a rogue miner includes, for instance, dust transactions (i.e. <0.0001 BTC) then any block they find can delayed by some nodes not relaying it.  This will allow time for "nice" miners to find a block and slip it in before the "bad" block makes it permanently into the chain.  The would create lots of orphans, but if done sparingly then it might create enough pressure for miners to play nice.  Forks are really bad so that is why I suggested that any valid block that is followed by 2 other blocks are automatically accepted.

This method could be used for both good and evil.  If most miners decided to block SD transactions then the nodes could ignore blocks that didn't include their transactions.  But, worse, nodes could refuse to relay blocks that did have SD transactions. 
thezerg
Legendary
*
Offline Offline

Activity: 1246
Merit: 1010


View Profile
March 12, 2013, 11:04:18 PM
 #18

if the block size limit were raised to 1MB, then this free transaction capaticy will likely become 128KB, so that more transactions become free
The capacity will become whatever the miners are willing to set it at, no more. If they want more fees nobody is forcing them to accept free transactions.

OK, time for a quick thought-experiment:

What if the some people get their way and the limit is increased to say 100MB per block.
If you're a miner, what would you do? Would you accept 1000s of free requests? Hell no! Compel users to put in proper bids. You need to earn a living too!
However, what happens with all that spare capacity? Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!

The people rejoice! Free transactions are back! All sorts of new services pop up, except that they have to rely on the 'slow' part of the economy because of course the rogue miner is pretty small and only discovers 1 block every 3 days on average.

All is well and good in the Bitcoin world -- velocity (and by extension: the exchange rate) is sky-high because of all the cheap/free TX requests being accepted.

But then disaster strikes: the rogue miner has disappeared! The cheap/free TX requests (aka: "zero-conf transactions") are piling up in the infinite memory heap and nobody's signing them. Some users eventually increase their bids (e.g.: from 0 Satoshis to 500k Satoshis) to speed up payments. However, many others say "screw that. Visa and Paypal have improved their services a lot lately. I think I'll use them."

What happens then? Volatility. The moral: without the ability to treat individual kilobytes of new block space as a scarce resource (and auction it off accordingly), one small miner could destabilise the whole market.

No.  simple soln: one or more of those services starts a miner.  After all it is in their interest.  Otoh, competing for blockspace opens the door for an altchain to service the market that cant afford the space.  Maybe someday, but btc is still so small we should not turn away svcs.
Peter Todd
Legendary
*
Offline Offline

Activity: 1120
Merit: 1149


View Profile
March 13, 2013, 08:39:50 AM
 #19

What if the some people get their way and the limit is increased to say 100MB per block.
If you're a miner, what would you do? Would you accept 1000s of free requests? Hell no! Compel users to put in proper bids. You need to earn a living too!
However, what happens with all that spare capacity? Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!

It's a lot more ugly than that. If there is spare capacity you can use it for something quite different than just cheap transactions; unfortunately fundamentally transactions are just data, and there is nothing we can do to prevent people from stuffing data that has nothing to do with finance at all into transactions, and thus blocks.

Thus with large blocks and cheap blockchain space you can offer a really useful service, lets call it "Google Chain Storage", the only backup service in the world that comes with the guarantee that you know you data is safe, every time you perform a successful transaction.


Technically speaking, what you do is you create a transaction with the following scriptPubKey:

Code:
OP_HASH160 <20 byte digest> OP_EQUALVERIFY <data>

In theory it can be spent by providing the data that when hashed has the 20 byte digest provided, so nodes can never prune the transaction from their databases. Of course, in reality you would just generate the digests randomly. The data payload can be up to 9974 bytes long for every transaction. At 0.1 cents per KB fees - what people were paying a few months ago - putting 1MB of junk into the blockchain forever would only cost a dollar. There are lots of people with data valuable enough that paying $1000/GB to be absolutely sure it is backed up makes sense.

Even if you try to combat the horridly abusive stuff like the above with a hard-fork that changes the rules to disable anything but the small set of standard transactions, there's still timestamping. Again the easiest way to do it is to just send a tiny amount of funds to an address that's actually a digest of the data you want to timestamp, and again the demand for time-stamping is more than enough to fill any blocksize you want.

markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
March 13, 2013, 08:59:28 AM
 #20

The magic of Bitcoin is that higher velocity leads to deflation.

Please explain how you reach that conclusion?

I thought velocity of money/currency is how fast it gets spent again and again and again, so that the more times per [span of time] the same coin can be spent again the less coins in total the system needs.

For example, if velocity was 21 million per day, so that one coin was being re-spent over and over 21 million times per day, then one coin could do the job that would have taken 21 million coins to do if velocity had been only one spend per day?

How does that cause deflation?

On the other hand if adoption increases while velocity does not increase as fast as adoption does, then there would be more need for coins / need for more coins, which sounds like it could be deflationary.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
johnyj (OP)
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
March 13, 2013, 09:49:29 AM
 #21

What if the some people get their way and the limit is increased to say 100MB per block.
If you're a miner, what would you do? Would you accept 1000s of free requests? Hell no! Compel users to put in proper bids. You need to earn a living too!
However, what happens with all that spare capacity? Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!

It's a lot more ugly than that. If there is spare capacity you can use it for something quite different than just cheap transactions; unfortunately fundamentally transactions are just data, and there is nothing we can do to prevent people from stuffing data that has nothing to do with finance at all into transactions, and thus blocks.

Thus with large blocks and cheap blockchain space you can offer a really useful service, lets call it "Google Chain Storage", the only backup service in the world that comes with the guarantee that you know you data is safe, every time you perform a successful transaction.

Technically speaking, what you do is you create a transaction with the following scriptPubKey:

Code:
OP_HASH160 <20 byte digest> OP_EQUALVERIFY <data>

In theory it can be spent by providing the data that when hashed has the 20 byte digest provided, so nodes can never prune the transaction from their databases. Of course, in reality you would just generate the digests randomly. The data payload can be up to 9974 bytes long for every transaction. At 0.1 cents per KB fees - what people were paying a few months ago - putting 1MB of junk into the blockchain forever would only cost a dollar. There are lots of people with data valuable enough that paying $1000/GB to be absolutely sure it is backed up makes sense.

Even if you try to combat the horridly abusive stuff like the above with a hard-fork that changes the rules to disable anything but the small set of standard transactions, there's still timestamping. Again the easiest way to do it is to just send a tiny amount of funds to an address that's actually a digest of the data you want to timestamp, and again the demand for time-stamping is more than enough to fill any blocksize you want.

Thanks for bring all these up, you should not demonstrate how to abuse the system Wink 

I'm bit more confident that the community will solve such kind of problem given their fast and professional reaction this time

Prattler
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
March 13, 2013, 10:05:43 AM
 #22

What if the some people get their way and the limit is increased to say 100MB per block.
If you're a miner, what would you do? Would you accept 1000s of free requests? Hell no! Compel users to put in proper bids. You need to earn a living too!
However, what happens with all that spare capacity? Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot!

It's a lot more ugly than that. If there is spare capacity you can use it for something quite different than just cheap transactions; unfortunately fundamentally transactions are just data, and there is nothing we can do to prevent people from stuffing data that has nothing to do with finance at all into transactions, and thus blocks.

Thus with large blocks and cheap blockchain space you can offer a really useful service, lets call it "Google Chain Storage", the only backup service in the world that comes with the guarantee that you know you data is safe, every time you perform a successful transaction.


Technically speaking, what you do is you create a transaction with the following scriptPubKey:

Code:
OP_HASH160 <20 byte digest> OP_EQUALVERIFY <data>

In theory it can be spent by providing the data that when hashed has the 20 byte digest provided, so nodes can never prune the transaction from their databases. Of course, in reality you would just generate the digests randomly. The data payload can be up to 9974 bytes long for every transaction. At 0.1 cents per KB fees - what people were paying a few months ago - putting 1MB of junk into the blockchain forever would only cost a dollar. There are lots of people with data valuable enough that paying $1000/GB to be absolutely sure it is backed up makes sense.

Even if you try to combat the horridly abusive stuff like the above with a hard-fork that changes the rules to disable anything but the small set of standard transactions, there's still timestamping. Again the easiest way to do it is to just send a tiny amount of funds to an address that's actually a digest of the data you want to timestamp, and again the demand for time-stamping is more than enough to fill any blocksize you want.
Thank you retep for thinking about bitcoin scalability and sustainability long term! Everyone should read this.
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
March 13, 2013, 10:10:52 AM
Last edit: March 13, 2013, 10:36:55 AM by markm
 #23

-- velocity (and by extension: the exchange rate) is sky-high because of all the cheap/free TX requests being accepted.

Whoa, explain how velocity increases exchange rates?

Surely velocity means the same coin can be used by more people in less time?

So more people manage to get their greek village parable circle of trade to go round with less coins.

So they don't need to buy as many coins per village.

How does that increase exchange rates?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Monster Tent
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
March 13, 2013, 10:22:54 AM
 #24

Upgrading the block size because of a bug doesnt show forward planning and should have been scheduled 6 months ago to avoid a fork.

Having a fork everytime the network bumps against the max block size isnt a good idea either.

benjamindees
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
March 13, 2013, 10:29:03 AM
 #25

The value of Bitcoin is the value represented by the Bitcoin economy.  The Bitcoin economy creates value just like any other economy, by voluntary specialization and trade.  Higher velocity means more specialization and trade, and thus higher value.

Just ignore exchange rates.  It has nothing to do with exchange.

Civil Liberty Through Complex Mathematics
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
March 13, 2013, 10:34:21 AM
 #26

The value of Bitcoin is the value represented by the Bitcoin economy.  The Bitcoin economy creates value just like any other economy, by voluntary specialization and trade.  Higher velocity means more specialization and trade, and thus higher value.

Just ignore exchange rates.  It has nothing to do with exchange.

Ah, okay, got you. If that tourist had wanted to buy all the services all the villagers had managed to sell to each other with his money while his back was turned, it would have cost him a heck of a lot more money than just that one "coin" they used for a few minutes behind his back and returned to him. Smiley

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Prattler
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
March 13, 2013, 10:35:59 AM
 #27

Having a fork everytime the network bumps against the max block size isnt a good idea either.
This is the best idea.

Full block space will always be occupied by spam. See http://en.wikipedia.org/wiki/Tragedy_of_the_commons. Network RAM/HDD/CPU is a limited and expensive resource, but miners have every incentive to deplete it (personal gain, costs shared by others). Bitcoin can survive the tragedy of the commons by scheduling how fast the limited resources are being depleted and keeping it lower than technology advancement.

There is currently no mechanism to force miners to pay for the network resources, they have to be limited through the block size limit.
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
March 13, 2013, 10:59:18 AM
 #28

Ok but that doesn't address money/currency velocity at all.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
benjamindees
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
March 13, 2013, 11:39:08 AM
Last edit: March 13, 2013, 11:59:19 AM by benjamindees
 #29

This discussion is kind of like arguing about the number of angels on the head of a pin, since the effects you're concerned about are greatly overshadowed by 1) miner block reward subsidies that have created an overly-strong network, 2) historically low transaction volume, and 3) massive speculative investment.

Civil Liberty Through Complex Mathematics
rebroad
Newbie
*
Offline Offline

Activity: 26
Merit: 9



View Profile
March 16, 2013, 04:31:14 PM
 #30

Before I thought that's the most troublesome topic in bitcoin, but now this bug in BDB opened a window to lift that limit, Gavin you are so lucky!  Wink

If I ever find myself owning things claiming to be bitcoins but that allow blocksizes over 1MB, I will be selling them all, and keeping the official bitcoins,,,!
Pages: 1 2 [All]
  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!