Bitcoin Forum
November 20, 2017, 12:41:33 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 [1394] 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2009951 times)
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 07:58:37 PM
 #27861

I just noticed this humorous analogy of full-RBF on Reddit in response to Maaku's comment that zero-confirm transactions were "already dead":

Quote from: imaginary_username
Analogy: Sure, locking your front door is good policy no matter where you're at. Not locking your door at all times is already dead, in your words. But some days, when I move furniture or out there to chase down my escaped cat, I feel okay leaving the door unlocked for a few minutes. It's possible, but highly unlikely, that people are gonna just break in during that time.

Implementing full RBF today will be akin to actively sending a marauding gang of thugs, and they'll break in every house that has an unlocked door for however short amounts of time. And then the Devs will point and laugh "I told you not to do 0-confs!"

A sane person can accept the risk of highly infrequent break-ins; if that becomes more often, maybe that person then invests in locking the door more often and more carefully. Great. But a sane person will not tolerate the mayor sending roving gangs of thugs to break into his house at the first sight of unlocked doors. Instead of investing in bigger locks, he's more likely to conclude that "this town sucks" and move on.

Gosh, I know you guys are good guys and care about the system being ironclad from all sides. But you gotta get out, take a walk in the real world sometimes, see how this is actually being used sometimes, before killing a usecase.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
1511181693
Hero Member
*
Offline Offline

Posts: 1511181693

View Profile Personal Message (Offline)

Ignore
1511181693
Reply with quote  #2

1511181693
Report to moderator
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 30, 2015, 08:01:08 PM
 #27862

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Jumping in. Not good to destroy zero conf, but we need to be antifragile, so the protocol should not guarantee zero conf, which it doesn't and never did. The receivers of coins must take full responsibility if they rely on zero conf, using heuristics like the current card companies does. I think I lean to the side of just not care about zero conf, from the basic bitcoin side.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:01:22 PM
 #27863

Quote
Because it can be economically expected that most transactions now are low priority, since fees are cheap. This means the actual transaction volume that likely would be taking place given only somewhat more expensive fees is much, much less. It's should be obvious enough that if transactions were completely free people would spam like crazy. That's not a judgment on the validity of those transactions; it's just economic reality. People start to economize dramatically when there is even a marginally-above-zero cost versus when there isn't.

This is in no way suggesting 1MB is sufficient, but it's not helpful to pretend that transaction volume when fees are negligible will remain the same if fees go to merely tiny. In no other market would we expect such a thing, and for all we know we could easily be talking about order-of-magnitude differences in volume from a fee increase that still presents no real pain for any major use case.

but cheap to who, you?  i remember an Indian standing up at the San Jose conf during Q&A and complaining about high tx fees for ppl in his country.  and they are, given their relative income levels.  

we should be promoting Bitcoin to these 3rd world countries where a .0001 minimum fee is arguably expensive.  that's why we have the  economic fee choice of .00001 which oftentimes still results in rejection.  to take it further, do you believe that Bitcoin should offer even these Indians the ability to buy a cup of coffee for cheap fees?  i think so but probably you think different.  i know tvbcof and iCE would flat out say no way.  but then that goes back to my argument that for maximum decentralization and to become digital gold Bitcoin needs to service these ppl.

when you say ppl will spam like crazy, don't you trust that the miners can react to filter that spam, if they so choose?  the problem with the 1MB choke approach is that yes, new users will be forced to economize on their tx's.  OR just leave.

This isn't relevant to the question of whether having a fee market would help. I'm not saying 1MB is adequate, and I'm not saying that fees shouldn't be cheap enough for any particular group. I'm saying that no matter what blocksize cap we have, or even if we have no cap, we will still need a fee market for maximum scalability on chain. And we could easily be talking about order-of-magnitude differences in scalability contingent on the presence or absence of a proper fee market. As for miners blocking spam, sure, but as you say: who's to tell what is really spam?

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  only users can determine how much they are willing to pay.
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 30, 2015, 08:01:27 PM
 #27864

Quote from: imaginary_username
Gosh, I know you guys are good guys and care about the system being ironclad from all sides. But you gotta get out, take a walk in the real world sometimes

Also applies to the "bigger blocks will mean fewer nodes" argument.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:04:51 PM
 #27865

...
fritzed out?  where do you even get that?  the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem.  it tries to fix something that is not there. 

Smart people have warned for a long time that zero-conf transactions are brittle.  If an 'industry' has built up around them, tough shit.



and your's is exactly the kind of attitude we should be rejecting here: 

"so what if we decide to change the rules in midstream on a bunch of ppl, it's what i think is best, so tough shit".
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 30, 2015, 08:05:32 PM
 #27866

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:07:07 PM
 #27867

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 30, 2015, 08:07:59 PM
 #27868

Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 30, 2015, 08:08:42 PM
 #27869

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.

Yes, the more mining costs the more miners will mine.
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 30, 2015, 08:10:15 PM
 #27870

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:10:56 PM
 #27871

network still clogged.

crimony.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:14:34 PM
 #27872

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

don't forget wallets like Mycelium that shows you a realtime flooding graph displaying when your particularly tx has hit 90% of the full nodes across the network and then working out a very small probability that it will not confirm based on a double spend.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 30, 2015, 08:15:44 PM
 #27873

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:16:06 PM
 #27874

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.

Yes, the more mining costs the more miners will mine.

of course, the sarcasm.

the point is, miners control the size of their blocks.  they will construct them to be profitable.
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 30, 2015, 08:17:03 PM
 #27875

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?


Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

This is the heuristics, you can add the experienced rate of non-confirmations. With Full-RBF they obviously have to adjust their heuristic formulas a bit, I am sure they (the market, really) can cope with it. (Still, I don't think it is needed).

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:17:13 PM
 #27876

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

then why are you even still here?  you should be filthy rich by now.
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 30, 2015, 08:17:59 PM
 #27877

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

don't forget wallets like Mycelium that shows you a realtime flooding graph displaying when your particularly tx has hit 90% of the full nodes across the network and then working out a very small probability that it will not confirm based on a double spend.

That is awesome, is this on the Android app, in which case how did I miss seeing that...
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:21:51 PM
 #27878

oh, how wonderful, Coinbase's node offline.  that's explains the flatline in the price i was seeing there.

"everything's just fine". Roll Eyes

can't wait for the explanation.

https://www.reddit.com/r/Bitcoin/comments/3bo0bj/coinbase_not_processing_blocks_since_hours/
Mengerian
Newbie
*
Offline Offline

Activity: 7


View Profile
June 30, 2015, 08:22:12 PM
 #27879

remember that, if i'm right, and full blocks are indicating additional incremental demand due to currency crises, this is going to be a more regular thing.  this is what we've theorized about for years.  the network HAS to be ready if you want to Moon.

1MB isn't going to cut it.  right now, unconf tx's are now up to 10000 with now >5TPS delays.

To be clear, I agree. Smoothly adjusting fees are another tool in the scaling toolbox, though, and should be ready for use as well. Where we're going, a 8 or 20x increase all by itself might not cut it. I'm eyeing a 500x price increase for the next bubble (peak, crashing afterward to 5-10x lower: ~$10-20K/BTC), which will mean a pretty big increase in transaction volume and may overrun even the 20MB blocks if we don't even have a fee market up yet.

We need as many scaling solutions in place as possible to enable the next bull run.

The nice thing about this debate is it's incentivizing them all. I'm confident we'll have the blocksize cap increase, hopefully in advance and not as a reaction to a stalled rally, but also a lot of other things. It's worth pushing against the small-blockers not because they have any real power to stop the increase, but because it lights a fire under them to do their part in making those optimizations to try to prove we can get by with smaller blocks. It's a futile effort on their part, but it ends up helping with large blocks, too.

Yes, it seems that increasing the blocksize limit is almost inevitable. No one can "centrally plan" bitcoin, at the end of the day anyone can run any software they want to interact with the network. It would be trivial for someone to branch off the source code using git, and release a version with Gavin's patch applied, or BIP 100, or some other change. Using git this version can easily track all the other developments, and all changes are well-defined and change history is cryptographically verified.

Since no one can apply top-down control over the network, we have to look at the incentives of the various participants. If miners, node operators, merchants, etc want larger blocks, then they would have an incentive to run software that allows a transition to larger blocks, and indicate that they are doing so.

The most overriding incentive is to stay in line with the network consensus. But if miners start mining blocks indicating that they implements BIP 100 or BIP 101, then network participants can indicate that they will accept larger blocks contingent on most others also accepting them.

In the longer term, it would also be good if this debate fosters a more diverse software ecosystem, which would allow other protocol changes to be decided by the market in this manner.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 30, 2015, 08:22:15 PM
 #27880

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.

Yes, the more mining costs the more miners will mine.

of course, the sarcasm.

the point is, miners control the size of their blocks.  they will construct them to be profitable.

This with big hashing power will create rules. You .. small miner .. will have to accept all blocks they will create. If you are lucky then you found 1 block per month.  
Pages: « 1 ... 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 [1394] 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 ... 1558 »
  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!